Encoder Technologies

AI

Practical AI in business software: what actually works

Forecasting, document extraction and retrieval assistants earn their place in operational software. How we scope, evaluate and constrain them.

By
Encoder Technologies
Published
Reading time
10 min

Most AI features in business software fail for an unglamorous reason: nobody identified the decision they were supposed to change. A dashboard predicting something no one acts on is a cost with a demo attached. So the first question is never which model — it is which decision, made by whom, how often, and what it costs to get wrong today.

Forecasting: beat the rule of thumb, consistently

Reorder quantities, staffing levels and cash position are the forecasting problems that recur in operational software. They usually need classical models rather than deep learning, and their value comes from being slightly better than the current heuristic across hundreds of small decisions rather than dramatically better once.

The baseline to beat is not zero. It is the experienced manager's rule of thumb, and you should measure against exactly that. A model that cannot outperform the person who has been doing this for ten years is a finding worth having early, not a project to continue funding.

Document extraction: remove typing, keep judgement

Supplier invoices, delivery notes and receipts arrive as PDFs and photographs, and somebody retypes them. Extraction with per-field confidence scoring, plus a review queue for anything uncertain, removes most of that work while keeping a human on the genuinely ambiguous cases.

This is the easiest category to justify commercially because the outcome is directly measurable: hours removed and error rate, both verifiable by the client against their own before-and-after.

Assistants: the engineering is permissions, not prompting

Retrieval-based assistants answering questions over company records are useful, and the hard part is not the model. An assistant must retrieve only what the asking user is already allowed to see, cite the records it answered from, and refuse when those records do not contain an answer.

Get that wrong and you have built a data-leak with a chat interface. Permission-aware retrieval is a design constraint from the first line, not a filter applied to results afterwards.

What we avoid

Features where a confident wrong answer is expensive and invisible. Models trained on data too thin to support the claim. Fine-tuning as an opening move rather than a last step.

We also insist on an evaluation set before launch — a fixed list of inputs with known-correct outputs — so accuracy is a number both sides can check, and so a regression six months later is detected rather than reported by a customer.

Sequence matters more than sophistication

Clean data models and documented APIs come first; the model is the last component and often the smallest. Businesses whose records are already coherent can add these features incrementally.

Businesses whose data lives in three disconnected systems should fix that first — and that fix is worth doing whether or not any AI is ever added on top of it.

Working on something this touches on? Tell us what you are building — we will say honestly whether we are the right team for it.

Related articles

FAQ

Questions from this article

How much data do we need before AI is worth considering?

Enough history for the pattern to have repeated many times — typically a year or more of clean transaction data for demand forecasting. The first phase of any engagement establishes whether the data supports the question.

How do you stop an assistant from inventing answers?

Constrain it to retrieved records, require citations, enforce the asking user's permissions at retrieval time, and evaluate against a fixed test set. It should say it cannot find an answer rather than produce one.

Have a product in mind?

Tell us what you're building, improving or automating. We'll help turn the idea into reliable software.