Reduce the steps staff take
A suggestion should appear where someone needs it. If using AI means copying records into another tool and bringing the answer back, count those extra steps against any time saved.
For a team working from paper, phone calls and established software, AI may help read an order, summarise an account or find information in records. Start with the effort the task takes today, then include the time needed to check the result. A model belongs only where that leaves the team with an easier job.
Choose a task with a result someone can check. Keep the useful tools around it, and compare the whole job before and after the change.
A suggestion should appear where someone needs it. If using AI means copying records into another tool and bringing the answer back, count those extra steps against any time saved.
Totals, credit limits and fixed checks belong in ordinary software. A model is more useful for varied wording or documents, where its interpretation can be reviewed.
Agree what a useful result looks like, then check typical cases and mistakes with staff. Keep a way to complete the task when the suggestion is wrong or the model is unavailable.
These examples come from a customer application in daily use since July 2026. They show where a model helps with varied input and where ordinary software is enough. The distributor case study describes the implementation.
A photograph of a handwritten order can fill a cart with parts and quantities. Staff can also dictate in mixed Hindi and English. The result still goes through the usual order steps, and the photograph stays attached for checking.
Opening an account brings up a few lines about its position in English, Hindi or Marathi. A fixed template fills the same space when the model is unavailable, so the summary has a fallback within the existing screen.
A collection list ranks accounts using overdue amounts, how late they are, credit limits and recent cheque returns. Accounts touched that day leave the list. This is a calculation with defined inputs; it needs no language model.
An account summary needs the right account records. Reading an order needs the slip and enough product information to check the items. Neither is a reason to rebuild every tool the business uses.
Keep the document or records beside the suggestion so someone can check names, quantities and dates. Treat missing or old information as a reason to check further.
Agree which records the task needs and who may see the result. Connect that access through the tools the team uses, with permissions that match the person doing the work.
Reading records and changing them need separate decisions. Set the approval steps before adding a model, including who can confirm a proposed change and how it is recorded.
Compare time spent from the original input to a checked result. Include correcting mistakes, moving between screens and teaching staff how to use the change.
Use unclear handwriting, incomplete records and unfamiliar wording in the trial. Agree when staff should correct a suggestion or complete the task by hand.
Decide how work continues during an outage and what the ongoing cost will be. If a rule or a simpler process does the job with less effort, choose that.
Both are browser pilots from September 2026, open to try from the Products page. Neither preview is connected to a generative model, and each product page says so.
Students work inside the boundary their teacher sets for each project, and each session leaves a record of how the work happened. The record makes no claim about who wrote it. In the preview, guidance is fixed and grammar corrections come from local rules.
It reads a prompt to an AI assistant before you send it, marks where the assistant would have to guess, and offers wording you accept or reject. Nothing in your draft changes unless you choose it. It uses local rules, not a model. It reads only the textbox in front of you.
Questions about this go to hello@64arcs.com. A person replies within two working days.