Below 10 desk people, the model puts dispatch with a team lead drawn from the pool. It adds a dedicated dispatcher at about 10. Your ticket assignment process still needs a named decision-maker: someone chooses the next eligible job, approves exceptions, and makes sure an awkward ticket has an owner.
I test an assignment rule by asking what it does to the board on Monday morning. A technician finishing work should know which ticket to take without shopping for a favourite. A ticket nobody can take should lead to a decision by the dispatch owner.
Give the Dispatch Owner the Assignment Decision
Separate ownership of the queue from ownership of the technical work. The dispatch owner decides where work goes. The assigned technician owns the agreed next action and reports when something prevents it.
On a smaller desk, the dispatch owner can be the working lead. Name the person covering that duty and the person who takes over when they're unavailable. Keep both names visible where the team actually gets its assignments.
This isn't a new staffing allowance. The model's smaller-team rule uses capacity within the existing pool, without adding a dispatch stipend, headcount, or separate allowance of minutes. Check whether the real workload leaves room for that duty rather than assuming the model guarantees spare time.
The owner or service manager remains responsible for making the arrangement workable. If the lead can't both carry technical work and make assignment decisions, they need a workload decision. Replacing a named dispatcher with the words shared responsibility won't make the work fit.
Publish the Rule for Taking the Next Ticket
Use a visible assignment order that starts with your agreed priority and service commitments. Within the work a technician is qualified and authorized to handle, use age to choose the next eligible ticket unless the dispatch owner records a reason to change the order. Publish the rule so a technician can apply it and a lead can explain an exception.
Don't set a universal response deadline in this rule. Use the commitments you've actually made to each client and the impact assessment your desk has recorded. A ticket marked urgent without enough information needs triage, not automatic promotion ahead of every other client.
I'd allow technicians to pull work only from the eligible set that rule produces. Work outside their skills or access stays visible to dispatch. Finishing an easy ticket doesn't entitle someone to skip an older eligible job because its description looks unpleasant.
A queue isn't a pick-and-mix counter. If a technician needs to depart from the order, they tell the dispatch owner why. The exception belongs in the ticket or assignment record so the next person can see the decision.
Make Declining a Ticket Produce a Next Action
A technician who can't safely take a job should say what is missing. The dispatch owner then resolves the assignment problem instead of returning the ticket to an unexplained pile. Give the team a short reason list they can use consistently.
| Reason the Technician Cannot Take It | Dispatch Decision | What Stays on the Record |
|---|---|---|
| Required skill is missing | Assign a capable resource or arrange supported work | Name the required skill and the next owner |
| Approved access is missing | Arrange the authorized access path or assign someone already authorized | Name the access dependency without copying secrets into the ticket |
| Existing committed work conflicts | Choose which commitment takes precedence and communicate the change | Record which work moves and who follows up |
| The request is too unclear to assign | Name someone to obtain the missing information | Record the question and who will ask it |
This gives you evidence before you call the behavior cherry picking. A repeated access problem needs an access decision. A technician repeatedly bypassing eligible work without a valid reason needs a direct conversation about the rule.
Erick Simpson describes investigating first-line work that kept reaching senior technicians before recommending another hire. In his account, assignment was part of the investigation, alongside what staff needed to complete the work. Use that as a prompt to inspect rejected assignments rather than treating a crowded senior queue as a complete hiring brief.
Keep Ownership During a Transfer
A request for help doesn't automatically transfer responsibility. Keep the current technician responsible for the next action until the receiving technician accepts it or the dispatch owner explicitly reassigns it. If that person is unavailable, the dispatch owner makes the handoff rather than waiting for an acknowledgement that can't arrive.
Say a first-line technician needs a specialist to investigate a recurring connectivity fault. The first-line technician records what's been checked and the specific help needed. Dispatch identifies the specialist and confirms who will update the client while that work happens.
The specialist might advise the current owner, or take the ticket. Those are different decisions. Put the chosen arrangement in the record so both people don't wait for the other to call the client.
For a severe incident, use the incident lead and the appropriate specialist path. Don't make staff pass it through a routine queue to satisfy an assignment rule. The dispatch owner should record the exception and check what happens to the ordinary work displaced by it.
Give Stalled Work Somewhere to Go
A ticket is stalled when its next action can't proceed under the current assignment. Define how the desk flags that condition and how the dispatch owner receives it. Use your service commitments to decide when intervention is needed rather than borrowing an arbitrary age limit.
The dispatch owner resolves the immediate assignment or takes the dependency to the service manager. If the obstacle is capacity across the desk, the service manager decides what to defer or cover. If it's a client decision, name the person who will obtain it and keep the waiting work visible.
Broken instructions deserve their own follow-through. Tas Gray describes asking staff to raise a specifically categorized ticket when they encounter incorrect documentation, creating a visible correction queue. That is his workflow suggestion; you can use the same principle to give an assignment failure an owner beyond the immediate workaround.
Check Whether the Rule Changes the Work
I don't need a workflow-optimization initiative to find out who takes the ticket. I need the assignment record to show the next action and its owner. Put these checks into the desk's existing review.
- The dispatch owner checks skipped eligible work and the reasons for assignment exceptions.
- The team lead checks whether missing skills or access repeatedly prevent work from reaching the right resource.
- The assigned technician keeps the next action current and raises a blocker before quietly abandoning the work.
- The service manager checks displaced commitments and unresolved capacity decisions.
- The MSP owner checks whether staffing follows ticket volumes and labor minutes rather than a feeling that everyone looks busy.
Don't judge the rule only by completed-ticket counts. Read the jobs that remain unassigned and the transfers that haven't been accepted. A higher completion count can coexist with difficult work left untouched.
Start by applying the rule to your actual unassigned work. Name the dispatch owner, identify the next eligible ticket, and follow every exception to a named decision-maker. If the team still can't tell who acts next, fix that part of the process before adding another status.
mspoutpost.com/articles/ticket-assignment-process-who-takes-the-next-job
Written by Megan Friesen
MSP Outpost publishes information, not legal, financial, insurance, tax or compliance advice, and reading it creates no professional relationship. For decisions about your business, talk to a qualified professional.