Most support tools present queues as piles: new, pending, waiting on customer, escalated. Operators live inside those piles. Product analytics usually never sees them. Support Funnel App Analytics, in the Identity Nodecore Atlas, treats each queue label as a funnel stage with entry criteria. If you cannot write the sentence “a ticket may enter Pending only when…”, you do not have a stage. You have a dumping ground with a colour.
Entry criteria sound bureaucratic until a night desk in Pathum Thani tries to honour an SLA that starts at bot acknowledgement. The clock is lying. The real stage — first human reply — is downstream. We ask desks to rename the stage in the Atlas even if the vendor field cannot be renamed. The map is allowed to be more honest than the software.
WhatsApp and LINE complicate this because the “ticket” is often created by a human after several messages. If your funnel starts at record creation, you have already dropped the conversational work that happened in the app people actually use. Queue-to-Resolution Mapping, our shorter workshop, spends a day just dating when the person first reached a human, not when the CRM woke up.
Escalation queues deserve the same treatment. “Escalated” without a reason code is not a stage; it is a shrug. In Signal Bench we require at least three reason codes that a reviewer would recognise: product defect, policy exception, missing access. Volume in each code is a funnel metric. Volume in a nameless escalation bucket is theatre.
The point is not to make operations look like growth analytics. The point is to stop pretending the desk is downstream of the app. For many Thai and APAC products, the messaging thread is the app. The queue is the funnel. Write the criteria or admit the pile.