Production system Case studyLive, in tuningZero-downtime deploys

AI Call-Time Dispatch Assistant for a Multi-Trade Field-Service Operation

A booking panel that fills itself while the phone is still ringing. It identifies the caller, matches a qualified technician against the day's roster, and offers an arrival window that live road distances can actually support, so the job is booked while the customer is still on the line.

1 clickfrom live call to booked job0blank screens, every path returnsLive roadsnot radius assumptionsVersionedengine, zero-downtime cutover

Built by Patrick Joseph Panuncillon, AI Director and Applied AI Systems Architect. Designed, built, shipped, and operated by one builder with AI augmentation.

The problem

A booking is four judgments made in seconds, from one person's memory.

  • Booking a service call means deciding who is qualified, who is actually free, whether they can physically reach the address in time, and whether the work is even in scope. All of it while a customer waits on the line.
  • That judgment lived with one or two senior dispatchers. When they were off shift, booking quality dropped, and none of the reasoning was written down anywhere a system could use.
  • Generic scheduling tools offer time slots without knowing whether a qualified technician can reach the address inside the window. A slot that looks bookable and is not produces a cancellation, a wasted truck roll, and a customer who now distrusts the next promise.

The solution

The panel does the arithmetic. The dispatcher still decides.

A panel lives inside the field-service platform the dispatchers already work in. When a call connects, it populates itself: the inbound number resolves against the customer record, technicians are filtered by trade qualification and the published roster, and arrival windows are computed from live driving distance and current crew position rather than from a fixed grid or a radius.

Work outside the service area or the trade scope is declined in the panel with the reason shown, rather than booked now and canceled later. Nothing books itself. The dispatcher reviews what the panel proposes and commits it with one click.

The trust modelThe panel performs the arithmetic that used to be done from memory, shows the reasoning behind every offer, and writes nothing until a person clicks.

How it works

Eight capabilities behind a one-click booking.

Described at the capability level. No code, endpoints, or vendor account detail.

IdentifyThe caller is known before hello

The inbound number resolves against the customer record while the phone is still ringing, so history, address, and prior jobs are already on screen when the dispatcher answers.

MatchSkill and roster aware

Technicians are filtered by trade qualification and by the published roster for that day. An unqualified or off-shift technician is never offered, so the panel cannot propose a booking the business cannot honor.

TravelReal road distance, not a radius

Arrival windows are computed from live driving distance and current crew position. The window offered is one the road network can actually support, which is the whole difference between a promise and a guess.

ScopeA stated no, at the right moment

Work outside the service area or trade scope is declined in the panel with the reason shown. Declining on the call is cheaper than a cancellation, a wasted truck roll, and a broken promise.

FallbackNever a blank screen

Every path returns something usable. If a data source is slow or unavailable the panel degrades to a reduced but still bookable state and says so, because a panel that sometimes shows nothing is a panel people stop opening.

VersioningZero-downtime engine cutover

The routing engine is versioned. A new ruleset is published beside the running one and cut over deliberately, so a deploy never lands in the middle of a live call.

BookOne click, one write

The confirmed booking is written once into the field-service platform. No double entry, no retyping what the panel already resolved, no second system to reconcile.

AuditEvery offer records why

The panel keeps the reasoning behind each technician and window it offered. That is what makes the system tunable against real outcomes instead of mysterious.

01Call connectsInbound number arrives from the phone system
02Caller resolvedMatched to the customer record and job history
03Skill and rosterOnly qualified, on-shift technicians survive
04Road-distance windowLive driving time and current crew position
05Scope checkOut of area or out of trade is declined with a reason
06Dispatcher reviewsA person confirms. Nothing books itself
07BookedWritten once to the field-service platform
Every step degrades to a usable state rather than failing to a blank screen.

The phased build

Engine first, interface second, honesty about travel time third.

1

The decision engine, standalone Built before any interface

The routing logic was built and versioned as its own service before a panel existed, so the decision layer could be tested against real historical bookings rather than against opinion.

2

Inside the tool they already use No new login

Delivered as a panel within the field-service platform. No second screen, no extra sign-in, and no change to how a call is handled. Adoption problems are usually interface problems.

3

Travel time, honestly

Radius-based assumptions were replaced with live driving distance and crew position. That is the difference between a window that sounds right in a meeting and one that holds on a Tuesday afternoon.

4

Refusal and graceful degradation

Added the stated no for out-of-scope work, and the reduced-but-bookable fallback for when a dependency is slow. Both exist because trust is lost faster than it is built.

5

Tuning against real days Current phase

The engine is now scored against how an expert dispatcher actually schedules an ordinary day, captured by a companion system described in the Dispatch Understudy case study.

Results and design commitments

Live, in tuning, and measured against real scheduling behavior.

Live
In production, in active tuning
1 click
From live call to booked job
0
Blank screens. Every path returns a usable panel
0
Downtime on engine deploys, by design
Live roads
Arrival windows from real driving distance
Stated
Reason given whenever work is declined
1 write
Booking written once. No double entry
Explainable
Every offer records why it was made
Why refusal is a feature

A system that books work it cannot serve creates a cancellation, a wasted truck roll, and a customer who stops believing the next arrival window. Declining on the call, with the reason shown, is cheaper than all three.

The hard constraint

The panel must never be the reason a call goes quiet. Every external call carries a timeout and a fallback, so a slow third party degrades one panel instead of stalling the dispatcher mid-conversation.

What actually changed

A scheduling decision that used to depend on one person's memory is now a repeatable, explainable, one-click booking made while the customer is still on the line. The expertise did not leave the building when its owner went on leave.

What it demonstrates

The skills behind the system.

Real-time decision support under time pressureConstraint-based schedulingGeospatial routing and travel-time estimationVersioned rules enginesZero-downtime deploymentBrowser-extension integration (Manifest V3)Telephony integrationField-service platform integrationGraceful degradation and fallback designHuman-in-the-loop bookingExplainable automated decisionsEncoding expert judgment as reviewable rules

Outcome and what is next

Live, in tuning, scored against the expert.

The engine is live and in tuning. It is scored against real dispatch behavior rather than against itself, which is the only honest way to know whether an automated scheduler is any good. The scoring set comes from the companion capture system, and the rules it produces feed straight back into this panel.

Confidentiality and intellectual property

This is an anonymized portfolio write-up. It names no client or employer and discloses no source code, prompts, credentials, endpoints, schemas, customer data, or exact commercial terms. Third-party vendors in the client's operational stack are described by category rather than by name. Figures are rounded or banded.

Intellectual property in every system described here belongs to the organization that commissioned it. Nothing on this page is a claim of ownership, a transfer of rights, or an offer to license, sell, or reproduce any system. This page records authorship and build credit only, and it is published in a personal capacity, not on behalf of any employer or client. See Authorship and verification for the full disclosure standard.

If any part of this page is inaccurate, or a rights holder considers it to exceed that standard, contact consultwithpatrick@gmail.com and it will be corrected or removed promptly.