Software That Returns a Decision

A new kind of software service reads an email or a document and returns a decision instead of a stored record. It can take the first pass at the routine calls your staff make all day, if you plan for its price per call, its variable answers and the checks people need before they rely on it.

For twenty years, business software fetched records. A newer kind of service reads an email or a document and returns a decision, so software can now take the first pass at the routine calls your staff make all day.

Developers call it a judgment API: your software sends it text and gets back a classification, a summary or a draft. It can take on work that used to need a person, and it brings three things a database never made you plan for: a price on every call, answers that vary, and the checks people need before they rely on it.

A Call That Returns a Decision

Record lookup

Ask for customer 123. The service returns the stored record: Jane, manager, operations. The same request returns the same record every time.

Judgment API

Send an email that says 'I've been waiting 3 days for a response.' The service returns: complaint, high urgency, escalate. It read the message and made a call a person used to make.

The lookup retrieves a fact someone stored. The judgment API reads text it has never seen and returns an assessment, which is why it can do work a lookup never could.

Decisions Chained Into a Workflow

Several judgment calls chained together can do a job. Take the instruction a team lead gives a new coordinator: when this kind of email comes in, work out what it is, pull out the details, send it to the right person and draft a reply. That was a job description. It can now be a configured workflow.

Email Arrives

An email, a web form or a support ticket comes in

Classify It

Judgment call: complaint, question or order?

Pull Out the Details

Judgment call: account, dates and amounts from free text

Route It

Judgment call: which person handles this kind of request

Draft a Reply

Judgment call: a reply a person reviews before it goes out

Four of the five steps are decisions a person used to make. The model behind each call is available to anyone. What your firm owns is the workflow: which calls to make, in what order, and where a person checks the result.

Three Things a Database Never Made You Plan For

A database lookup costs next to nothing and comes back at once. A judgment call is billed by the model provider every time it runs, and it is much slower.

Say one workflow step classifies 10,000 documents a day at half a cent each (illustrative figures). That is $50 a day, about $18,000 a year, for a single step. The design controls the bill: reuse answers already given, batch work that can wait, send simple calls to a small, cheap model, and track spend as it happens.

Send the same email twice and the judgment API may mark the urgency high the first time and medium the second. Both are reasonable, and a test that expects one exact answer fails.

The checks change to fit. The software reports how sure it is, confirms every answer has the expected fields, sends low-confidence decisions to a person, and falls back safely when an answer is unusable. You test the range of answers and how the system fails.

It shows its reasoning. “Marked urgent because the sender has waited 3 days and mentions a deadline.” A person who sees why can judge whether the call was right.

It allows an override. A person can change any automated decision. Staff who cannot correct a wrong call start working around the system.

It cites its evidence. A lead marked high priority shows the signals behind the mark and quotes the source, so anyone can audit the decision later.

Where It Pays in Your Firm

Copying files and sending standard emails were automated years ago. The calls that stayed manual are the ones where someone reads something, interprets it and decides what happens next:

Is this email a complaint or a question?
Should this invoice be approved or flagged?
Does this ticket need escalation or a standard reply?
Is this contract clause standard or unusual?

Picture a coordinator who makes one of those calls 200 times a day. With software taking the first pass, the coordinator reviews only the calls it was unsure of, say 15 a day (illustrative figures), and the rest go through with their reasoning attached.

Start with one decision: the one your staff make most often, where a wrong call is cheap and easy to catch. Work out the cost per call at your volume before anything is built, then run the software beside the person and compare their calls before anyone relies on it. The risk is a wrong call nobody sees, which is why the review step matters more than the choice of model.

Which decision does your team make hundreds of times a week?

Book Free Assessment