Technician Scheduling and Dispatch Software Development

What dispatch software from Tepia actually decides

A dispatch system answers four questions every hour of the day: which technician, which job, in what order, and what happens when the plan breaks. Off the shelf tools answer the first two well and leave the last two to a dispatcher with a phone and a whiteboard. Tepia builds custom dispatch software when the third and fourth questions are where your money goes.

The typical Tepia client has 8 to 80 technicians, a mix of scheduled and emergency work, and at least one rule the platforms cannot express: a tech certified for commercial refrigeration must take those calls first, a maintenance agreement customer gets a two hour window instead of four, or a crew of two is needed for anything over a certain weight. Tepia encodes those rules so the board suggests the right answer and the dispatcher confirms it.

It pairs with the mobile work order management app page, which covers what happens after a job is assigned.

Scheduling logic Tepia builds into the board

Tepia designs the dispatch board around constraints first and the drag and drop interface second, because a pretty board with the wrong rules produces wrong schedules faster.

Tepia typically implements a suggestion engine rather than full automation. The system proposes assignments ranked by drive time, skills fit and capacity, and the dispatcher accepts or adjusts. Full automatic dispatch is possible, but most Tepia clients prefer the dispatcher to stay in control for the first year and tighten automation as trust builds.

Real time location and reassignment

Live location is the feature dispatchers ask for first and technicians worry about most. Tepia builds it to answer operational questions (who is closest, has the tech left, is the ETA still true) rather than to surveil. Location updates run only during work hours and only while the technician is on a shift, and that policy is visible inside the app.

The technician app reports location every 1 to 5 minutes while en route and less often on site, which keeps battery use modest. The dispatcher sees pins on a map, the job list, and an exception panel that flags the things that need a decision: a tech running more than 20 minutes late, a job with no assignment inside its window, or a cancelled job that opened a gap.

Reassignment is a single drag on the board. Tepia builds the downstream effects to happen automatically: the old technician’s app removes the job, the new technician’s app receives it with a push notification, and the customer gets a revised ETA by text if the window changed. Every reassignment is logged with who made it and why, so you can review patterns later.

Customer notifications that reduce calls

Most inbound calls to a dispatch desk are a customer asking where the technician is. Tepia designs the notification layer to answer that question before it is asked.

Notifications run through Twilio for SMS and SendGrid for email. Tepia builds the templates into the admin portal so your office can edit wording without a developer, and a customer link page shows the technician’s approximate position on a map while en route. Clients typically see dispatcher call volume fall once the en route text is live, because the question it answers is the one that drives most calls.

Every message is tied to the work order, so a dispatcher can see exactly what the customer has been told. Tepia also supports two way replies, where a customer’s text reply to reschedule lands as a task on the dispatch board instead of in a shared inbox.

How Tepia approaches technician scheduling and dispatch software

Dispatch software fails when it is designed from the office chair alone. Tepia’s six phase process puts discovery time with dispatchers and technicians before any design work starts.

1. Discovery (typically 1 to 3 months). Tepia sits with your dispatchers for several shifts, interviews technicians, and reviews third party integrations such as QuickBooks or ServiceTitan. Deliverables: Investigation Summary, Interview Summary and User Stories, including a written list of every scheduling rule.
2. Design. Design questionnaire, moodboards and a style guide, then detailed wireframes of the board, the exception panel and the technician app. Sample designs are tested on a real week of your historical jobs.
3. Development and Testing (typically 2 to 6 months). Alpha and Beta schedules with test plans for functional, user acceptance and nonfunctional testing. Tepia load tests the board with your peak day plus 50%.
4. Training. Hands on sessions for dispatchers using user story scenarios such as a same day emergency with three techs already at capacity.
5. Launch (about 1 month). Migration of customers, sites, technicians and open jobs, a parallel run with the old system for one or two weeks, and Tepia support reps on the rollout.

Read the full process at tepia.co/process and see how other operations products turned out at our work.

Frequently asked questions