# Route a new support ticket

Completed process documentation example. The screen labels, team roles, and routing rules are fictional training examples. Replace them with your own process before use. This document is an editorial example, not a customer case study or a measured AI-generation result.

## Document details

| Field              | Example                                                                                                 |
| ------------------ | ------------------------------------------------------------------------------------------------------- |
| Process owner      | Support lead                                                                                            |
| Performed by       | Teammate reviewing the support queue                                                                    |
| Version            | Example 1.0                                                                                             |
| Last verified      | Training example; validate in your own help desk before use                                             |
| Review trigger     | Routing rules, ticket fields, or team responsibilities change; readers repeatedly ask the same question |
| Source walkthrough | Add your team's current training recording                                                              |
| Maintained copy    | Add the link to your team's approved version                                                            |

## Purpose and result

Put a new request with the team that can handle it, while preserving the context the next person needs. The finished ticket has a receiving team, a saved internal note, and a place in the receiving queue.

## When to use this guide

Start: A new ticket appears in the Unassigned queue.

Scope: Ordinary product-use and billing questions from existing customer accounts.

Outside scope: Suspected security issues or widespread outages follow the team's separate incident process. Stop routine routing and contact the support lead through your incident channel.

## Before you start

- Access: Permission to view tickets, add internal notes, and assign a receiving team.
- Information: The customer's request and access to the account directory.
- Dependencies: The ticket is visible in the Unassigned queue.
- Rules: Use the team's maintained routing policy. The table below is an illustrative example.

## Steps and decisions

### 1. Identify the account and request

Open the oldest new ticket in Unassigned. Read the message and check the account against the customer directory.

Check: The account in the ticket matches the account in the directory.

Decision: If you cannot identify the account, leave an internal note describing the missing information and ask the support lead to review it before routing. Leave the ticket available for review.

### 2. Look for an existing conversation

Check the account's open tickets for the same request.

Decision: If one already exists, follow the team's duplicate-ticket procedure and link the records. Continue here when this ticket represents a new request. If you cannot determine whether it is a duplicate, ask the support lead before merging or closing anything.

### 3. Apply the routing rule

Use the request itself to choose the receiving team. An urgent-sounding subject line is not enough to classify the request.

| Request in this training example              | Receiving team or next action                        |
| --------------------------------------------- | ---------------------------------------------------- |
| Ordinary product-use question                 | Product Support                                      |
| Billing question                              | Billing                                              |
| Unclear request or missing account            | Support lead reviews before assignment               |
| Suspected security issue or widespread outage | Stop routine routing and follow the incident process |

Check: The chosen route matches the team's current policy. In your actual document, link to the maintained routing rules so readers can check the source.

### 4. Leave context and save the assignment

Add an internal note with a short description of the request, any relevant existing ticket, and the reason for the route. Choose the receiving team and save.

Example internal note: The customer asks how to change a saved report filter. No matching open ticket found. Routed to Product Support for product-use help.

Check: The note is internal and contains the information the next teammate needs. Follow the team's separate policy for customer-visible messages.

### 5. Check the result

Confirm that the receiving team appears on the ticket and the internal note was saved. Check that the ticket appears in that team's queue.

Decision: If saving fails or the ticket does not reach the receiving queue, keep it available for review and contact the support lead. Record the attempted route and what failed. An attempted assignment does not complete the handoff.

## Exceptions and escalation

- Missing account: Record the missing information internally and ask the support lead to review before routing.
- Uncertain duplicate: Follow the duplicate-ticket policy or ask the support lead before merging or closing a record.
- Suspected incident: Stop routine routing and use the team's incident process.
- Assignment failure: Keep the ticket available for review, record what failed, and contact the support lead.

Replace the support-lead and incident contact routes with your team's actual channels before publishing this guide.

## Completion check

- The right team owns the ticket under the current routing policy.
- The internal note is saved and explains the request and route.
- The receiving queue shows the ticket, so the next team can pick it up.

## Maintenance and change history

Owner: Support lead.

Review: Verify the guide when routing rules, ticket fields, or team responsibilities change, and when readers repeatedly ask the same question. Check all linked policies and walkthroughs during the review.

| Date            | What changed                                                                                  | Verified by        |
| --------------- | --------------------------------------------------------------------------------------------- | ------------------ |
| Before team use | Adapt the example, add real contact routes and policy links, and have a teammate try the task | Your process owner |

Example by Kommodo. Template and guidance: https://kommodo.ai/blog/process-documentation-template