SERVICE GUIDE

Outsourced Help Desk for MSP

Choose an outsourced help desk by the ticket work it will own and the work your MSP will retain. Compare shared, dedicated and overflow services using the same users, applications, staffed hours, allowed actions and escalation route. Agree which team maintains client context and accepts tickets outside the supplier's scope.
Edited by Vasilii KaraUpdated Suggest a correction

Set the client-facing brand and communication rules in the white-label help desk guide. Compare quoted billing units, minimums and extra charges in the pricing guide.

Fit: the honest triggers

  • Volume outgrew the bench - tickets queue during business hours; hiring lags demand.
  • Coverage promise outgrew the roster - you sold extended hours; staffing them internally needs more seats than the workload justifies.
  • Tier 1 is consuming tier 3 - senior engineers doing password resets because there is no one else.
  • Key-person risk - support knowledge concentrated in one or two heads.

And the trigger to distrust: "support is a cost center, make it someone else's problem". Support is where your clients experience you. You can outsource the labor; the accountability does not move.

What exactly moves: ticket scope

Define the handoff in ticket terms, with written boundaries:

  • Included categories - password and account issues, how-to questions, known errors, standard software issues, hardware triage.
  • Tier boundary - where L1 ends: by task list, not by "complexity". A written catalogue of included actions per category.
  • Excluded categories - anything touching your clients' compliance, VIP users if you keep those, changes requiring your authority.
  • Channels - phone, email, portal, chat: which the provider staffs, during which windows.
  • Reopen and splitting rules - what counts as one ticket matters for both quality metrics and per-ticket pricing.

Shared, dedicated, overflow

All 3 models shown. Print includes the full comparison.

Dimension Shared queue Dedicated team Overflow
Who answers Pooled technicians across many MSPs Named technicians on your account Your team first; provider catches the rest
Context retention Depends on documentation and assignment continuity Depends on staff continuity and documentation Verify how retained context is shared with the provider
Continuity Verify pooling, backup and assignment Verify named-team continuity and backfill Verify both teams and handoff documents
Entry cost Compare quoted minimums and variable fees Compare seat commitments and absence cover Compare retained costs, provider fees and routing effort
Knowledge transfer burden Agree runbooks, permissions and acceptance before opening the queue Agree role training, documentation and absence cover Keep routing notes and changes current across both teams
Typical failure mode Generic answers; clients repeat themselves Team churn resets context Tickets bouncing without clear ownership
Management you keep QA sampling, documentation standards Define supervision: the supplier may manage delivery, or your MSP may direct the engineers Routing rules and seam monitoring

Compare working systems, continuity and supervision as well as price. Shared and dedicated arrangements both need maintained documentation; overflow also needs an accepting owner when work crosses between teams.

Match the purchase to the work you want to move

Dedicated describes resource allocation. It does not by itself say who manages daily work or owns the service outcome. The examples below separate reception, a support queue with a handback boundary, and an engineer directed by your MSP. Open each for the actual service conditions and questions to put in the proposal.

HelpDesk.tech / Concierge intake - reception and ticket creation

Ask in the proposal: Which requests become tickets, who accepts the technical work, and what happens when that owner is unavailable? Price reception and technical resolution as their own obligations.

Read HelpDesk.tech: Concierge intake - reception and ticket creation / Build an RFP for this service

Sherweb / Helpdesk

Ask in the proposal: Which support tier and task list govern this order? Agree who accepts a returned ticket, how the user is kept informed, and where approvals and final resolution are recorded.

Read Sherweb: Helpdesk / Build an RFP for this service

Flexis IT / AgilePOD - dedicated help desk engineer

Ask in the proposal: Who directs this engineer and reviews the completed work? Specify each shift, simultaneous resources, holidays and absence cover, and include the supervision your MSP keeps in the cost comparison.

Read Flexis IT: AgilePOD - dedicated help desk engineer / Build an RFP for this service

Write the accepting technical owner beside each contact route. If your MSP must resolve the request, supervise the engineer or accept work returned at a time limit, include that retained work in the price comparison. The desk versus staff augmentation guide compares the management responsibilities in more detail.

Knowledge transfer - the make-or-break

