Start with eight help desk ticket statuses, each tied to a next action and an owner. Treat that as a proposed working list, then remove any distinction your desk doesn't need. A shorter menu helps only if the receiving person knows what to do. Renaming Pending won't assign the work behind it.
My test is: what does this do to the board on Monday morning? The desk lead should be able to identify work that needs assignment and work waiting on a named decision. A technician should be able to pick up a ticket without asking what its status was meant to imply.
Choose States That Change the Next Action
Review the statuses you actually use before creating another set. For each one, ask what changes when a ticket enters it. Keep a distinct state when it changes the responsible person or the next action the team needs to take.
Record the ticket owner separately from its status. A waiting state can describe a dependency while the technician still owns the follow-up. Don't let a status change erase that responsibility.
Cut workflow optimization from the brief and name the failed handoff. A ticket sitting unassigned and a ticket waiting for a client answer need different actions. An extra label won't resolve either one unless someone accepts that action.
Use the proposed list below to test those distinctions. The automatic actions are configuration requirements to check in your own PSA, rather than claims that every product supplies them in the same way.
| Proposed Status | Meaning and Next Owner | Action to Configure and Test |
|---|---|---|
| New | The desk lead needs to triage the received request. | Make the request visible in the intake queue and notify the responsible role. |
| Ready | The request is understood and the lead must allocate the work. | Require the next action and show it in the assignment queue. |
| In Progress | The assigned technician is performing the next action. | Keep the owner visible and use the actual work record for progress reporting. |
| Scheduled | The technician owns work arranged for an accepted future slot. | Record the slot and show the due work to the person responsible. |
| Waiting for Client | The technician is waiting for a specific client decision or input. | Require the question and follow-up owner, then create the agreed reminder. |
| Waiting for Vendor | The technician is waiting for an identified supplier action. | Link the vendor case and schedule its next internal follow-up. |
| Resolved | The technician has recorded the result and the request needs the agreed verification or closure step. | Send the appropriate result update and route any further response for action. |
| Closed | The request has met the agreed closure procedure. | Retain the work record and test how a later client reply is handled. |
Give Waiting Work a Question and a Follow-Up
For a ticket waiting on a client, write the actual question in the work record. Send it through the agreed client route and record who follows up. The desk needs to distinguish a sent request from a decision that has actually arrived.
For a vendor dependency, retain the supplier case reference. Keep the internal owner and next follow-up visible even if the supplier uses a separate portal. Waiting for Vendor isn't a retirement plan.
Picture a ticket whose supplier has replied, but the reply landed in a mailbox nobody checked. The status still says waiting even though the next action belongs to your team. Test that return route and make the receiving technician responsible for checking the answer.
Use the service commitment to decide how time is measured. A status name doesn't authorize a pause in an agreed response or resolution measure. Have the service lead confirm the clock rules before changing the configuration.
Test the Entry and the Return Path
Choose a real workflow and create a clearly marked test request. Have the technician move it through the relevant states with the information the rules require. Check what the receiving person sees, rather than stopping at a saved configuration screen.
Test the client reply and vendor reply paths as well. Confirm that a new answer reaches someone who can act without silently clearing the ticket's context. If the product can't create the proposed reminder or route, agree an explicit supported alternative.
Keep automatic messages distinct from evidence of work. A status transition that sends an acknowledgement doesn't establish that a technician began diagnosis. Report the event that actually meets your service commitment.
Have someone other than the configuration author inspect the result. Give them the ticket and ask them to identify its next action. Correct any missing owner or misleading message before applying the change to normal work.
Keep the Pool Working Without Inventing Another Role
The model uses a pooled desk for smaller MSPs and staffs it from ticket work. Configure statuses so the team can route work to the capable technician who will take it. A status list doesn't by itself establish a need for another dispatcher.
Have the desk lead check unassigned work and overdue follow-ups through the board views the team uses. Make a failed automation visible in that review. Otherwise the rule can exist in configuration while the ticket never reaches its intended recipient.
Keep the review focused on an action someone can accept. If a technician is unavailable, name who takes the next step. A shared pool still needs an explicit owner for the individual ticket.
Change the List With the People Who Use It
Justin Esgar describes bringing his team into PSA sales demonstrations and asking for their reactions, while retaining the owner's tool decision. That's his practitioner selection account. I'd involve technicians in checking a status change too, without assuming a vote settles the service requirements.
Show the team what each retained state means using the tested request. Explain any renamed state and the information now required. Keep the current rules accessible where staff work, with the person responsible for maintaining them named.
When retiring an old state, check the tickets and automation that still depend on it. Decide their treatment before removing the option. A shorter list shouldn't strand existing requests in a state the team no longer understands.
Start with a ticket that waited because its next action was unclear. Correct that handoff and test its return path. Then use the same evidence to decide which status distinctions your desk actually needs.
mspoutpost.com/articles/help-desk-ticket-statuses-that-assign-the-next-action
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.