Practical AI features in business software, and their limits

The AI features that earn their place in business software are the ones that remove typing or reading: turning a voice note into a structured record, summarising a long history, pulling fields out of a scanned document, and drafting a follow-up message for a person to approve. Each of these saves minutes many times a day. Each also fails sometimes, so the feature is only as good as its fallback, its log and the way it is measured. This is how we build them and where they stop.

Which AI features actually save time?

We are cautious about AI features because most of the ones we are asked for are a chat box bolted onto a screen. A chat box makes a demo look modern and saves nobody any time. The features below are different. They sit inside a workflow someone already does, and they take a step out of it.

How does voice to text work in a real clinic?

A doctor sends a voice note. The audio is transcribed, and the transcript is turned into the fields the record expects: diagnosis, medications with dose and frequency, advice, follow-up date. The draft appears on the doctor's screen with the original audio next to it. Nothing is saved as final until the doctor approves it. This is the whole design: the model does the typing, the person does the deciding. In a noisy OPD with mixed Hindi and English, the transcript will be wrong sometimes, and the review step is what makes that acceptable.

What is the fallback when the model fails?

Every AI feature we ship has a plain path that works with the model switched off. If transcription fails, the voice note is saved and the form is empty, exactly as it was before the feature existed. If extraction cannot read a document, the form is blank and the image is attached. If a draft cannot be generated, the compose box is empty. The rule is that the model can only add, never block. A feature that stops a workflow when the AI provider is slow or down is a feature that staff switch off on the first bad day, and rightly.

• Timeouts are short. A draft that takes twenty seconds is a draft nobody waits for.
• Failures are silent to the user and loud to us. Staff see the plain form; we see the alert.
• Model output is never the final record. A person confirms, and the confirmation is what is stored.
• Provider and model can be swapped without the feature changing.

Why does every AI action need a log?

When a doctor asks why the draft said 'twice daily' when the audio said 'once', someone has to be able to answer. So every AI action is logged: the input (audio, document or record), the exact prompt and model version, the raw output, what the person changed before approving, and the time. This log is what lets us find a bad prompt, measure how often drafts are edited, and show an auditor what the software did and did not decide. It is also personal data, so it is stored under the same access rules and retention as the record itself, in India, as the Digital Personal Data Protection Act expects.

How do you evaluate whether it is good enough?

Good enough is a number, and the number comes from your data, not from a benchmark. Before a feature goes live, we run it over a sample of real inputs and score the output against what a person produced for the same input. For extraction that is field accuracy. For transcription it is how much the draft had to be edited to reach the approved record. For drafts it is how often staff send without changing anything. The score decides whether the feature ships, and it is watched after launch.

1. Collect fifty to a hundred real examples with the correct answer written by a person.
2. Run the feature over them and score each output automatically where possible, by hand where not.
3. Set a threshold with the business owner: what error rate is acceptable, given that a person reviews every output?
4. Ship behind a flag for a few users, watch the edit rate, then widen.
5. Re-run the same set whenever the prompt, model or provider changes.

Where do the limits sit?

Some tasks should not be given to a model even with review. Deciding a diagnosis, approving a discount, or sending a message to a patient without a person seeing it. A follow-up draft on WhatsApp is fine. An auto-reply that answers a medical question is not, which is why our WhatsApp auto-reply hands over to a human on anything that is not a simple booking or status query, inside the customer service window rules Meta sets. The other limit is data. A model given your records must run under a contract that says the data is not used to train it and is not retained. That is a question to ask your vendor, and one we answer on every AI project.

Frequently asked questions

Do AI features need an internet connection?

Usually, yes, because the models run on a provider's servers. This is one more reason the plain fallback matters: when the connection drops, the form still works and the voice note is kept for later. Smaller models can run on your own server for some tasks, at a cost in accuracy, and that is a fair choice for data that cannot leave the building.

Will AI replace our data entry staff?

It changes their work from typing to checking. The drafts are wrong often enough that a person reviewing them is still the safety net, and a good reviewer is faster with a draft than without one. Where we have seen headcount fall, it is because the business grew without hiring, not because someone was let go on the day the feature went live.

How do we know the model is not making things up?

You cannot tell by looking at the output, which is why every output is reviewed and logged. The safeguards are structural: the model is asked only for fields that exist in the input, empty is an allowed answer, the source is shown next to the draft, and the evaluation set catches drift. Treat any vendor who says their AI does not make mistakes with suspicion.