AI and voice assistants

Assistants that file the record, not ones that chat

The useful question about an assistant is not what it can discuss but what it can finish. In ASNPRO more than fifty operations are done by speaking Turkish: say that a maintenance visit is complete and a payment was collected, and the maintenance record closes and the payment is entered. The output is rows in a database, not a paragraph of text.

That is the line we work on. If the result of an assistant is something a person then has to retype into a form, it has moved the work rather than removed it.

Getting Turkish right

Turkish is harder to handle than English for this kind of work. Suffixes carry meaning that English puts in separate words, and field vocabulary is full of part names, brand names and abbreviations that general speech models have never encountered. Making recognition hold up in a noisy machine room took vocabulary work and a lot of real recordings, not a default configuration.

We reuse that groundwork. Your terminology, your product names and the phrases your staff actually use go into the system during the build, instead of being discovered as failures after launch.

Where an instruction becomes an action

Spoken or typed input is turned into a structured intent with its parameters: which record, which operation, which amount. That intent is then checked against the same permission rules and the same validation the form would apply. An assistant is another client of your business logic, never a way around it.

Anything that writes or changes money, status or customer data is confirmed first, in one short sentence the user approves. Anything the system is unsure about asks rather than guesses. A wrong record created silently costs far more than a question.

Documents and receipts

OCR turns a photographed receipt, delivery note or form into fields. Realistic accuracy on a creased receipt shot at an angle is not one hundred percent, and systems that pretend otherwise produce silent errors that only surface at month end.

So the review step is designed in from the start: extracted fields appear next to the image, low-confidence values are flagged, and a person confirms. Over time the flag rate tells you exactly where the extraction needs work, which is a number you can act on.

Connecting a model to your data without handing over the keys

An assistant that answers questions about your own records needs access to them, and that raises a question worth answering explicitly rather than in a footnote: what leaves your systems, where it is processed, and what is retained. We decide it per project and write it down.

The options are real. Sensitive fields can be filtered or masked before anything is sent to a hosted model, parts of the pipeline can run on your own servers, or the model can be limited to producing an intent while the data stays behind your API. Which combination fits depends on what the data is and what your obligations are.

How we scope an assistant project

First we count. Which operations happen most often, how long each takes today, and how many can be expressed in a single sentence. That ranked list decides what is worth automating, and it is usually a handful of actions covering most of the volume.

Then a narrow pilot: two or three operations wired into the real system and used by real staff. This is where the vocabulary problems and the awkward phrasings show up.

Then measurement: how often the assistant understood, how often it asked, how often it was wrong. The set of operations widens only where those numbers hold.

Then the rest in batches, with the same measurement each time, and with the manual path always left available.

Knowing when not to use a model

Plenty of problems described as AI work are better solved with a rule, a query or a decent report. A model that produces a plausible answer where a calculation would produce a correct one is a downgrade. We say so when that is the case; it makes for a cheaper project and a better system.