Build an MSP service desk command center

A good MSP service desk command center is not a wall of charts. It is an operating system for the day.

Service managers and dispatchers need to know four things quickly: how much work is active, which tickets are stuck, where SLA exposure is building, and what actions should happen next. If those answers live in separate PSA queues, spreadsheets, Teams messages, and individual technician calendars, the desk runs on memory instead of visibility.

The goal is not to create another report. The goal is to give the person running the desk a live view of pressure, risk, and available moves.

Start with the decisions the command center must support

Before choosing dashboard widgets, define the decisions your team makes repeatedly during the day.

For most MSPs, the key service desk decisions are:

• Which ticket should be worked next?
• Which technician has capacity or the right skill?
• Which client commitment is at risk?
• Which ticket is waiting on us, not the client or vendor?
• Which queue is accumulating low-visibility work?
• Which escalation needs a manager, not just another note?
• Which dispatcher action should happen before the next check-in?

A command center should be designed around these decisions. If a metric does not help someone act in the next hour, it belongs in a report, not the live service desk view.

This is where many PSA dashboards fall short. They show counts, but not operational meaning. A queue with 74 open tickets is not useful by itself. A queue with 12 tickets breaching in the next two hours, 5 unassigned priority incidents, and 3 tickets untouched since yesterday is useful.

Show live workload by status, ownership, and time pressure

The first layer of an MSP service desk command center is workload. Not monthly ticket volume. Not last week’s close rate. Live workload.

At minimum, service leaders should see current work by:

• New and untriaged tickets
• Assigned but not started tickets
• Active tickets in progress
• Waiting on client
• Waiting on vendor
• Waiting on internal approval
• Scheduled work
• Escalated work
• Tickets due or breaching today

The point is to separate raw backlog from actionable backlog. Fifty open tickets may be fine if most are scheduled project follow-ups or client-waiting items. Fifteen open tickets may be dangerous if they are all unassigned and aging.

Live workload should also show technician load in practical terms. Avoid only counting assigned tickets. One technician may have 18 small follow-ups. Another may have 4 tickets that will consume the day. A useful view combines ticket count, priority, estimated effort, appointments, and SLA exposure.

Corei’s operational dashboards are built for this kind of service view: not just reporting what happened, but helping a manager understand what the desk is carrying right now.

Define what counts as a stuck ticket

Stuck tickets are one of the biggest sources of client frustration because they often do not look urgent in a queue. They are not always breaching SLA. They are not always high priority. They simply stop moving.

A command center should identify stuck tickets using rules that fit your desk. Common stuck-ticket signals include:

• No technician update for more than one business day
• No client-facing update after internal work occurred
• Ticket reassigned more than twice
• Ticket reopened after closure
• Ticket in waiting status with no follow-up date
• Ticket has an internal note asking for help but no escalation
• Ticket is blocked by procurement, vendor, or approval
• Ticket is linked to repeat issues for the same user or site

The important part is to distinguish stuck from waiting. A ticket waiting on a client with a clear next follow-up is controlled. A ticket waiting on a client with no next action is unmanaged.

Your command center should group stuck tickets by the reason they are stuck. That allows dispatchers and service managers to act in batches. For example, a dispatcher can clear missing follow-up dates. A service manager can review repeat reassignments. A procurement coordinator can unblock hardware-dependent tickets.

If your PSA supports automation, stuck-ticket detection should trigger a suggested action, not just a red icon. Corei’s autonomous tickets can help classify, route, and summarize tickets so the desk sees why work is stalled instead of manually reading every thread.

Make SLA exposure visible before breach

SLA reporting after the fact is useful for accountability. It is not enough for daily operations.

A command center should show SLA exposure in forward-looking windows:

• Breaching in the next 30 minutes
• Breaching in the next 2 hours
• Breaching today
• First response at risk
• Resolution target at risk
• Client-specific commitment at risk
• Priority mismatch suspected

This matters because many SLA misses are not discovered when they become risky. They are discovered when they have already failed.

The command center should also show why exposure exists. Is the ticket unassigned? Assigned to someone in meetings? Waiting on a triage decision? Misclassified priority? Scheduled too late? Blocked by another team?

The best view combines time remaining with action options. For example:

• Reassign to technician with available capacity
• Escalate to senior engineer
• Send client update
• Convert to scheduled onsite work
• Split request from incident
• Adjust priority with manager approval

A simple red-yellow-green SLA gauge can help, but the detail behind the gauge is what makes it operational. Corei’s live health gauges are designed to surface these pressure points so leaders can see where service is healthy, strained, or at risk.

Put dispatcher actions in the same view

Visibility does not improve service unless it changes behavior. That is why dispatcher actions belong inside the command center, not in a separate workflow.

A dispatcher should be able to work from a short list of recommended actions, such as:

• Assign unowned tickets based on skill and availability
• Rebalance overloaded technicians
• Escalate tickets with repeated reassignment
• Nudge technicians on tickets with no update
• Schedule follow-up for waiting tickets
• Contact clients where SLA exposure requires an update
• Move misrouted tickets to the right board or queue
• Flag tickets that need service manager review

