#Support Tickets

#Overview

The AiDial portal includes a support ticket workflow for questions, access issues, billing questions, and operational requests. Use it when you need AiDial or your delivery partner to review a portal issue with the right account context.

Support tickets are available to customer and partner portal users according to role. Your request is scoped to your signed-in organisation and, when relevant, to the selected client or project. The customer/partner Support page is authorised for client_admin, client_manager, client_staff, partner_admin, and partner_user; internal AiDial support actions are handled through the scoped support API/BFF routes where those routes allow them.

#When to Create a Ticket

Create a support ticket when you need help with:

• signing in, MFA, or access problems
• billing questions or invoice follow-up
• call history, dashboard, or reporting questions
• settings changes that are not available to your role
• project configuration questions that need partner or AiDial review
• a suspected incident or degraded portal experience

For urgent service-impacting issues, use your agreed escalation path as well as opening a ticket.

#Creating a Ticket

1. Sign in to the AiDial portal.
2. Open Support from the portal navigation.
3. Select New ticket.
4. Confirm the project the request belongs to.
5. Select Low, Normal, or High priority.
6. Confirm who should receive ticket updates. You are always included, and you can add verified users from your organisation.
7. Optionally attach up to 5 recent calls from the same project.
8. Optionally add PNG, JPG/JPEG, or PDF attachments when attachment storage is available.
9. Add a short subject and complete What's happening?.
10. Submit the ticket.

Do not include passwords, API keys, recovery codes, full payment details, or other secrets in a ticket. AiDial support will never ask you to paste one-time MFA codes or raw secret values.

#Related Calls

Customer users can attach recent call references while creating a ticket. The portal validates the selected calls before the ticket is submitted, deduplicates repeated references, and only allows calls that belong to the selected project and signed-in tenant scope.

The support BFF route contract also supports listing, attaching, and detaching related calls for scoped support workflows, and internal reverse ticket lookup by call reference. Those operations stay behind role, tenant, and project checks; the current ticket detail page only shows a linked-call shortcut when the ticket detail payload includes a safe related_call_id. Related-call validation and reverse ticket lookup do not expose caller details, transcripts, summaries, or tickets from another organisation.

#Update Recipients

The create form's Send updates to field accepts verified tenant users only. The portal stores user identifiers, not free-text email addresses, and displays recipient chips by display name. The signed-in user is added automatically and cannot be removed while creating the ticket.

A ticket must have at least 1 and at most 5 update recipients. Recipient add and remove actions are scoped to the ticket tenant, audited without raw email addresses, and protected by the same non-enumerating access checks as other support ticket actions.

#Uploads

Uploads let you add files to a project-scoped support ticket while preserving a safe display version of the filename you selected. The portal accepts png, jpg, jpeg, and pdf files up to 10 MB each, with up to 5 active attachments per ticket. Duplicate active filenames are rejected within the same ticket so that support can refer to each file unambiguously.

Uploaded files are private support-ticket data. Attachment storage is readiness-checked before the dropzone is enabled. When available, the portal requests a short-lived upload session from aidial_api; the browser uploads directly to DigitalOcean Spaces by pre-signed PUT URL, and the portal server does not receive the file bytes. Backend object keys use the support_attachments folder with server-generated file IDs; the user-selected filename is kept only as the safe display filename.

#Ticket Categories

Customer-created tickets do not require a category at submission time. Partner administrators, AiDial administrators, or AiDial operators can assign the category during triage when their role has write access to the ticket.

#Priority Guide

Choose the priority carefully. Overstating priority can slow triage because support may need extra clarification before acting. AiDial support can still use the full internal priority scale, including Medium and Critical, during triage after creation.

#Following Up

The Support page uses role-specific lists. Client administrators see open, waiting-on-you, resolved, and all-ticket views with ticket reference, subject, owner, status, reply/comment summary, and last update time. Other customer roles use the standard ticket table with status, priority, category, requester, created date, and a linked-call shortcut when one is present. Partner users see an assigned-client queue with client, requester, owner, status, priority, category, and updated time. Open a ticket to review its details, status history, comments, and clean attachments.

You can add a comment when you have more information or need to clarify the request. Keep comments focused on the issue and avoid adding secrets or unnecessary personal information.

The client-administrator ticket list supports open, waiting, resolved, and all-ticket views. Subject search is scoped to the selected tenant context and rejects wildcard-style search strings so another organisation's ticket subjects cannot be probed through broad search filters.

#Statuses

Some status changes are performed by support or by users with the required role. Partner administrators, AiDial administrators, and AiDial operators can perform valid status transitions. Customer roles can only reopen a resolved or closed ticket. If a status action is not visible, your current role may not be allowed to make that change.

#Access and Scope

Customer users see tickets for their own organisation. Partner users see tickets only for clients assigned to their partner account. Access is checked by the portal each time a ticket is listed, opened, commented on, or updated.

The browser talks to portal route handlers under /api/support/** and /api/shell/support/open-count. Those handlers use the signed-in NextAuth/Zitadel session and forward a server-side bearer token to aidial_api; the browser is not expected to send X-API-Key. Non-API Support pages are protected by middleware, while support API routes enforce their own session, RBAC, CSRF for mutations, rate-limit, audit, and tenant/project-scope checks.

Ticket pages avoid exposing whether another organisation has a matching ticket or call reference. If a ticket is outside your scope, the portal shows a not-found style response.

Related-call checks follow the same scoping rule. A call from another tenant or from a project outside the user's assignment is treated as unavailable, even if the caller knows the call reference.

The Support sidebar badge shows the number of open tickets for eligible roles. Client administrators and client managers see their own organisation count; partner users see their assigned-client count. Client staff do not receive the badge. The badge refreshes from the signed-in portal session about once per minute, hides zero and error states, and does not accept a browser-supplied client ID.

List badges and waiting counts use stored support-ticket aggregates from the API. Customer roles see customer-visible comment counts and support-reply state only; partner and AiDial support roles can use their broader support scope without exposing client ids in summary counts.

#Good Ticket Descriptions

Helpful tickets usually include:

• what you were trying to do
• the page or workflow where the issue happened
• the approximate date and time
• the project or client name, if your role manages more than one
• any visible error message, without secrets
• what you expected to happen

Avoid screenshots that reveal callers' personal information unless support specifically asks for a redacted example.

#Common Issues

#Related Pages

• Signing In
• Roles & Permissions
• Partner Escalation