See who a ticket goes to and why

What you will have

• See which tech a ticket landed on and read the reason recorded for it, in one sentence.
• Know the order dispatch tries before it gives up: the owning pod's skill match, then its least-loaded free member, then the next tier up, then a specialty pod, then a human.
• Give one client a dedicated tech so every one of their tickets goes straight to that person, ahead of the pod entirely.
• See how a ticket's calendar block gets its length, and what the audit log records when a person reassigns a ticket by hand instead of leaving it to dispatch.

Why it works this way

Steps

1. 1

   Open a ticket dispatch has already assigned and look at Assigned To on the toolbar.

   Ticket #25, "VPN client crashes on wake from sleep" for Harbor Freight Logistics, came in through the client portal with nobody named to take it. Dispatch picked jordan.reyes the moment it landed. Assigned To on the toolbar shows the pick, same as any other assignment; there is no WHY chip here now, that lives on History, one card down the page.

   

2. 2

   Open History and expand the row that reads Autonomous dispatch, to jordan.reyes, Dispatched.

   The row names what acted (Autonomous dispatch) and who it picked (to jordan.reyes) in one line, plain sentence, no archaeology needed. Expand it and the full pick shows underneath: Step 2, Step Label owning-pod:relaxed, Pod Name Help Desk, Load 4, Candidates Considered 2, Required Skills none, Reason ticket.created:client-portal. Step 2 is the pod waterfall's second rung: the owning pod's tier, any free member, least loaded first, no skill match needed. Two candidates were in the pod; jordan.reyes had the lighter load of the two, so jordan.reyes got it.

   

3. 3

   Open Settings > System > Setup Wizards > Set up Dispatch and read the first lesson.

   "Prerequisite: pods + members" states the order the code runs, in the product's own words: dispatch can only assign a ticket to a tech who is a member of the client's owning pod, tiers (T1 to T2 to T3) set the escalation order inside that pod, and the pod's own Auto-Dispatch toggle is the final per-pod gate on whether Elise books the calendar herself or leaves the pick to the plain waterfall. Team > Pods > (a pod) > Members is where techs join a pod and get a tier; Config is where Auto-Dispatch lives.

   

4. 4

   Open Clients > Bluebird Dental > Settings and set Default Ticket Assignee.

   This is the dedicated-tech door. Its own hint spells out the ruling: every new ticket for this client, however it arrives, goes straight to this person ahead of every other assignment mechanism, though the ticket still gets scheduled and tagged like any other. Set it to jordan.reyes and save. Owning Pod stays "- Unassigned -" here on purpose, since with a dedicated tech in place there is no waterfall left for a pod to run. This client edit screen does not print the client's name anywhere on it; the breadcrumb and page title both stay generic while you're on it, so the ticket number and Bluebird Dental context in the surrounding steps are what confirm you're on the right client's page.

   Note: Default Ticket Assignee locks every new ticket for this client to that person, ahead of dispatch and Ticket Rules, until a human reassigns it by hand.

   

5. 5

   Create a new ticket for Bluebird Dental and open its History.

   Ticket #26, "New hire needs a laptop set up before Monday," was created with no assignee picked. It landed on jordan.reyes before the page even finished loading, and History reads a different sentence than ticket #25's: "Dedicated tech (Client default assignee), Dedicated tech assigned," expanding to Assigned To jordan.reyes. No pod, no tiers, no candidates considered, because none of that ran; the dedicated-tech rule caught the ticket at creation, ahead of dispatch.

   

6. 6

   Open Scheduling on the ticket and click Schedule.

   The form pre-fills Tech to the ticket's current assignee and Duration (min) to 60, this tenant's Default Ticket Estimate (Settings > Dispatch & Scheduling > Dispatch Rules), because ticket #26 carries no tags with a learned average yet. A ticket whose tags do have history gets the rolling average for those tags instead, always the larger of the two if it carries more than one tag; the block is sized by whichever real fix-time number resolves, never a flat guess.

   

7. 7

   Reassign a dispatched ticket by hand: open Assigned To on ticket #25 and pick a different tech.

   Picking Northwind Demo from the Assigned To combobox moves the ticket immediately; Assigned To on the toolbar now reads Northwind Demo in place of jordan.reyes.

   

8. 8

   Open History again and expand the new Reassigned row.

   The row is named by the person who did it, Northwind Demo, badged user rather than system, with no WHY chip: a human made this choice, so there is no automated cause to explain. It expands to the plain diff every reassignment leaves: assignedTo changed, before jordan.reyes, after Northwind Demo, plus Old Assigned To and New Assigned To spelled out again underneath. Reassigning also erases the dispatch chip that used to explain the assignment: getAssignmentCause only shows an automated reason while the automated pick is still the ticket's current assignee, and a manual reassignment away from that pick is never automated again.

   

9. 9

   Move a ticket to a different client: click the Organization field on the ticket toolbar and search for the new client.

   Ticket #46, "Front desk printer offline," started on Bluebird Dental with a reply and 5 minutes of logged time already on it. Clicking Organization opens a plain search box right there in the toolbar; typing "Harbor Point" lists Harbor Point Physio to pick. The same toolbar's Contact field does the same job the other way round: picking a contact who belongs to a different client moves the ticket to that client too.

   

10. 10

    Pick it, and the whole ticket moves in one step, with no confirmation.

    Organization now reads Harbor Point Physio, and the breadcrumb and page title switch to match. Nothing else about the ticket was touched to make this true: the Communication card still shows both the original note and the reply that carried 5 minutes of logged time, and the Time Entries card still totals 0:05 hrs logged. Replies, files and time entries all move with the ticket, in the same step.

    Note: Only closed and billed work blocks a move: a time entry locked because it is already on a live invoice. Time locked by a consolidation rollup, a closed period or a manager lock still travels with the ticket. To move a ticket with billed time on it, void the invoice first, then move it (owner ruling, src/lib/domains/tickets/org-move.ts:18-31).

    

Other ways to do this

If it did not work

• If the client has no Owning Pod and no Default Ticket Assignee, dispatch has nowhere to send the ticket: it stays unassigned and is flagged Needs Attention for the pod's techs to claim.
• If Elise Dispatch Mode is Off, no ticket is ever auto-dispatched; every ticket falls back to whatever the creating door does (admin tickets self-assign to the creating admin, client-portal and email tickets stay unassigned until claimed).
• If the pod's lowest tier has nobody eligible (no members, or everyone inactive, blacklisted, or PASSIVE), dispatch climbs to the next tier automatically rather than stopping.
• If a required skill matches nobody in the owning pod or any specialty pod, dispatch falls back to the full candidate set rather than stranding the ticket on a skills miss.
• If Elise Dispatch Mode is On for a pod whose own Auto-Dispatch toggle is off, that pod still self-serves the plain waterfall pick; only a pod with both switches on lets Elise book the tech's real calendar herself.
• If a move is refused, it is because the ticket carries time already invoiced on a live invoice; void that invoice first, then move it.

Questions this page answers