This list should refresh throughout the day. Morning dispatch is different from the 2 p.m. service check. A command center should help the dispatcher run the desk in cycles: review pressure, take action, confirm movement, then repeat.

Corei’s dispatch capabilities focus on scheduling, capacity, and reassignment help, which are the practical levers dispatchers use when the desk starts to bend.

Separate manager view from technician view

A command center is for running the desk. It should not become the technician’s primary workspace.

Service managers and dispatchers need a cross-desk operating view. Technicians need a focused work queue that tells them what to do next, what context matters, and what needs updating. If technicians are forced to interpret the full command center, they lose time and attention.

Design the command center to answer management questions:

• Are we under control right now?
• Where is risk increasing?
• Who needs help?
• What work needs reassignment?
• Which clients need proactive communication?

Design the technician workspace to answer execution questions:

• What should I work on next?
• What is the client context?
• What has already been tried?
• What update is needed?
• What can be closed safely?

When these views are connected, managers do not need to interrupt technicians for status as often, and technicians do not need to hunt across boards for context.

Choose metrics that create action, not debate

The wrong metrics create arguments. The right metrics create movement.

For a command center, avoid vanity metrics that require too much interpretation during the day. Instead, prioritize operational metrics with an obvious owner and action.

Useful command center metrics include:

• Unassigned tickets by age and priority
• Tickets breaching within defined windows
• Tickets with no update beyond threshold
• Tickets waiting without follow-up date
• Technician load adjusted for meetings and PTO
• Reopened tickets by owner or client
• Escalations awaiting acceptance
• Tickets blocked by vendor or procurement
• New tickets by source, such as email, phone, chat, or alert

Less useful as live command center metrics:

• Monthly ticket volume
• Average close time across all ticket types
• CSAT trend without current ticket context
• Total open tickets without segmentation
• Technician utilization without schedule reality

Those metrics still matter. They belong in reporting and review meetings. The command center should stay focused on today’s operating decisions.

Include intake quality in the command center

Many service desk problems start before dispatch. Poor intake creates unclear tickets, weak priority decisions, unnecessary back-and-forth, and wrong assignments.

A strong command center should show whether intake is clean. Track items such as:

• Tickets missing client, contact, device, or site
• Tickets without category or type
• Phone calls not yet converted into tickets
• Chat requests awaiting triage
• Monitoring alerts grouped or suppressed
• Duplicate tickets for the same issue

This is especially important when work enters from many sources. Email, phone, chat, monitoring, and client portals all need to land in a consistent operating model.

AI can help here, but control matters. Intake automation should classify and summarize work while still allowing the MSP to define what the AI may do. For example, an AI phone intake workflow can capture the call, identify the client, summarize the issue, and create a ticket, while escalation rules remain under your policy.

Build around existing PSA data, then improve it

Most MSPs do not get to start from a clean system. Your command center has to work with the PSA reality you have: inconsistent statuses, old boards, uneven categories, and technicians who use notes differently.

Start by mapping current data into four operating buckets:

1. Workload: what exists and who owns it.
2. Stuck work: what is not moving.
3. SLA exposure: what may fail soon.
4. Dispatcher actions: what should happen next.

Do not wait for perfect data. Instead, use the command center to expose where process cleanup matters. If too many tickets are stuck because waiting statuses lack follow-up dates, fix that workflow first. If SLA exposure is caused by incorrect priorities, improve classification and intake rules.

For MSPs running ConnectWise Manage, Corei can run on top through a two-way ConnectWise integration, allowing teams to improve operational visibility without replacing everything at once.

Review the command center in daily operating rhythms

A command center is only useful if it becomes part of the desk’s cadence.

Consider these operating rhythms:

• Start-of-day review: backlog, overnight intake, staffing, and SLA exposure.
• Mid-morning dispatch check: unassigned work, first-response risk, and stuck tickets.
• Early afternoon rebalance: technician load, escalations, and client updates.
• End-of-day control check: waiting tickets, follow-ups, and tomorrow’s risk.
• Weekly service review: stuck-ticket patterns, SLA misses, intake quality, and staffing gaps.

The daily rhythm should be short and action-oriented. The weekly review can be more analytical.

If a metric appears every day but never changes a decision, remove it from the command center. If a dispatcher repeatedly asks the same question outside the system, add that answer to the command center.

Practical takeaway: build the first version in four panels

You do not need to build the perfect command center on day one. Start with four panels that match how the service desk actually runs.

Panel 1: Live workload

Show open work by status, priority, owner, and source. Include unassigned and untriaged tickets prominently.

Panel 2: Stuck tickets

Show tickets with no update, no follow-up date, repeated reassignment, reopened status, or unresolved blockers.

Panel 3: SLA exposure

Show tickets at risk in the next 30 minutes, next 2 hours, and today. Include first response and resolution exposure separately.

Panel 4: Dispatcher actions

Show recommended assignments, rebalances, escalations, follow-ups, and client updates.

Keep each panel tied to action. The command center should help the desk move work, not admire data.

An effective MSP service desk command center gives service leaders a live picture of operational pressure and gives dispatchers a clear path to reduce it. When workload, stuck tickets, SLA exposure, and dispatcher actions live together, the desk becomes easier to run and easier to improve.