# Working tickets

> Work the Tickets queue in the console. Claim and assign tickets, read the thread and the AI summary, reply on WhatsApp, track delivery, escalate, call the customer, and read the tracker.

Source: https://docs.amomic.in/console/tickets

---

A ticket is support work that needs a person but not right now: a repair to book, a refund to chase, a question the agent could not answer. **Tickets** in the console is where your team picks that work up, answers the customer, and closes it.

Tickets arrive from four places:

- **Your AI agents**, when a customer asks for help the agent cannot finish. The ticket keeps the channel and the conversation it came from.
- **Live support**, when a customer asked for a person and nobody picked them up in time. See [Human handoff](/console/human-handoff).
- **Your own systems**, through the [Tickets API](/api/tickets).
- **An admin**, who raises one by hand with **New ticket**.

Every new ticket gets an AI summary, a priority-based SLA clock and, if you route automatically, an assignee before anyone opens it.

Who can do what:

| | Member | Admin or owner |
|---|---|---|
| See tickets | Active ones only: **New**, **Open**, **Pending**, **Waiting customer** | Every queue, including **Escalated due**, **Resolved** and **Closed** |
| Work a ticket (reply, note, status, priority, tags, AI copilot) | After claiming it, or once it is assigned to them | Any ticket |
| Assign a ticket | To themselves only (**Claim ticket**) | To anyone |
| Escalate | Yes | Yes |
| Acknowledge an escalation | No | Yes |
| **New ticket**, **Routing**, **Reply settings**, **Tracker** | No | Yes |

Routing and reply settings have their own page: [Ticket settings](/console/ticket-settings).

