Plain-English dispatch policies, explainable technician recommendations.
An AI dispatch agent for field teams — write the assignment policy in plain English, test it on a real ticket, and get every recommendation with its score and reasoning on the surface.
The demo is a desktop console. Open it in a new tab to click through the real product on sample data.
Open the demo- Role
- Lead Product Designer
- Contribution
- Led design, copy, and frontend — policy authoring, the recommendation card, technicians, and data sources.
- Timeline
- 2025 – Present
- Client
- Facilio
- Disciplines
- Design · Dev
What it is
Describe how assignment should work in plain English. The agent turns it into a policy, scores every candidate, and recommends — or auto-assigns — with the reasoning on the surface.
It ships as its own product for teams that already have tickets: Home, Tickets, Technicians, Dispatcher policies, and Ask AI. The window above is that product on sample data.
The problem
A dispatcher reads a ticket and guesses who is free, close enough, and certified. The rules in their head are real — they just live nowhere.
The usual fixes both fail: IF/THEN builders cap what you can say, and a text box that returns a black box can't be trusted. This rule decides who gets sent to a gas leak.
The idea
Write prose. Brief the policy the way you'd brief a new dispatcher.
Get structure back. Four labelled steps that mirror how the engine actually runs.
Test before you trust. Run it on a real ticket before it touches a live one.
Show the reasoning. Every recommendation carries its score, its runners-up, and the steps behind it.
Write the policy
A blank canvas, a prompt box, a few example chips. Type the rule, hit Enter, and you're on the builder page while the AI drafts.
Refinement stays conversational: a chat rail on the left, the structured breakdown on the right updating as you go.
Structure, not a black box
The breakdown renders the rule as a pipeline.
Trigger. When it applies, as IF / AND rows.
Eligibility. The hard filter, as chip clusters.
Ranking. One weight bar that splits to 100% across skill, proximity, availability, performance and cost.
Assignment. Who wins.
Test it on a real ticket
Open the playground from the builder, pick a real ticket from the queue, run the policy. Ranked technicians, a Top match badge, nothing saved.
Trusting the assignment
In the ticket, the card leads with its own state: “Atom recommends” while it waits for you, “Auto-assigned” once it has acted.
A number, not a word. “96% match,” never “high.”
Runners-up with their own scores. Each has an Assign button, so overriding is one scored click.
How Atom decided. The six engine steps, each shown only if the backend produced real reasoning for it.
The people it ranks
The directory holds exactly what the engine ranks on: skills rated 1–5, certifications, zones, inventory, breaks, live status, job history. The explanation and its data share one vocabulary.
The system you already run
Nothing gets retyped. Data Sources connects the CMMS you already run and maps its fields onto the product's — with coverage shown per dataset, so you know what the engine won't know.
How it's built
One bundle, two products. The Dispatcher is served from the same build as the Helpdesk; the first URL segment picks the product.
A subset, not a fork. Gating is a denylist — Inbox, Contacts, Intake and channel settings hidden. A new module appears in both until someone parks it.
Portable by design. All dispatch routing lives in one folder, so it lifts into a standalone app with only the shell wiring to redo.