Four phone calls before anyone is sent
A lockout comes in at 2pm: a woman with a baby in the flat and the keys inside. The office wants someone there as soon as possible. The diary says Mark is on a lock change in the north of town, Jay is on a safe service, and Chris is "out". The office rings Mark, who is nearly finished but twenty minutes away. They ring Chris, who does not answer because he is driving. They ring Jay, who is round the corner but mid-service and needs another hour.
Ten minutes later they send Mark. Chris, it turns out, was two streets away and free. Meanwhile the customer has been told "someone will be with you soon" and has rung twice to ask when.
The diary shows plans, not reality
Locksmith days change constantly: jobs overrun, a quick job turns into a parts order, an engineer pops to the wholesaler. The diary records what was planned, and the only way to find out what is actually happening is to ring people who are often driving or have their hands in a door.
- The diary is not updated when jobs finish early or overrun.
- The office has no view of where engineers actually are.
- Ringing round interrupts engineers mid-job and while driving.
- Van stock is not considered, so the nearest engineer may lack the parts.
- Customers get vague arrival times because the office genuinely does not know.
Tracker systems on the vans often exist already, but they sit in a separate web page nobody has open, and they show dots on a map without knowing what each engineer is doing.
Slower arrivals and awkward customer calls
For urgent locksmith work, speed of arrival is much of what the customer is paying for. A slower dispatch means longer waits, more calls from anxious customers and a higher chance they ring another firm while waiting. Office time goes on phone calls, and engineers get irritated by constant interruptions.
A dispatch board that knows where and what
We build a dispatch view for the office that combines location, job status and stock, using data you mostly already have.
- Engineer positions come from your existing vehicle trackers through their API, or from the engineer's phone while they are on shift, with their agreement and only during working hours.
- Job status comes from the engineer's job app: travelling, on site, finishing, free. Taps they make anyway become the live status.
- When an urgent job is entered, the board lists engineers by estimated travel time from a mapping service, taking into account whether they are free or nearly finished.
- If the job type needs particular parts, van stock is checked for each candidate, so the suggestion is someone who can finish the job.
- The office chooses who to send. The engineer gets the job on their phone with the address, access notes and quote.
- The customer gets a text with the engineer's name and an estimated arrival time, updated if it changes.
| Question | Answered by |
|---|---|
| Who is closest? | Tracker or phone location and travel time |
| Who is free now or soon? | Job status from the engineer app |
| Who has the right parts? | Van stock records |
| When will they arrive? | Travel estimate, texted to the customer |
The final decision stays with the office. The board makes a suggestion, and a person who knows the engineers and the area confirms it.
Faster sends, fewer calls
The office can dispatch in the time it takes to read the board. Engineers are interrupted only when they are actually being sent. Customers get a name and a time, and a text if that changes, so fewer of them ring to ask. Over time the board also shows where demand comes from and whether engineers are based in the right places.
Does your dispatch look like this?
- The office rings round to find who is free.
- Tracker data exists but is not used to dispatch.
- Engineers are sent without the parts the job needs.
- Customers ring back asking when someone will arrive.
- The diary rarely matches what actually happened.