> ## Documentation Index
> Fetch the complete documentation index at: https://helpdocs.getthread.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Dispatcher Intake

> Attended chat intake for dispatchers — describe the issue conversationally and get back a properly created ticket: KB/docs/history checked, board/type/priority set, summary written, first-touch note attached.

<Info>
  **Category:** Triage & Routing · [View source ↗](https://github.com/bryan-getthread/skills/blob/main/skills/triage-and-routing/dispatcher-intake/SKILL.md)
</Info>

**Connectors:** `IT Glue` `Hudu`

**Role:** [Dispatcher](/start-here/roles/dispatcher)

**Outcome:** Faster Resolution & Response, Time & Cost Savings (Capacity)

**When to use:** A dispatcher on a call ("Someone from \<client> just called, their warehouse label printer won't print, started this morning"), walk-up/hallway intake where a tech relays an issue verbally, or a phone-heavy desk that wants every call to land as a consistent classified ticket. This is the step before new-ticket-first-touch: no ticket yet, a human relaying an issue live.

**Run it:** on one new intake (a live conversation, before any ticket exists).

## Prompt

```
Conversational ticket creation for the person answering the phone: the dispatcher describes the
issue in their own words, you ask the one or two questions that matter, check documentation and
history while they talk, and create a well-formed ticket with a research-backed first note.

1. Take the description as given, then ask only for what's missing and load-bearing: which
   client, who reported it (contact), what's affected, since when, how urgent it feels. One
   compact round of questions — dispatchers are usually mid-call.

2. Resolve entities as you go: search clients for the client, search contacts for the reporter
   (offer the closest matches rather than guessing between similar names). Never create on an
   unresolved client or contact match.

3. Research in parallel with the conversation:
   - Search tickets: similar past tickets for this client (same symptom/device) and any OPEN
     ticket that might make this a duplicate — if a likely duplicate exists, say so and let the
     dispatcher decide before creating anything. The duplicate check is mandatory.
   - Search the knowledge base, and IT Glue / Hudu documentation where enabled: known fixes,
     client-specific runbooks, environment notes. These connector searches are available only
     when those integrations are enabled; skip silently and rely on the KB + ticket history
     when absent.

4. Propose the ticket before creating it: board, type/subtype per the intake-classification-tree
   logic, priority with a one-line justification, a summary line in the desk's format, and a
   clean description from the dispatcher's words. The dispatcher confirms client, contact, and
   priority before the ticket is created.

5. Create the ticket with the confirmed fields, then leave the first-touch research note (plain
   text): similar past tickets found (numbers + one-line outcomes), relevant KB/docs references,
   and suggested first steps. The note cites only what searches actually returned — no invented
   KB articles, ticket numbers, or doc links; empty research → say "no similar tickets or docs
   found." Label the similar-tickets list as partial if history checks capped.

6. Hand back: ticket number, where it landed, and anything the dispatcher should tell the caller
   (expected next step — no time promises unless the desk's SLA config states one).

Notes are plain text (PSA-safe). The ticket description preserves the dispatcher's factual
content — clean it up, don't editorialize it.
```


## Related topics

- [Dispatcher](/start-here/roles/dispatcher.md)
- [Notion Intake Forms](/skill-library/connectors/notion-intake-forms.md)
- [Intake Classification Tree](/skill-library/triage-and-routing/intake-classification-tree.md)