Agree how desk staff use your runbooks, client notes and known-error lists before a pilot. Check whether technicians can retrieve and apply the context needed for the agreed ticket types.

  • Inventory what documented knowledge exists per client; fix the worst gaps before cutover.
  • Agree the documentation platform and format - yours, as source of truth, so exit stays possible.
  • Define the feedback loop: provider technicians must write back what they learn, in your format, and someone must review it.
  • Shadow period: provider answers with your team watching, then alone with sampling. Entry and exit criteria per phase.

Quality sampling

A compliance percentage alone does not expose individual misses. Review exception details alongside the aggregate.

  • Set the sampling schedule and coverage for your ticket volume and risk. Assess resolution, tone, documentation and escalation judgment separately.
  • Track reopens, time to escalation and repeated requests for client context alongside satisfaction feedback. Review the underlying cases when a pattern changes.
  • Review escalations for necessity, the accepting owner and the context that traveled with the ticket. Increase review after a failed case or a change to staff, tools or routing.
  • Keep findings in an action list with the provider response, correction owner, due date and retest outcome.

Example ticket review

Illustrative ticket HD02: a consenting test user requests access assistance through the branded telephone channel. The desk must map the correct client, complete the approved identity checks, perform only the permitted reset and document the confirmation. An identity mismatch stops the action and sends an accepted escalation to the MSP. Business-application permissions remain outside this sample scope.

Assess identity, tenant mapping, action authority, technical accuracy, clarity, documentation and handoff as separate pass/fail/not-observed fields. A critical identity failure is not averaged away by clear communication. These are sample assessment criteria, not provider ratings. The help desk pilot supplies a balanced case set.

Escalation and client control

  • Named escalation receivers on your side, with windows and channels.
  • Severity rules the provider can apply at intake without calling you - plus the list of judgment calls they must never make alone.
  • Client-sensitive flags: VIPs, fragile relationships, compliance-bound clients - routed to you regardless of category.
  • Language and geography: put required languages, assigned staff countries and data-processing locations in the RFP. A company office address does not identify who handles your queue. Use the provider directory for service-specific team statements, then confirm the assignment in writing.

Security boundary

The desk touches client identities daily. Minimum bar: named accounts in your tenant, MFA, least privilege by task list, per-person audit trail, screening and training disclosures, incident notification terms, subcontractor transparency, and tested access revocation. For identity-sensitive work, request the account-recovery and approval procedure, including requests the desk must hold or escalate.

Transition plan

  1. Current workload measures first - current volume, first-contact resolution, backlog age - so you can tell whether things got better.
  2. Pilot segment - authorized internal tickets or a defined, consenting client group.
  3. Shadow, then reverse-shadow, then cutover with a rollback trigger you wrote down in advance.
  4. First-week and thirty-day reviews against the initial measures.
  5. Client communication where the experience visibly changes (hours, channels, voices).

Failure modes to test for

  • Context starvation - tickets answered correctly-but-generically; measure reopens and repeated requests for context. Countered by documentation discipline and sampling.
  • Seam drops - overflow and after-hours boundaries where tickets wait for an owner. Countered by mechanical routing rules and synthetic tests.
  • Escalation inflation - everything hard comes back to you, and you are now paying twice. Watch time-to-escalate and escalation rate trends.
  • Delivery changes - staffing or routing changes can affect results. Recheck failed or reopened tickets and sample the changed setup. Agree the review cadence and acceptance owner before launch.
  • Exit trap - ticket history and runbooks living in provider systems. Countered in the contract, before signature.

Vendor questions

  1. Which model is this, and what changes between shared and dedicated in staffing, context handling and price basis?
  2. Show me the included-actions catalogue for L1 at intake - not the marketing tier names.
  3. Where do my tickets live - my PSA or yours - and who owns history at exit?
  4. What languages and locations staff my window, per shift?
  5. What is your caller-verification procedure for identity-sensitive requests?
  6. How do you transfer and maintain client context, and in whose documentation platform?
  7. What does your quality reporting show beyond a compliance percentage - and can I audit raw tickets?
  8. Exit terms: notice, data return format, revocation proof, transition assistance.

Ask each candidate to mark the same included-action list, identify the accepting escalation owner and demonstrate the quality report you would receive. Keep unanswered tasks beside the quote so they remain visible during selection.

Next steps

Turn the guide into requirements

Turn missing answers into questions. Copy this checklist into your vendor request.

Before a proposal can be compared

0 of 8 complete

Your entries stay in this browser tab and are not sent to us. Copy, download or save a file before you leave.