Ticket Queue Management for a Small Pooled MSP Desk

Count Desk Staff Before Designing the Boards

Total company headcount doesn't tell you how many people can pick up a support ticket. The model separates desk work from account management, vCIO work, centralized services, projects, sales, and administration. Start with the roster that actually covers the desk.

The model uses a pool for smaller desks. It calculates desk staffing from tickets, labor minutes by resolving tier, and residual alert work, then rounds up to whole people with a minimum of two. It doesn't give every tier its own staffed queue.

Below ten desk people, the model has a team lead dispatch from the pool. That person needs authority to assign work, clarify priorities, and arrange cover. Check the lead's actual workload before assuming the model's allowance fits your operation. Naming the lead doesn't create more working hours.

For the example's four-person desk, I'd start with a common support board that the lead can inspect as a whole. Choose the structure from the work that must be seen and assigned, rather than from the departments you hope to have later.

Separate Work Only When the Ownership Changes

A board should have a clear purpose, a responsible person, and a rule for entering and leaving it. Write those down before adding it to the PSA. If the same people would watch the same tickets under the same commitments, test a saved view or category instead, where your PSA supports it.

Keep incoming support requests and active support visible together. Give project work a planning route with a project owner and an agreed handover to service. Don't hide a support request on a project board because the client also has a project underway.

Recurring internal work, such as documentation corrections, also needs a named owner. It may fit within an existing board with a clear classification. Add another board only when you can explain who will maintain it and how work will return to the shared picture.

On MSP Mastery, Tas Gray describes asking staff to raise a ticket with a defined type, subtype, and item when they find an outdated process. That gives the documentation owner a visible correction queue. It's one practitioner's method; you can borrow the explicit route and owner without copying the rest of his setup.

Make the Next Action Visible

I'd use support views that answer a working question. The labels below are a proposed arrangement, not a requirement to buy a PSA feature or create separate boards. Confirm what your current system can show before changing the team's routine.

Keep the assignee when a ticket moves into Waiting. Record what was requested, from whom, and when someone will follow up. A status records a condition; it doesn't take responsibility for the client update.

Separate waiting reasons if they help the lead act. Waiting for a vendor answer and waiting for an internal approval need different conversations. Don't add statuses that nobody can distinguish when reading the ticket.

Keep Escalation Inside the Pool

When a technician needs help, have them record what they tested, what happened, and the specific decision or skill they need. The lead then arranges the next person. Keep the current owner responsible until the handoff is accepted and recorded.

A category can describe the skill needed without becoming a permanent barrier between technicians. The model's tier-based labor assumptions describe the work and its cost. They don't require a ticket to visit a succession of tier boards before someone can resolve it.

For work needing restricted access, check the PSA's actual permissions and use the approved handling route. The common board needs enough information to track responsibility without exposing details to people who aren't authorized to see them. Have the person responsible for access confirm the configuration.

Review the Board Against Commitments

Set review and follow-up times from your client commitments, coverage hours, and observed workload. The model doesn't supply a universal stale-ticket age or dispatch interval. The lead should be able to explain when each view is checked and who covers it during an absence.

Use a short check with a person named on every line.

• The team lead checks new and unassigned work, confirms the next action, and assigns a technician who can take it.
• Each assigned technician checks their active and waiting work, updates the client where needed, and records the next follow-up.
• The team lead checks requested handoffs and confirms the receiving technician has accepted them.
• The lead's named backup checks coverage during absence and records any work that must be reassigned.
• The owner or service lead reviews missed commitments, repeated transfers, and work left outside the shared picture, then assigns corrective action.

An old ticket can be waiting on an agreed future event. A recently edited ticket can still lack a useful next step. Read the next action and the commitment as well as the activity timestamp.

Remove Queues That Have No Job

Before retiring a queue, inspect everything in it. Give each live ticket a destination, an owner, and a next action. Check intake rules, recurring tasks, reports, and integrations that might still send work there. Have the PSA administrator verify those routes before switching them off.

Then test a request from arrival through assignment, waiting, escalation, and closure. Ask the lead and backup to find it without help from the person who configured the board. If they can't, adjust the route or the view before asking the whole team to use it.

Keep the structure while it helps the desk see and own the work. Add a board when a real difference in responsibility requires one. Start with your current unowned tickets: each needs a person and a next action before it needs another place to sit.