A customer agrees on a call to move a delivery date. The project manager updates the plan, the ERP keeps the old date, and finance invoices against it. Nobody did anything wrong. The decision simply never left the call.

Every week, people across your organisation listen back to calls, read notes and copy what was agreed into the CRM, the ERP, the project plan and finance’s systems. It feels like admin. Put a number on it and it becomes one of the largest costs nobody budgets for.

A 50-person team spending 45 minutes a day moving information from calls into systems spends about 8,625 hours a year on it. At £60 an hour fully loaded, that’s over £500,000 of capacity a year spent carrying information from one place to another.

50 people × 45 minutes × 230 working days × £60 an hour.

And the hours are the smaller part of the bill.

What it really costs

The expensive part is what happens when a decision arrives late, or never arrives at all.

Revenue arrives later
If onboarding a customer worth £5,000 a month starts two weeks late because a requirement never reached the project plan, about £2,300 of revenue arrives later. That repeats for every customer it happens to.
Deals stall
A security question that sits in someone’s notes for a week adds a week to the sales cycle, and the deals waiting on security are usually the ones closest to signature.
Work gets done twice
An invoice raised against a date that changed on a call means a credit note, a new invoice, a delayed payment and a conversation with an irritated customer.
Operations become fragile
When the only complete record of what was agreed is one person’s memory of the call, the process works until that person is on holiday.

None of this appears as a line in the budget. It shows up as slower cash, longer sales cycles and teams that feel stretched while doing work no customer pays for.

What changes when decisions move by themselves

What’s agreed on a call reaches the right system the same day, approved and traceable.

Cut the 45 minutes to 10 and the same team gets back about 6,700 hours a year, roughly £400,000 of capacity at the same rate.

The bigger gains come from speed. Onboarding starts the day the requirement is agreed. The security review starts the day the question is raised. The invoice matches the delivery it bills for. A team that no longer re-keys its calls can take on more accounts, run more projects or close more deals, and the numbers leadership looks at reflect what was actually agreed last week.

Why this is possible now

Capturing calls is solved and cheap. The new part is judging, call by call, what should change.

Tools like Granola have made recording and transcribing meetings routine, and its API and webhooks let transcripts feed other systems. Speech-to-text models such as NVIDIA’s Parakeet TDT 0.6B v3, which covers 25 European languages and is licensed for commercial use, can run on your own machines when privacy or the cost per call matters. Where transcription runs decides what leaves the building: only text, or the audio itself.

Grey squares are audio, black squares are text. The dashed box is where transcription runs.

The newer change is the decision layer. Small models built for structured questions, such as TypeSafe AI’s Jev, currently in early access, return a typed answer with a confidence value, cheaply enough to run on every call. That turns “read the notes and decide” into something software can do for the clear cases, handing the rest to a person.

How it works

Most of a call changes nothing. The system’s job is to find the few decisions that do and route each one correctly.

What happens to 100 statements from one call.

Pick out what was decided

People discuss, propose and commit, often in the same breath. For the business these mean very different things:

  • We might need to push delivery to the 24th.Discussion
  • We can deliver on the 24th if the customer approves.Proposal
  • The customer has approved delivery on the 24th.Agreement

Extraction turns the statements that matter into candidate changes, marked as unauthorised until they’re checked, with the speaker and timestamp kept as evidence. This is what stops a “maybe” becoming a delivery date.

Check it against the records

Each candidate is resolved against the systems that own the facts. The system of record stays authoritative however recent the call, so a comment in a meeting can’t quietly override a contract.

The candidate goes out as a question and comes back as facts.

Decide with bounded questions

The decision is broken into small questions with fixed answers. A model answers each one and software applies your rules. Role checks, date comparisons and approval lookups stay in code, where they’re exact.

“We can deliver on the 24th if the customer approves.”

The fourth case is the one that pays for the whole system. The call says the customer approved, the records hold no approval, so it goes to a person and the wrong invoice is never raised.

Apply the change everywhere it belongs

An update that lands in the ERP but fails in the project tool recreates the original problem. Execution runs as a durable workflow, with retries, a check that each record hasn’t changed since it was evaluated, and a path to an operator when something fails. The change counts as done only when every system shows it.

The hard parts

A wrong update costs more than a slow one, so control comes before speed.

Permissions
A service that reads transcripts shouldn’t be able to write wherever it likes. Separate read from write, scope each integration, and require approval for anything consequential.
Provenance
Every change traces back to the words that caused it. When finance asks why a delivery date moved, the answer takes seconds, which is what makes auditors and customers comfortable with automation.
Data
Decide where each stage runs. Local transcription keeps audio in-house, but an external decision API still receives the extracted passages.
Accuracy that matters
Measure the system on dates, amounts, names and negation. A transcript that confuses “approved” with “not approved” can still score well on overall accuracy.
Asking why a date changed walks the chain back to the words said on the call.

Run the first version in shadow mode: it proposes changes, your team keeps working as usual, and you compare the two before it gets write access. Every mismatch becomes a test case.

In shadow mode nothing is written. Mismatches go back into the evaluation set.

Where to start

Start where the money is: one workflow where delay is expensive and someone re-keys calls every week.

  1. Pick the workflow: customer onboarding, delivery coordination, supplier management or account operations, whichever has the clearest cost of delay.
  2. Map how information moves today and price it: who copies what, how often, and what happens when it’s late or wrong.
  3. Choose a few well-defined changes to automate first, such as a delivery date moving, a requirement changing or an action getting a new owner.
  4. Use an existing transcription provider. Build local capture only when privacy or cost per call demands it, and only once the automation downstream has proved itself.
  5. Run it in shadow mode, then grant write access one type of change at a time.

Once the first workflow works, the capture, decision and execution layers carry over to the next. Each new workflow brings its own rules about authority and acceptable actions, and that is where most of the engineering goes.

Beyond meetings

The same applies to email, support conversations and documents: anywhere people read something and update a system by hand. In most organisations it adds up to one of the largest costs that never appears in a budget.

Connecting the pieces is achievable today. The harder work is knowing which decisions matter, who can make them and which system owns the result. At Gris Noir, that’s where we start: we price the operation, find the workflows where decisions get lost between the call and the record, and build the system that carries them across.