On-site service request and dispatch process map

What is in this map

15 steps across 3 swimlanes and 5 phases, with 2 decision points.

Swimlanes (who does the work)

ServiceDesk, Field Service and Logistics

Phases (left to right)

Intake, Triage & decision, Dispatch preparation, On-site visit and Close-out

Why map this process

The map treats how the customer contacted ServiceDesk, phone, email or the portal, as irrelevant to what happens next, and puts every channel into the same queue at row 1. That is a deliberate simplification: the moment three intake channels start behaving differently downstream, a technician has to learn three versions of the same process depending on how the ticket arrived, which is exactly the kind of inconsistency a swimlane map is supposed to make visible and force out.

Confirming spares and test equipment before the technician leaves, rather than discovering a gap on site, is the map's answer to the single most expensive mistake a dispatch process can make: a technician driving to a customer's site and back again for a part that could have been checked against the ticket at dispatch. Picking spares 'against the customer's instrument type and the fault pattern already on the ticket' rather than a generic kit is the detail that makes that check worth doing.

Every step in the map

This is the spreadsheet behind the diagram. The numbers in “Goes to” are row numbers, which is exactly what the editor’s “Line to” column holds — so you can read the flow here and retype any part of it.

The decision points

Every branch in the map, with the label on each outgoing line. These are the questions the process has to be able to answer.

• 4. Remote support sufficient, or **on-site visit** required?

  Owned by ServiceDesk · Triage & decision

  • Remote → step 5
  • On-site → step 6

• 12. Issue **fully resolved** during visit?

  Owned by Field Service · On-site visit

  • Resolved → step 14
  • Follow-up needed → step 13

Notes on specific steps

These notes travel with the map. In the editor they live in the Notes column and appear when you open a box.

1. Customer contacts ServiceDesk (phone, email or portal)

Phone, email and the customer portal all land in the same queue. How the customer reached ServiceDesk does not change what happens next, only what gets typed into the ticket first.

4. Remote support sufficient, or **on-site visit** required?

The busiest gate on this chart. Symptoms that describe a configuration drift, a wiring fault visible on a live reading, or a documented calibration due date usually resolve by phone. Symptoms describing a suspected sensor failure, a process safety concern, or anything needing hands-on access to classified or ATEX-rated equipment go on-site instead.

7. Confirm required spares are in stock and pick for the job

Checked against the customer's instrument type and the fault pattern already on the ticket, not a generic spares kit, so the technician is not driving back for a part that could have been pulled at dispatch.

11. Write service report on-site and obtain **customer sign-off**

Findings, work performed and parts used, signed by the customer before the technician leaves site, so the record does not depend on a follow-up call to reconstruct what happened.

12. Issue **fully resolved** during visit?

A full fix confirmed on-site, versus a job that needs a part on order, an isolation the customer's process cannot grant that day, or a second specialist. Logging this as a decision keeps a job that spans two visits on one dispatch record instead of turning into a second, disconnected ticket.

14. ServiceDesk closes ticket and confirms resolution logged

Both branches, a phone resolution and a signed on-site report, close through the same ServiceDesk record, so nothing that skipped a dispatch stays untracked.

Making it yours

The 'fully resolved during visit' decision near the end (row 12) is what keeps a job spanning two visits on one dispatch record instead of splintering into a second, disconnected ticket: its 'Follow-up needed' branch loops back to 'assign technician' rather than starting a new Start row. When adapting this map for your own service desk, resist the temptation to close and reopen a ticket for a multi-visit job — the loop is there so the history stays in one place.

What to watch out for

• Do not merge the remote-resolution and on-site-resolution paths into one closing step without checking both feed it correctly. Row 14 closes the ticket for both branches deliberately, so nothing that resolved by phone stays untracked outside the same ServiceDesk record an on-site visit closes through.
• The customer sign-off at row 11 is not a formality to skip when the technician is confident the fix worked. Findings, work performed and parts used are captured and signed on-site specifically so the record does not depend on a follow-up call to reconstruct what happened — a verbal 'looks good' from the customer is not the same record.
• Site access, PPE requirements and the appointment window (row 9) belong before the vehicle is loaded, not discovered on arrival. Confirming them with the customer ahead of the visit is what stops a technician turning up to a site they cannot actually enter that day.

Frequently asked questions