Several reports of the same fault become one case.
The dispatcher sees one fault with the full report history. They approve the category, priority, and contractor work order.
Problem, solution, and result
The problem
The same fault arrives by phone, email, and portal in different words. Dispatchers search for repeats and judge urgency by hand. A safety issue can disappear in the queue.
How the system works
The system keeps each original report, proposes a category, and compares it with open cases. Repeats become one fault. Safety and SLA rules order the queue. The dispatcher approves the next action.
What we tested
The demonstration joined repeated reports correctly and detected the expected safety signals. It uses a small test dataset. Priority quality, handling time, and cost must be confirmed on the client’s full traffic.
For whom
This is a good automation candidate when reports arrive through several channels and the first sort plus duplicate search takes the whole morning.
Reports → one fault → queue → dispatcher
- 01Repeated reports are linked to the building history
- 02Safety and SLA determine the order
- 03The dispatcher approves the action
- Business type
- Property managers, housing cooperatives, and municipal operators
- Input
- Resident tickets by phone, email, and portal; the reproduction seeds 400 tickets across 40 buildings with 24 months of history
- Boundary
- The system contacts no contractors and closes no cases; the dispatcher approves every order
- Cost
- USD 0.010717 for the complete recorded run: 24 reports and 6 model calls.
- Security
- Safety-related reports move higher in the queue. The dispatcher approves the final priority and work order.
- Speed
- We measure full-queue handling time in a pilot using the actual flow of reports.
- Trace
- The history connects each report with its case, proposed priority, and the dispatcher’s decision.
- Similar system build
- from €6,000 net (approx. $6,500) · 6–16 weeks
Reference exchange rates: USD 1 = PLN 3.72; EUR 1 = PLN 4.30. PLN amounts are rounded, with the measurement currency retained in parentheses.
Where automation stops
The dispatcher approves the work
The system orders the queue and suggests duplicates. It does not contact contractors, confirm repairs, or close cases. The dispatcher can correct a category, and the change history remains with the ticket.
- Boundary
- The system contacts no contractors and closes no cases; the dispatcher approves every order
- Cost
- USD 0.010717 for the complete recorded run: 24 reports and 6 model calls.
- Security
- Safety-related reports move higher in the queue. The dispatcher approves the final priority and work order.
- Speed
- We measure full-queue handling time in a pilot using the actual flow of reports.
The first test missed its threshold
The first test placed two roof leaks, a heating fault, and a leaning balustrade in the wrong queues. The system relied too heavily on the resident’s category. We reduced its weight, clarified the categories, and added rules for clear safety signals. The earlier result remains visible because the two test sets were not matched record by record.
Estimated impact
Calculate the impact at your volume
This estimate uses the stated volume. Enter your own numbers to assess the possible impact in your company. The result is confirmed only during a pilot.
Today
model: 140 h
With the system
model: 32 h
Time or cost saved
model: 80-135 h/mo, base 108 h
- Volume
- 2,400 tickets/mo
- Formula
- (2,400 × (3.5 - 0.8)) / 60 = 108 h/mo
- Calculation status
- modelled and unmeasured
Data in the screenshots. The names, amounts, and documents shown in the screenshots are synthetic. Client data remains private. Measurements describe the demonstrator and are kept separate from production outcomes.
Working surfaces
The dispatcher approves the category, priority, and work order. The system prepares an organized case.
The dispatcher starts with an ordered queue. Safety cases appear first, and repeated reports form one fault with the reasoning shown. A pilot measures crew response time, SLA performance, and routing quality across all categories.
Three views for the dispatcher
Ticket queue
Cases ordered by safety and SLA deadline.
Fault record
Original reports, building history, and proposed category.
Duplicate review
Compared reports with the reason they may describe the same fault.
System screens
See how the system works in practice
These desktop and mobile screenshots come from the running application. They show the process and the points where a person makes the decision.
- Screens
- 12
- px
- 1440 · 390
- 021440×2016
Three different reports grouped into one fault. - 031440×1100
The current 1.000 result displayed beside the earlier 0.828 run.
Open the remaining screen archive (9)
- 041440×1100
Measurement scope and limits - 051440×1100
Safety-ticket correction - 061440×1100
Correct roof-ticket route - 071440×1100
Safety signals - 081440×1100
Repeat reports - 091440×1100
Buildings - 101440×1100
A building card - 111440×1100
Crews - 121440×1100
Response deadlines
Technology stack
The model compares text; rules order the queue
The model proposes categories and duplicates. Code raises clear safety signals and applies SLA rules. PostgreSQL and Redis store the state and queue.
- LangGraph
- runs the graph of classification, history comparison, and escalation
- LiteLLM
- model routing plus call and token limits on every measurement
- PostgreSQL 17
- the source of truth for tickets, the queue, and recorded runs
- Redis
- coordinates workers and the task queue
- FastAPI
- serves operational data to the duty screens
- OpenTelemetry
- records the trace of every run
The client receives the code, categories, test data, and documentation. The system runs on the client side. Phone, email, portal, and contractor integrations are built during implementation.
Technical details and measurements
The working loop
Every report receives the same checks
The system reads the original text, proposes a category, and compares it with the building's history. Every suggestion includes reasoning and waits for the dispatcher.
Phone, email, or resident portal
Category, urgency, and history check
Repeats → one fault
Safety and SLA → queue order
Dispatcher approves the work order
System architecture
Original report, history comparison, SLA, and decision record
The model proposes categories and duplicate links. Code applies safety and SLA rules. The database retains the original text, corrections, and each decision.
- 01
Input
The ticket enters unedited.
The resident's text stays raw and normalization hides nothing. The original is visible next to the result at every stage, including after a category correction.
- 02
Classification
The graph proposes a category and looks for repeats.
The model assigns a category, an urgency, and a safety signal, receiving the reporter's own category only as an untrusted hint. Duplicate candidates are compared strictly within the same building and fault.
- 03
Queue
Risk and SLA set the order.
Safety tickets go on top, then cases past their SLA deadline. These are deterministic rules you can read and change without touching the model.
- 04
Decision and trace
The dispatcher approves; the run remains.
The contractor proposal waits for a decision. The run records classifications, comparisons, the source of every category verdict, tokens, and call costs, so quality measurement is part of the system.
Why this is an agent on a short leash
The graph runs a defined decision loop: the model compares a ticket with the building's history and must justify every merge. Everything expressible as a rule remains a rule, including queue order, the SLA matrix and unambiguous system terms. The model performs no outward actions, and every run records that boundary in its trace.
- Safety and SLA rules order the queue
- The model classifies and compares, with no outward actions
- The reporter's category enters as an untrusted hint
- The dispatcher's correction lands in the run beside the original proposal
Want to assess a similar process in your company?
- A 30-minute call with the engineer who would lead the work.
- A review of the processes that cost you the most time and money.
- A written summary of what to automate first and the likely cost range.
Times are shown in your own time zone. We work with clients across time zones.
The scan is free and creates no obligation. If automation is unlikely to pay off, the written recommendation will say so.