An AI call taker needs an error log, not just a hotline to the programmer

An AI call taker gets better only as fast as its mistakes reach someone who can change its configuration, and in most agencies that path is still a conversation. Jonesboro, Arkansas just described its version on the record, and it is worth studying because it is so ordinary.

The system is called Lezle. It answers non-emergency calls for the Jonesboro E-911 center in Craighead County, and KAIT reported in January that the tool was developed by Prepared by AXON and would be used strictly for non-emergency calls. In its October 29 report, KAIT says that from Sept. 29 to Oct. 28, Lezle answered nearly 5,000 calls, and that dispatchers say it resolves more than half of them itself.

The same story contains the detail I care about. Dispatcher Terra Summers described an early glitch: after an accident, Lezle would tell the caller, "Please go online to file this accident report." Her response is the one any call taker would give: "Well, with any car accident, we're going to send an officer."

How the error traveled

KAIT describes the correction path in two sentences. When Lezle gets something wrong, dispatchers file a report with upper administration. Administrators either fix the issue themselves or send it to the programmer if they cannot.

That path worked for the accident case. A dispatcher noticed, a report went up, and the behavior changed. I do not read the story as a failure. I read it as a process that depends on the right person hearing the right call, with no shared record of what was caught, when, or what changed.

The safeguards around Lezle are real. Summers told KAIT that trigger words such as "emergency," "breathing," or "fire" immediately transfer a caller to a live dispatcher. When the system launched, KATV reported that live dispatchers would monitor it at all times and could force a call to dispatch if it was not being processed correctly. Training coordinator Cristy Hundley told KAIT in September that Lezle is "never going to answer a 911 call."

Those controls catch the dangerous call in the moment. The accident example is a different kind of error. Nobody said "emergency." The caller was routed to a web form, and the only safeguard was a person who knew that accidents get an officer. A keyword list will not find that class of mistake. A review of what the system actually did will.

Why the volume changes the math

KAIT's story says Lezle cut dispatchers' call load by 56% in the past 30 days. That figure comes from the station's reporting and the dispatchers it spoke with. The story does not say how it was measured or against what baseline, so I treat it as a reported outcome, not a benchmark.

The point that holds without the percentage is this. If the system resolves more than half of nearly 5,000 calls in a month without a person, most of what it does is never heard by a dispatcher. Informal reports catch the errors that happen to surface. They cannot tell you how often a misroute happened before someone noticed, or whether the fix held.

I covered what to measure in the first month of these deployments in What to measure in month one of an AI non-emergency line, including the point that failures need an owner. Jonesboro adds the missing piece: a real example of a misroute that no trigger word would have caught. That example deserves a structured home.

A one-page error log

This is the log I would put next to any AI call taker. It fits on one page, it works in a spreadsheet, and it does not need the vendor's permission to start.

Fields for each entry:

1. Date and time of the call, and the call or transcript ID.
2. Who caught it: dispatcher, supervisor, caller complaint, or scheduled review.
3. What the system did, in one sentence, quoted from the transcript where possible.
4. What a trained call taker would have done.
5. Category: misroute, wrong information, missed emergency cue, failed transfer, language or accessibility issue, or other.
6. Severity: could this have delayed a response to a person who needed one?
7. Fix owner: agency administrator or vendor, with a named person on each side.
8. The change made, the date it went live, and the configuration or prompt version if the vendor provides one.
9. Retest: a scripted call that reproduces the original problem, run after the change, with the result.
10. Status: open, fixed and retested, or accepted with a reason.

The retest field matters most. A fix that nobody re-ran is a belief that the fix worked. A scripted call, such as "I was just in a fender bender on Main Street," gives the next reviewer a way to confirm that the accident case still routes to an officer after the next update.

Owner and review cadence

The log needs one owner on the agency side. In most centers that is a supervisor or the training coordinator, someone who knows the call types and can tell the vendor what "correct" looks like. The vendor needs a named contact who acknowledges each entry and reports when a change ships.

For cadence, I would start with three rhythms:

• Same day for anything in the severity column that could have delayed a response. Those go straight to the agency owner and the vendor contact.
• Weekly for everything else, in a short review that clears open entries and reruns the scripted calls for anything fixed that week.
• Monthly for a sample of calls nobody flagged. Pull a set of AI-resolved calls at random and listen to them with a senior call taker. This is the only step that finds errors no one reported.

Then rerun the full set of scripted calls after every vendor update, whether or not the update was described as touching routing.

The log also answers the questions a city council or the public will eventually ask. How many errors have you found? What kind? How long did each one take to fix? Jonesboro's dispatchers already do the hard part, which is noticing. Writing it down is what lets someone outside the dispatch floor see that it happened.

If you run one of these systems, pull the last month of informal reports this week and put them into the ten fields above. The empty cells will show you where the process depends on memory.