Looking for On-Demand Tech Support?
Techmate has the boots-on-the-ground IT Support where and when you need it.
Schedule a Discovery CallWhen Should Your Service Desk Dispatch? An On-Demand IT Support Playbook
Quick answer: A dispatch playbook tells your service desk when to fix remotely, ship a replacement, guide a site contact, or send on-demand IT support. Base the call on whether the issue is physical, how many users are affected, shipping speed and downtime cost. Techmate’s onsite IT support services cover the dispatch option in 450+ US cities.
Every service desk faces the same decision many times a week: do we send someone? Dispatch too quickly and you pay for visits a remote session could have handled. Dispatch too slowly and a site sits offline while agents try one more reboot.
The second mistake is usually the expensive one. In ITIC’s 2024 survey, more than 90% of mid-size and large enterprises put the cost of a single hour of downtime above $300,000 (ITIC, 2024). A branch office is a fraction of that, but the logic holds: minutes spent debating a dispatch are minutes of lost work for everyone at the site.
An on-demand IT support playbook makes the decision consistent. This guide shows how to build one, with decision criteria, a scenario matrix, request templates and the alternatives to dispatch that are often faster and cheaper.
What are the four response options?
Every physical or site-level issue resolves through one of four paths. The playbook’s job is to route each issue to the right one quickly.
| Option | Best when | Tradeoff | Typical example |
|---|---|---|---|
| Fix remotely | Software, configuration or account issues | Cannot solve physical problems | VPN profile, mailbox, driver, port config |
| Ship a replacement | Single-user device failure; user can self-install | Shipping time; user must set up and return the old unit | Laptop that will not boot, failed headset or dock |
| Guided site contact step | Simple, safe physical action | Relies on a non-technical person following instructions | Power cycle a modem, reseat a cable, read a status light |
| Dispatch a technician | Physical work beyond what users can safely do | Cost and scheduling time | Switch swap, rack work, AV failure, multi-user outage |
Most desks already use all four. The difference a playbook makes is that the choice no longer depends on which agent picks up the ticket.
How do you decide whether to send an IT technician onsite?
Work through six questions in order. The first one that produces a clear answer usually decides the route.
1. Is the problem physical?
If remote diagnosis points to hardware, cabling or power, remote fixes will not work. Move to the other three options immediately instead of spending another hour on remote attempts.
2. How many people are affected?
A single user’s failed laptop can often wait a day for a shipped replacement. A whole site offline cannot. Neither can a shared resource that blocks a team, such as a conference room before a client meeting or a check-in kiosk.
3. How fast can a replacement ship?
Next-day shipping may be faster than scheduling a technician at a remote site. It may be slower than a same-day technician in a dense metro. Know your shipping cutoffs and your spares locations so agents are not guessing.
4. Can someone onsite do it safely?
Power cycling a modem is reasonable to ask of an office manager. Swapping a firewall is not. Define which guided steps are acceptable, and write them as short scripts with photos. See how to write an IT support policy for branch employees.
5. What does downtime cost?
A payment kiosk at a busy store or a clinic’s check-in system justifies faster action than a secondary printer. Tier your sites and devices by business impact in advance so the decision is a lookup, not a debate.
6. Is it part of a pattern?
Repeated issues at the same site may justify a technician visit to find the root cause, even if each individual issue could be handled remotely. Three “fixed remotely” tickets for the same access point in a month is a dispatch, not three successes.
What does a dispatch decision matrix look like?
Use this as a starting point and adjust thresholds to your environment, contracts and site tiers.
| Scenario | First action | Dispatch trigger |
|---|---|---|
| User laptop will not boot | Remote triage | Ship replacement; dispatch only if user cannot set up or data recovery is needed |
| Whole site offline | Remote check of ISP circuit and edge devices | Guided power cycle; dispatch in parallel if not resolved within the priority window |
| Single access point offline | Remote reboot or PoE port bounce | Dispatch if device does not recover; batch with other work if not urgent |
| Conference room AV down before a key meeting | Remote guidance to user | Dispatch immediately if the meeting is critical |
| Printer jam or error | Guided user fix | Dispatch if hardware fault or recurring |
| Switch showing hardware alarm | Remote diagnosis | Dispatch with a pre-configured spare |
| New hire starting at a branch | Ship pre-imaged laptop | Dispatch if multiple hires, docks or complex setup |
| Repeated tickets from one site | Review ticket history | Schedule a visit for root cause |
| Network closet UPS on battery | Check utility power and runtime remotely | Dispatch if runtime is low or the UPS failed self-test |
The escalation mechanics behind these triggers are covered in outsourced tech support escalation paths. For AV-heavy sites, our onsite AV IT support page outlines what a conference room visit typically covers.
How does the matrix change by site type?
The same scenario can land differently depending on the site:
- Law firm offices: conference rooms and printers used for filings carry higher urgency during business hours; after-hours work is often preferred for anything disruptive.
- Bank and credit union branches: teller workstations, check scanners and network edge devices are high-impact; access usually needs advance notice and an escort.
- Retail stores: point-of-sale and payment devices outrank back-office equipment; dispatch windows should avoid peak trading hours.
- Real estate and professional services offices: often have no onsite IT contact at all, so guided steps are less reliable and the dispatch threshold is lower.
When should you dispatch in parallel?
For critical outages, do not wait for remote options to fail completely. Start remote diagnosis and request a technician at the same time. If remote work fixes the problem, cancel the dispatch. The cost of a canceled request is usually far lower than extra hours of downtime. Check your provider’s cancellation terms so you know the cost in advance.
Define parallel dispatch narrowly so it does not become the default. A good rule: parallel dispatch applies to your top site tier when the site is fully offline, or when a revenue or client-facing system is down with no workaround. Everything else follows the normal sequence.
What should an on-demand IT support dispatch request include?
When the playbook says dispatch, the request should be complete. A technician who arrives with partial information spends the first part of the visit on the phone, and an incomplete request is one of the most common causes of a return trip.
| Field | Why it matters |
|---|---|
| Site address, onsite contact and access details | Badge desks, suite numbers and building hours stop more visits than technical problems |
| Symptom and troubleshooting already done | Prevents the technician repeating remote steps |
| Device identification (model, serial, rack location, port) | Lets the technician find the right device in a crowded closet |
| Parts status and tracking | Avoids arriving before the part does |
| Priority and business impact | Sets scheduling and escalation expectations |
| Remote engineer contact for configuration steps | Keeps configuration with your team while hands-on work happens onsite |
| Closeout requirements (photos, serials, test steps) | Defines “done” before the visit starts |
See IT field support services, step by step for the full request-to-closeout flow, and how Techmate dispatch works for how requests are matched to a technician.
How do you batch non-urgent work?
Not every physical issue needs its own visit. For low-priority items at the same site, such as a flickering monitor, a slow printer and a loose cable, queue them and send one technician for all three. Batching lowers cost per task and respects minimum billing increments.
A simple batching rule set:
- Tag tickets “batchable” when the issue has a workaround and affects one user.
- Hold batchable tickets per site until either three accumulate or a set number of business days pass.
- Attach batchable tickets to any urgent dispatch at the same site.
- Tell affected users the planned visit date so the ticket does not look abandoned.
Scheduled visits formalize this. See scoping recurring field IT work.
Why does writing the playbook down matter so much?
Because inconsistency, not lack of skill, causes most bad dispatch decisions. Uptime Institute’s 2026 outage analysis found that failing to follow established procedures was the top driver of human-error outages, and that 57% of respondents said their most recent major outage cost more than $100,000 (Uptime Institute via Business Wire, 2026). That research covers data centers, but the lesson carries to branch IT: procedures only help if they exist, are short enough to use and are actually followed.
Common playbook mistakes to avoid
- Too long to use. If an agent needs ten minutes to find the right rule, they will skip it. Keep the matrix on one page.
- No site tiers. Without a list of which sites and devices are critical, every outage gets argued from scratch.
- Guided steps without scripts. “Ask the office manager to check the router” fails when nobody knows which box is the router. Use photos and labels.
- No cancellation rule. Teams avoid parallel dispatch because nobody knows who approves the cost. Name the approver.
- Never reviewed. Thresholds set in year one rarely fit the site count and device mix in year three.
How do you keep the playbook current?
- Review dispatch decisions monthly: which dispatches were not needed, and which were delayed?
- Update thresholds based on real outcomes, not on the loudest ticket of the month.
- Add new scenarios as new equipment, sites or vendors appear.
- Train new service desk staff on the playbook during onboarding.
- Share it with your on-demand IT support provider so both sides apply the same criteria.
How does on-demand IT support fit into a dispatch playbook?
On-demand IT support is the dispatch option in your playbook: the IT field technician you send when remote, shipping and guided options will not work. It suits distributed companies that cannot justify staff at every site but still need hands onsite when a closet, desk or conference room fails. If you are weighing it against a fully managed model, see on-demand vs managed IT. For tasks your own engineers direct step by step, smart hands IT services are often the right fit.
The bottom line
A dispatch playbook turns a judgment call into a repeatable decision. Define when to fix remotely, ship, guide a site contact or dispatch an on-demand technician. Use criteria based on the physical nature of the problem, impact, shipping speed, onsite ability and downtime cost. Dispatch in parallel for critical issues, batch the rest and review regularly.
Techmate supports service desks with more than 7,000 vetted technicians across 450+ US cities, a 97% resolution rate and a 4.7 out of 5 CSAT. Contact us to align your playbook with dispatch options.
Frequently Asked Questions
When should a service desk send a technician onsite?
Send a technician when the issue is physical and cannot be solved remotely, shipping a replacement is not practical, and no one onsite can safely perform the needed step. High downtime cost or a pattern of repeat tickets at one site also justifies a visit, even when each individual issue looks minor.
Should I ship a replacement or send a technician?
Shipping usually works for single-user devices the user can set up, such as a laptop or dock. Send a technician for multi-user issues, network equipment, complex setups, data recovery, or when shipping would take longer than a scheduled visit. Know your shipping cutoffs so agents can compare the two quickly.
What is parallel dispatch?
Parallel dispatch means starting remote troubleshooting and requesting a technician at the same time for critical outages, then canceling the dispatch if the remote fix works. Limit it to your most important sites and systems, check your provider’s cancellation terms, and name who approves the cost so agents do not hesitate.
Can office staff help with IT troubleshooting?
Yes, for simple and safe steps such as power cycling a modem, reseating a cable or reading a status light. Give them short scripts with photos and labeled equipment. Anything involving network equipment replacement, rack work, electrical work or configuration should go to a trained technician.
How do you reduce unnecessary IT dispatches?
Use a written playbook with clear criteria and site tiers, improve remote diagnostics and out-of-band access, ship replacements where practical, and batch non-urgent tasks into scheduled visits. Review unneeded dispatches monthly and adjust thresholds based on what actually happened rather than on assumptions.
What should an IT dispatch playbook include?
It should include the four response options, decision criteria, site and device tiers, a scenario matrix, parallel dispatch rules with a named approver, required dispatch request fields, batching rules, guided-step scripts for site contacts, and a monthly review process. Keep the core matrix to one page.
How fast can on-demand IT support be dispatched?
It depends on site location, priority, building access and whether parts are already onsite. Urgent requests are typically handled differently from scheduled work, which is booked in advance. Ask any provider how they set arrival windows by priority and city, and build those windows into your playbook’s triggers.
Want a second set of eyes on your dispatch rules? Book a free 30-minute IT support audit and we will review where your service desk sends, ships or waits, and what to change.
