On-Site Service Request & Dispatch SOP
An on-site service request and dispatch SOP for Insatech: ServiceDesk intake and triage, the remote-versus-on-site decision, technician assignment, equipment preparation, the customer visit and the service report that closes every case.
What the On-Site service request & dispatch SOP process is
Every customer contact into Insatech's service business, whatever the medium, lands in one place: ServiceDesk. That is deliberate. A customer with a drifting flow reading, a customer whose transmitter has stopped responding, and a customer asking when their next calibration is due are all, from the customer's side, just "calling Insatech about an instrument problem," and they should not need to know in advance which of those is a five-minute phone fix and which needs a technician standing in front of the equipment. That judgment belongs to ServiceDesk, made once, at intake, through "Technical triage against symptoms and service history" and the "Remote support sufficient, or on-site visit required?" decision that follows it. Everything this SOP covers exists to make that one call well: not fast for its own sake, and not cautious for its own sake either.
The decision is the SOP's real content, and it cuts both ways. Dispatching a technician for something a phone call would have fixed costs a service vehicle, a day's travel and a technician's hours the customer did not need to pay for, and it is the failure mode ServiceDesk is best placed to catch, since the symptoms are usually already in the ticket by the time triage finishes. The opposite failure is worse: talking a customer through a suspected sensor failure, a live safety concern, or anything that needs hands-on access to ATEX-rated equipment in a classified area, because nobody wanted to book a visit. "Remote support sufficient, or on-site visit required?" is written as a real branch with two real destinations, "Resolve remotely with customer over phone or portal" on one side and "Assign technician" on the other, precisely so that call has to be made explicitly, on the symptoms in the ticket, rather than defaulted into by whoever is holding the phone.
The two branches do not stay separate forever, and neither one is a guaranteed straight line to close. A remote fix skips "Confirm required spares are in stock and pick for the job", "Prepare test equipment and load service vehicle" and the visit itself entirely, jumping straight from "Resolve remotely with customer over phone or portal" to "ServiceDesk closes ticket and confirms resolution logged." An on-site visit runs through "Write service report on-site and obtain customer sign-off" into a second decision, "Issue fully resolved during visit?", because not every job finishes in one trip: a part on order, an isolation the customer's process cannot grant that day, or a fault that needs a second specialist all show up here as "Follow-up needed" rather than a quietly reopened ticket, and route to "Log outstanding work and schedule follow-up visit", which loops back into "Assign technician" instead of starting a disconnected second case. Both eventual outcomes, a phone resolution and a fully resolved visit, converge on the same "ServiceDesk closes ticket and confirms resolution logged" row. That convergence is what keeps a phone resolution from becoming an undocumented favor: it closes through the same ServiceDesk record as a dispatched visit, on the same ticket, with the same owner. People and Workload are set on every step across both branches and the follow-up loop, so the workload BI panel can show, for a week where the phones are busy, whether that is showing up as Rachel Foster's ServiceDesk hours, Thomas Reid's field hours, or both.
What this flowchart covers
In this template
- Intake and triage, from "Customer contacts ServiceDesk (phone, email or portal)" through "Log ticket and capture symptoms, instrument and process context" to "Technical triage against symptoms and service history"
- The remote-versus-on-site gate itself: "Remote support sufficient, or on-site visit required?", which either resolves the case at "Resolve remotely with customer over phone or portal" or sends it on to dispatch
- Dispatch preparation across the ServiceDesk, Field Service and Logistics lanes: "Assign technician", "Confirm required spares are in stock and pick for the job", "Prepare test equipment and load service vehicle" and "Confirm appointment window, site access and PPE requirements with customer", all before anyone leaves for site
- The visit, its record, and the follow-up gate: "Customer visit: assess and resolve issue on-site", "Write service report on-site and obtain customer sign-off", and "Issue fully resolved during visit?", which either clears the case for close-out or routes it to "Log outstanding work and schedule follow-up visit", looping back into "Assign technician" instead of opening a second, disconnected ticket
- The close-out both branches share: "ServiceDesk closes ticket and confirms resolution logged" closes a remote resolution the same way it closes a fully resolved on-site visit, on the same ticket
- Named owners and hours on every row via the People and Workload columns, so the workload BI panel can show Rachel Foster's ServiceDesk hours running the full width of the chart while Thomas Reid's field hours cluster in dispatch preparation and the on-site visit
When to use this template
- You're standardising how Insatech's ServiceDesk decides remote support versus a technician visit, and want that call fixed on one chart instead of left to whoever happens to pick up the phone
- A customer has questioned whether a truck roll was actually necessary, and you want a documented triage step that shows what the decision was based on
- You're onboarding a new ServiceDesk coordinator or dispatcher and need a reference for exactly what triage covers before the remote/on-site call, and what has to happen before a technician leaves for site
- You're checking whether the same technician is booked against two dispatched visits in the same week
- A site visit closed without a signed service report reaching the file, and you want one place in the process where that gets caught before the ticket closes
How it works
Replace the lanes with your actual service roles
This chart uses ServiceDesk, Field Service and Logistics. If Insatech splits dispatch coordination from ServiceDesk triage, or a separate stores function owns spares, give that role its own lane rather than folding it into ServiceDesk: the handoff is usually where a step gets assumed done by someone who assumed someone else did it.
Put your own remote/on-site criteria on the decision
"Remote support sufficient, or on-site visit required?" needs a stated list of what tips each way, not just "use judgment." Write the actual criteria, symptom patterns, ATEX or classified-area involvement, safety indicators, into the row's comment field so triage does not depend on which coordinator is on shift.
Set People and Workload on every row before you rely on the BI panel
The workload panel can only total hours for rows that carry them. Fill in People and Workload for each step as you adapt the chart, using realistic effort hours rather than elapsed time, so a week with several dispatches actually shows up as a busy week for the right person.
Decide what a spares check means for your product lines
"Confirm required spares are in stock and pick for the job" only works if it is checked against the instrument type and fault pattern already in the ticket. If Insatech's stores are organised by product line or by customer contract, say so in the row rather than leaving it as a generic stock check.
Name who can close a ticket without a signed report
"ServiceDesk closes ticket and confirms resolution logged" is the point both branches converge on. Decide, and write down, whether closure is ever allowed to happen without "Write service report on-site and obtain customer sign-off" reaching the file first, so that is a policy on the chart rather than an exception someone makes under pressure.
Frequently asked questions
What decides whether a case is handled remotely or a technician is dispatched?
The "Remote support sufficient, or on-site visit required?" decision, made at the end of "Technical triage against symptoms and service history." It weighs the symptoms and the instrument's service history: a configuration issue or a wiring fault visible on a live reading usually resolves by phone, while a suspected sensor failure, a safety concern, or anything needing hands-on access to ATEX-rated equipment goes on-site.
What happens after ServiceDesk decides a visit is needed?
The case moves into the Dispatch preparation stage: "Assign technician", "Confirm required spares are in stock and pick for the job", "Prepare test equipment and load service vehicle", and "Confirm appointment window, site access and PPE requirements with customer", all before the technician leaves for the visit itself.
Does a remotely resolved case skip the service report?
Yes. "Resolve remotely with customer over phone or portal" goes straight to "ServiceDesk closes ticket and confirms resolution logged" without touching dispatch preparation or the on-site report, since no technician was sent and there is nothing written on-site to sign. The remote resolution itself is what gets logged.
Who closes the ticket, ServiceDesk or the technician?
ServiceDesk does, in both branches. "ServiceDesk closes ticket and confirms resolution logged" is the single row a phone resolution and a fully resolved on-site visit both close through, so every case ends up on the same record regardless of which branch handled it.
What happens if the technician can't fully resolve the issue in one visit?
"Issue fully resolved during visit?" catches that on-site, right after the report is written. A "Follow-up needed" answer routes to "Log outstanding work and schedule follow-up visit", which loops back into "Assign technician" rather than closing the ticket, so a job that needs a part on order or a second visit stays on the same case instead of becoming an untracked reopen later.
How is this different from the Emergency Instrument Failure / Troubleshooting SOP?
This SOP assumes the customer has already identified the problem well enough for triage to weigh remote against on-site calmly. The emergency SOP covers the opposite situation, a process that is degraded right now, where which instrument is even at fault is not yet known and the urgency assessment has to happen before any remote/dispatch call, not as a routine triage step.
Can this SOP be used for a customer with a pure phone-support contract and no on-site component?
Yes. Every case still runs through "Remote support sufficient, or on-site visit required?" for the record, but for that customer the on-site branch is never taken. Keeping the decision on the chart, rather than removing it, is what shows an auditor the case was assessed rather than assumed.