![The Tickets page with queue filters across the top, the ticket list on the left and a WhatsApp ticket open on the right, showing an internal note, a delivered reply and a reply waiting for the customer to open it](https://docs.amomic.in/screens/tickets/queue.light.webp)

*The queue on the left, the open ticket on the right. The newest reply is waiting for the customer to open a notification.*

## Queues, filters and search

The buttons along the top are queues. Every queue except **All** shows how many tickets it holds.

| Queue | What it holds |
|---|---|
| **All** | Every ticket you are allowed to see. For a member that means every active ticket. |
| **New** | Created and not yet touched. |
| **Open** | Being worked on. |
| **Pending** | Parked on your side: waiting for a part, a refund, another team. |
| **Waiting customer** | Parked on the customer's side: you asked them something. |
| **Escalated due** | Admins only. Tickets with an escalation nobody has acknowledged yet. |
| **Resolved** | Admins only. Done, and can still be reopened. |
| **Closed** | Admins only. Finished. |

The **All channels** menu narrows the list to tickets that came from **WhatsApp**, **Voice**, **Web chat**, **Email** or **API**. Email means a ticket raised with that origin, from the API or by hand. Customers cannot email a ticket in.

The search box matches the ticket reference, the subject, the customer's name and email, the latest message and the tags. It does **not** match phone numbers. To find a customer by phone, search for them in [Contacts](/console/contact-memory) and open the ticket from their activity.

The list loads 100 tickets at a time. **Load more** fetches the next 100. The count above the list, such as `1822 tickets`, is the whole queue, not the page.

### Reading a row

Each row shows the channel icon, the customer, the subject, when it last changed and the latest message. Under that:

- the priority (**Low**, **Normal**, **High**, **Urgent**) and the status;
- a red triangle when an escalation is due;
- a robot icon when the AI has triaged it;
- **Unassigned** in amber, or a person icon when someone owns it;
- the SLA label (see [Priority and SLA](#priority-and-sla)).

A red **Reply not delivered** badge (or **3 replies not delivered**) sits on its own line when someone on your team replied and the customer has not received it. That includes a reply waiting for the customer to open a notification. Look for these first: the ticket looks answered, but the customer has heard nothing.

### Linking straight to a ticket

`https://console.amomic.in/tickets?ticket=<ticket_id>` opens one ticket directly, even when it is not on the first page of the list. The contact panel in Contacts uses this link.

## Reading a ticket

The header shows the subject, then the customer's name, phone and email, the origin channel, the status menu, the SLA label and, when one is due, an **Escalation due** link. On the right:

- **Call**, when the customer has a phone number. See [Call the customer](#call-the-customer).
- **Claim ticket**, when the ticket is active and nobody owns it.
- **AI & details**, which opens the side panel.

Below the header are three tabs.

| Tab | What it shows |
|---|---|
| **Conversation** | The ticket thread: what the customer said, your team's replies with their delivery state, and internal notes. This is where you reply. |
| **Summary** | The customer's contact details and the AI's conversation summary, with its confidence, the intent, the risk, the customer's sentiment and anything it thinks is missing. |
| **Full history** | The original chat or call transcript the ticket was raised from, up to the latest 200 messages. A ticket raised by hand or from the API has none. |

### AI & details

![A ticket with the AI & details panel open, showing the reference, priority and assignee menus, an Escalation due box with an Acknowledge button, and the AI copilot summary](https://docs.amomic.in/screens/tickets/details.light.webp)

*AI & details on an escalated ticket. An admin sees the assignee menu and Acknowledge.*

The panel holds, top to bottom:

- **The reference** (for example `AM-2B9D5F13`), the subject and when it was opened. Quote the reference to the customer; it is the same one the API returns as `public_ref`.
- **Priority**, as a menu.
- **Assign ticket**, as a menu. Admins only. It lists every active member with their role.
- **The SLA label** and the current owner.
- **The escalation box**, when there is one. See [Escalate and acknowledge](#escalate-and-acknowledge).
- **AI copilot.** See [The AI copilot](#the-ai-copilot).
- **Customer context**: email, phone, the conversation thread id, and the ticket's **Tags**. Type in **Add a tag** and press Enter or **Add**. Tags are stored lowercase with spaces turned into hyphens, up to 32 characters each and 20 per ticket.

## Statuses and how they move

Change the status with the menu in the header. It only offers moves that are allowed from where the ticket is now.

| From | Can move to |
|---|---|
| **New** | Open, Pending, Waiting customer, Resolved, Closed |
| **Open** | Pending, Waiting customer, Resolved, Closed |
| **Pending** | Open, Waiting customer, Resolved, Closed |
| **Waiting customer** | Open, Pending, Resolved, Closed |
| **Resolved** | Open, Closed |
| **Closed** | Open |

New, Open, Pending and Waiting customer are the **active** statuses. Members only ever see active tickets, so a member who resolves a ticket stops seeing it until it is reopened.

Moving a ticket to Resolved or Closed has two side effects:

- A due escalation on it is marked resolved.
- Any reply still waiting for the customer to open a notification, or held on a setting, is cancelled and shows **Never delivered**. A customer who finally taps the notification days later is not sent an update on a request you have closed. The words stay on the ticket for your team.

One status change happens on its own: when the customer writes on a ticket that is **Waiting customer**, **Resolved** or **Closed** (for example by tapping **Add reply** on WhatsApp), the ticket moves back to **Open**. Nothing else changes a status for you. Replying does not move a ticket to Waiting customer; set it yourself.

## Priority and SLA

Every ticket gets an SLA due time when it is created, from its priority:

| Priority | Due within |
|---|---|
| **Urgent** | 2 hours |
| **High** | 8 hours |
| **Normal** | 24 hours |
| **Low** | 72 hours |

The due time is fixed at creation. **Changing the priority later does not move it.** Raising a Low ticket to Urgent leaves its 72-hour clock in place, so keep an eye on tickets you escalate by hand.

The clock counts calendar hours. It does not pause outside your live hours, at night, or while a ticket is Pending or Waiting customer.

| Label | Meaning |
|---|---|
| `14h left` | Active, and due in that many hours, rounded up. Turns red at 4 hours or less. |
| `2h overdue` | Active, and past its due time. Red. |
| **SLA met** | Resolved or closed before the due time. |
| **SLA breached** | Resolved or closed after the due time. Red. |
| **Completed** | Closed with no resolution time recorded. |

## Claim, assign and route

- **Claim ticket** makes it yours. It appears on any active ticket nobody owns. Until a member claims a ticket, the reply box reads *Claim this ticket before working on it.* and the AI copilot is read-only for them.
- A member who opens a ticket someone else owns sees *Assigned to another team member. You can view the active ticket, but only its assignee or an admin can work it.*
- Admins assign anyone from **AI & details → Assign ticket**, or choose **Unassigned** to put a ticket back in the pool.
- **Routing** decides whether new tickets are assigned automatically. See [Ticket settings](/console/ticket-settings#routing).

## Reply or add an internal note

::: steps

::: step Choose what you are writing

The menu under the reply box starts on **Public reply**. Switch it to **Internal note** to write something only your team sees. A note never reaches the customer; it shows in the thread with a padlock and **Internal note**.
:::

::: step Write it

The placeholder tells you where a reply will go, for example *Reply via whatsapp...*. If a line above the box reads **Reply delivery information** or **Written replies unavailable**, open **Details** first. See [Before you type](#before-you-type-can-a-reply-reach-them).
:::

::: step Send

Choose **Send reply** or **Add note**, or press **Ctrl + Enter** (**⌘ + Enter** on a Mac).
:::

:::

The toast tells you what really happened to a reply, not just that it was saved:

| Toast | Meaning |
|---|---|
| *Reply delivered* | It reached the customer. |
| *Customer notified — your reply arrives when they open it* | Their WhatsApp window was closed, so they got a notification first. |
| *The reply is saved and will be retried.* (or the reason) | The first attempt failed. It retries on its own. |
| The reason, in red | It cannot be delivered. |

## Where a reply goes

A reply does not always travel on the channel the ticket came from:

| Ticket came from | The reply goes |
|---|---|
| **WhatsApp** | Back to the same chat, from the number the customer wrote to. |
| **Voice** or **Web chat**, with a phone number | To the customer on **WhatsApp**. A phone call has no written channel, and WhatsApp is the one that lets the customer answer. |
| **Web chat**, no phone number | Into the visitor's chat window, which they see if they come back while their chat session is still alive. |
| **Email** | By email to the customer's address. This is the only case that uses email. |
| **API** | Nowhere. A written reply cannot reach the customer from a ticket your systems created; your systems receive the `ticket.replied` [webhook](/webhooks/events) and can deliver it themselves. Or call the customer. |

Every WhatsApp message from a ticket carries an **Add reply** button. When the customer taps it and types, their answer lands on the ticket.

WhatsApp tickets always reply from the number the customer wrote to. For the other rows, the number comes from [Reply settings](/console/ticket-settings#which-number-replies-come-from).

## Did the reply reach the customer?

Under each staff reply is its delivery state.

| State | What it means | What to do |
|---|---|---|
| **Delivered** · time | It reached the customer. | Nothing. |
| **Sending** | In flight, or waiting for its next automatic attempt. | Nothing. |
| **Waiting for the customer to open it** | The customer has been quiet for over 24 hours, so WhatsApp only allows a notification. They were sent one. Your reply is delivered the moment they tap **View update**. | Nothing, unless it is urgent; then call them. |
| **Held — waiting on a setting** | Nothing has been attempted, and nothing will be until an admin changes a setting or the workspace's invoice is paid. The reply is kept, not lost. | Read the line under it. Usually: choose a number in [Reply settings](/console/ticket-settings#which-number-replies-come-from). If it reads *Sending is paused while this workspace has an unpaid invoice*, an owner pays the invoice on [Billing](/console/billing). |
| **Not delivered yet — retrying** | An attempt failed and it will be tried again automatically. | Wait, or fix the cause the line under it names. |
| **Never delivered** | It will not arrive. | Fix the cause, then **Send again**, or call the customer. |

The line under a reply that has not been delivered explains why, in a sentence. `· 3 attempts` shows how many tries it has had.

The rules behind these states:

- **Three attempts.** A failing reply is retried automatically. After the third failed attempt it becomes **Never delivered**, and the ticket's owner gets a console notification, *Reply to AM-… was not delivered*.
- **Three days.** If a customer never opens the notification, the reply becomes **Never delivered** after three days, with *Try calling them*. The owner is notified.
- **Held replies cost no attempts.** They wait for as long as the setting is unfixed, then go out on their own.
- **A suspended workspace holds WhatsApp replies.** While the workspace is suspended for an unpaid invoice, a WhatsApp reply is held with *Sending is paused while this workspace has an unpaid invoice. This reply is kept and sends by itself once the invoice is paid.* It goes out without anyone pressing **Send again**. A reply on an email ticket is not held; it is still sent by email. See [When a payment fails](/operate/plan-changes#when-a-payment-fails).
- **Several replies, one tap.** If you wrote three replies while the customer was away, one tap on **View update** delivers all three, in the order you wrote them.
- **Send again** appears on **Not delivered yet — retrying** and **Never delivered** replies, for whoever can work the ticket. It resets the attempt count, because you have presumably just fixed what was wrong. It is not offered on a reply that is only waiting for the customer to open it, because that would send them a second notification.

::: note A closed WhatsApp window is not a failure
It is a different route. The customer gets a short notification, taps **View update**, and every reply waiting on that ticket is delivered in order. See [The 24-hour window](/channels/whatsapp-window).
:::

### Before you type: can a reply reach them?

When something affects delivery, a line above the reply box says so before you write anything. **Details** opens the **Reply delivery** dialog.

- **Reply delivery information** (grey) means the reply will get there, by a route worth knowing about. The usual one: the customer has been quiet for over 24 hours, so they will get a notification first.
- **Written replies unavailable** (amber) means a written reply cannot reach this customer at all. The dialog says why, and gives you the way out.

![The Reply delivery dialog saying a written reply cannot reach this customer because they opted out of WhatsApp messages, and suggesting a call on their number instead](https://docs.amomic.in/screens/tickets/reply-delivery.light.webp)

*A customer who opted out of WhatsApp. The way out is the phone.*

| Reason in the dialog | The way out |
|---|---|
| The customer opted out of WhatsApp messages from you. | Call them. The dialog shows the number. |
| The workspace has more than one WhatsApp number and none is chosen for replies. | An admin gets **Choose a reply number**, which opens Reply settings. A member is told an admin can set it from **Reply settings**. Write the reply anyway; it is held and goes out once a number is chosen. |
| WhatsApp is not connected for this workspace. | Connect it in [Channels → WhatsApp](/channels/whatsapp). |
| The update template is not approved, so a customer quiet for over 24 hours cannot be reached. | An admin sends it for approval from [Reply settings](/console/ticket-settings#the-ticket-update-template). Meta usually answers within a day. |
| The ticket has no phone number or email address. | Call them if you have their number elsewhere, or wait for them to come back. A web-chat ticket without a phone number has no second route. |
| The ticket came from the API. | Deliver it from your own systems, or call. |

::: warning Until the update template is approved, quiet customers do not hear back
Replies inside the 24-hour window go out normally. A reply to a customer quiet for longer is retried, and after three attempts it is **Never delivered**. Get the template approved, then use **Send again**.
:::

## The AI copilot

Every ticket is triaged by AI when it is created. Open **AI & details** to use the copilot.

| Part | What it is |
|---|---|
| Confidence | How sure the AI is of its reading, as a percentage. |
| Summary | The customer's problem and where it stands. |
| Intent, risk, sentiment | What the customer wants, how risky the ticket is (**low**, **medium**, **high**), and how they feel (**positive**, **neutral**, **negative**, **frustrated**). |
| **AI recommended tags** | Suggested tags. Each `+ tag` button adds it to the ticket. |
| **Missing:** | Information the AI thinks you still need from the customer. |
| **Suggested reply · review before sending** | A draft reply. **Use draft** puts it in the reply box for you to edit. **Copy** copies it. |

The refresh button next to the confidence regenerates everything from the thread as it is now. Do this after the customer has replied. A ticket without an AI reading shows **Generate** instead.

The copilot never sends anything. A suggested reply goes nowhere until you send it yourself. Members can use it on tickets they have claimed.

## Escalate and acknowledge

Escalate when you are blocked: it needs a decision above your authority, it is urgent, or it is outside what you can do. It is not a substitute for assigning the ticket to someone.

::: steps

::: step Open the menu under the reply box

Choose **Escalate** at the bottom of the **Public reply** menu. It is offered on active tickets you can work or claim.
:::

::: step Say why

In **Tell admins why this needs attention**, write what is blocked. At least three characters. Then choose **Escalate to admins**.
:::

:::

What happens:

- The ticket shows a red triangle in the list and **Escalation due** in its header, and joins the **Escalated due** queue. The tracker's **Escalations due** count goes up.
- If a member escalates an unassigned ticket, it is now theirs. An admin who escalates does not take ownership.
- The reason, who raised it and when are recorded in the **AI & details** escalation box.

An admin reads the reason in **AI & details** and chooses **Acknowledge**, which marks it **Escalation acknowledged** so the team can see it is owned. Resolving or closing the ticket also clears a due escalation. A ticket can only have one due escalation at a time.

::: note Admins find escalations in the queue
Escalating does not send admins a separate message or email. Admins should check **Escalated due** (or the tracker's **Escalations due**) as part of their routine.
:::

## Call the customer

**Call** appears in the header of any ticket with a phone number. It opens **Call** followed by the customer's name.

![The call chooser for a ticket, offering Web call from the browser or Call on my phone](https://docs.amomic.in/screens/tickets/call.light.webp)

*Two ways to call from a ticket.*

| Option | What happens |
|---|---|
| **Web call** | You talk from the browser. The call panel has **Mute**, **Hold**, **Hang up**, **Microphone** and **Speaker** pickers, and the ticket's **Info**, **Summary** and **Conversation** beside the call so you do not have to switch tabs. It shows **Not set up** and cannot be chosen when in-browser calling is not enabled for your workspace. |
| **Call on my phone** | Amomic-AI rings the phone number on your profile, then the customer, and connects you. Your number must be verified first; if it is not, you are asked to verify it with a one-time code before the call starts. |

While a phone-mode call runs, a status chip next to **Call** reads *Calling both phones…*, *Ringing…*, *Connecting…* or **Connected**, and finally **Call ended**, **No answer**, **Line busy** or **Call failed**.

Calling needs at least one active phone number in the workspace; it is the caller ID the customer sees. Without one, the call does not start and you are told *Add a phone number to your workspace before calling.*

The call is recorded in [Calls](/console/calls) as a call from a ticket, with who placed it, whether it was a web call or a phone call, and its talk time. It uses your workspace's voice minutes like any other call.

## Create a ticket (admins)

**New ticket** opens **Create ticket**.

| Field | Notes |
|---|---|
| **Customer name**, **Email** | At least one is required. |
| **Subject** | Required. Up to 240 characters. |
| **Request** | Required. The customer's request and any context. It becomes the first message of the thread. |
| **Origin channel** | **Manual / API** (default), **Email**, **WhatsApp**, **Voice** or **Web chat**. A label for where the request came from. |
| **Priority** | Sets the SLA clock. Default **Normal**. |

There is no phone field. That means:

- a hand-made ticket has no **Call** button;
- a written reply can only reach the customer when the **Origin channel** is **Email** and you entered their email address.

For work you need to answer on WhatsApp, let the agent raise the ticket from the conversation. A ticket created through the [Tickets API](/api/tickets) with the customer's phone number gets a **Call** button, but it still cannot take a written reply (see [Where a reply goes](#where-a-reply-goes)).

## The tracker

The Tickets page has two views, switched at the top: **Workspace**, the queue, and **Tracker**. The tracker is **admin-only**. It counts every ticket in the workspace, not one page of them.

![The ticket tracker with six figures, an AI operations analysis and a team workload table](https://docs.amomic.in/screens/tickets/tracker.light.webp)

*The tracker after Analyze now.*

| Figure | What it counts |
|---|---|
| **Total created** | Every ticket the workspace has ever had, in any status. |
| **Active** | Tickets in New, Open, Pending or Waiting customer. |
| **Pending** | Tickets in Pending. |
| **Unassigned** | Active tickets with nobody assigned. This is the number to drive to zero. |
| **Escalations due** | Escalations not yet acknowledged. |
| **SLA risk** | Active tickets due **within the next four hours**, including any already overdue. |

**SLA risk** is a warning, not a breach count. A ticket shows there while you can still act on it.

### AI operations analysis

**Analyze now** writes a short reading of the workload: where the pressure is, what to do first, who is carrying too much. It is generated from the same figures, stamped with the time it ran, and does not refresh itself. Choose **Refresh analysis** when the numbers have moved. It changes nothing on the page; treat it as a summary of what you can already see.

### Team workload

One row per person who currently owns at least one ticket, in any status, with their role:

| Column | Counts |
|---|---|
| **Open** | Their tickets in New or Open. |
| **Pending** | Their tickets in Pending. |
| **Waiting** | Their tickets in Waiting customer. |
| **Resolved** | Their tickets in Resolved. |
| **Total** | Every ticket assigned to them now, **including closed ones**, so it is more than the other columns added up. A ticket reassigned to someone else counts for its new owner. |

The table is sorted by **Open**, busiest first. Someone with no tickets at all does not appear.

## Troubleshooting

**I can't reply: the box says *Claim this ticket before working on it.*** Choose **Claim ticket** in the header. If there is no Claim button, someone else owns it; ask them or an admin.

**A ticket disappeared from my list.** It was resolved or closed. Members only see active tickets. Ask an admin, who can see the **Resolved** and **Closed** queues and reopen it. It also comes back as **Open** by itself if the customer writes on it again.

**The list says *Reply not delivered* but the ticket looks answered.** Open it and read the line under the last reply. Most often the customer has not opened the WhatsApp notification yet. If it is urgent, call them.

**A reply has said *Held — waiting on a setting* for hours.** Nothing will move until the setting is fixed. The line under the reply names it; usually an admin needs to choose a number in [Reply settings](/console/ticket-settings#which-number-replies-come-from). If it says the workspace has an unpaid invoice, the reply goes out by itself once an owner pays it on [Billing](/console/billing).

**I raised the priority but the SLA did not change.** The due time is set when the ticket is created and does not move. See [Priority and SLA](#priority-and-sla).

**Search can't find a customer by phone number.** Search does not cover phone numbers. Find the customer in [Contacts](/console/contact-memory) and open the ticket from their activity.

**Web call says *Not set up*.** In-browser calling is not enabled for your workspace. Use **Call on my phone**.

## Related

::: cards

::: card Ticket settings
[Routing, the reply number, and the update template](/console/ticket-settings), for admins.
:::

::: card Human handoff
[Live support](/console/human-handoff): customers who need a person now, not later.
:::

::: card Tickets API
[Create and read tickets](/api/tickets) from your own systems. For an agent-created hand-off from start to finish, see [Escalate to a ticket](/recipes/support-escalation).
:::

:::