Manage tickets in Internal → Tickets

Open the authorized internal queue

Sign in with an available internal operator account, open the outer Internal tab and choose Tickets in its inner sidebar. Operator access is a privileged account flag granted separately; an ordinary profile edit cannot enable it, and explicit fixture accounts cannot use the operator queue. The customer Support page remains scoped to your own tickets even if you are an operator, so use Internal → Tickets for cross-account support work. A developer API key does not authenticate this internal workflow or the private images you need to inspect.

Find the intended customer conversation

Use the Status filter to inspect Open, In progress, Waiting on customer, Escalated, Resolved, Closed or all statuses. Read the subject, category, account ID, message count and message time before opening a case. Use Load more tickets when a list has additional pages. Similar subjects can belong to different accounts, so confirm the target instead of answering the first familiar-looking row. The queue organizes saved conversations; a status filter is not an automatic service-level deadline or evidence that another operator has claimed exclusive ownership of the ticket.

Read existing messages and status history

Open the ticket and review the customer's report, previous support answers, image evidence and status transitions. Load older messages and older status updates independently when the initial view does not include the whole history. Identify what the customer has already tried before asking for the same information again. If a screenshot lacks symbol, date or session coordinates, request those specific details rather than assuming the picture describes current live data. Keep the account context in view while opening private images so evidence from similarly named cases is not mixed.

Compose a public customer reply

The thread composer sends a public support message, not a private staff note. Use clear paragraphs, intentional blank lines and numbered steps for a suggested procedure. State the expected outcome of each important step so the customer knows what result to report. Attach only relevant safe images and review them before sending. Use Send reply & email to save the answer and queue its notification. Do not include internal credentials, provider secrets, another customer's data or operational discussion that was meant only for staff.

1. Open the correct account's ticket and read its existing evidence.
2. Write a customer-visible answer with concrete steps and expected outcomes.
3. Review formatting and attachments, then choose Send reply & email once.

Update the ticket status deliberately

Choose a Ticket status and use Update status to commit the selected transition. Open keeps the issue active; In progress records ongoing work; Waiting on customer asks for additional evidence or action; Escalated records further investigation; Resolved and Closed mark completed or closed conversation states. An active support reply normally moves the ticket to Waiting on customer. A reply to an already resolved or closed case does not itself guarantee a different closed-state policy. Choose the explicit status that matches the next step and explain any material transition in the public answer when useful.

Expect customer follow-ups and concurrent edits

Customers can resolve or reopen their own tickets. A customer reply reopens resolved or closed cases, while an escalated case retains escalation through the follow-up. Visible screens refresh every 20 seconds when appropriate and on focus, but another operator can still update a ticket while your draft is open. Writes use the current revision and a request identity; on conflict, read the refreshed conversation before resending. Operator replies and status changes write audit evidence with the mutation, so avoid making a series of meaningless status changes just to draw attention.

Separate saved replies from email acceptance

Each saved support reply queues a durable job to send from noreply@ordermap.si through Resend to the actual ticket owner's verified email. The composer does not choose an arbitrary recipient. Queued, provider-accepted and delivered are separate states, and delivered does not prove primary-inbox placement or correct mail-client rendering. Direct email responses are not ingested; customers continue in the app. Respect the per-account UTC daily bounds of 200 replies, 200 status changes and 50 images, plus five images per message and the 1,000-message ticket limit. These bounds do not create a promised response time.