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.
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.