Some of your employees may have tried general-purpose AI tools and found them useful for individual tasks, such as drafting a message or summarizing a document. But these tools stay outside your business systems: they don’t know the company’s data, they don’t follow its rules and permissions, and what they produce doesn’t go through the usual approval steps.
When AI works inside the system the company uses, on the other hand, it reads only what it’s allowed to read, proposes its result on the screen where the employee is working, and what it produces goes through the same review as any other work. The question here isn’t which technology to choose, but where to start, and how to build the first step so that afterward you know whether it’s worth expanding.
We suggest four practical steps: choosing one process, defining the expected outcome, reviewing the outputs, and then expanding step by step. With each step, we explain what it means technically and how it affects day-to-day work.
Choose one process with clear rules and data
Look for a process that is repeated often, whose rules are written down or can be, and whose data is in the system or in documents with a similar layout. The clearer the rules, the easier it is to judge the result; the cleaner the data, the less needs correcting later. Examples of such processes include:
- Reading supplier invoices and proposing their details in the data entry form.
- Classifying incoming requests and messages and routing them to the right department.
- Preparing draft replies to recurring inquiries, based on the company’s documents and procedures.
- Matching purchase orders with invoices and goods receipt notes, and showing the discrepancies to whoever reviews them.
On the other hand, don’t start with a process whose rules the team hasn’t yet agreed on. If two departments disagree on the moment an order counts as complete, AI won’t settle that disagreement; it will repeat it faster. And if a simple rule in the system is enough to do the job, it’s clearer and easier to maintain.
Where the automated step sits in the workflow
Pin down exactly where the automated suggestion comes in: after which step, and before which step. When reading supplier invoices, for example, the automated step comes after the document is uploaded and before it’s saved, so the employee sees the fields already filled in and corrects them before approving them. Steps that create accounting entries or send replies to customers stay after human approval, not before it.
This way, the workflow stays as the team knows it, and only the source of the draft changes. If the feature stops for any reason, work continues manually from the same point, without disrupting the department.
Data and permissions before anything else
The automated step needs data to read from: the text of the document, item or supplier data, and perhaps the history of past orders. Name this data specifically, and don’t give the feature general access to the whole database. The rule you apply to employees applies here too: each party sees only what it needs for its work.
Agree with management on what may be processed and where: what can be sent to an external service, and what must stay inside the company’s environment, such as payroll and customers’ personal data. Then there’s the question of display: if the feature summarizes a document, the summary must not appear to an employee who doesn’t have permission to see the original document.
In the article “User permissions and audit trails: the basis of trust in any business system,” we covered the principle of giving each user the permissions they need and no more, and of recording who did what and when. The same principle applies to any automated step inside the system.
Define the expected outcome before you build
Before any pilot, write down what must change in day-to-day work if it succeeds, in a form that can be checked. A phrase like “we want to save time” isn’t enough to decide, after the pilot, whether it succeeded. The following questions help you frame the expected outcome:
- What goes into the process, and what must come out of it?
- Which cases go straight to an employee without an automated suggestion?
- How will you compare the result with the current way of working, for example, the time data entry takes or the number of corrections the reviewer makes?
- Who owns the process, and who decides whether the pilot has achieved what you agreed on?
These answers become the acceptance criteria for the feature, and results are measured against them throughout the pilot, not only at its end. Always measure against the agreed outcome, not against a general impression that the feature works well. Whatever doesn’t meet the criteria doesn’t go into day-to-day work, however convincing it looked in the first demo.
Review the outputs and log every suggestion
Design the process from the start so that every output that affects a customer or a decision passes to a responsible person, who reviews it before it’s approved, on the same screen they work on. This way, the employee’s work shifts from data entry to review, and the decision stays in their hands.
AI suggests, and the responsible person decides. That is how responsibility stays clear inside the system.
Technically, the system keeps a clear log for every suggestion: what went into the automated step, what it suggested, who reviewed it, and whether they accepted it as it was, edited it, or rejected it. Weeks later, this log answers a question like “Why did this value appear on the invoice?” and reveals the cases where corrections keep recurring. The log is subject to the same permissions, because it contains business data.
Bring the people who carry out the process every day into the pilot, because they know the exceptions that don’t show up in samples. Their feedback, together with the log, is what the decision to expand is based on, not a general impression of the pilot.
When the feature is unsure
It isn’t enough for the system to suggest a result; it has to know when to hold back. If the document is unreadable, a value falls outside the usual range, or the feature can’t find a matching item, the right course is to refer the case to the employee with the reason explained, not to fill in the fields with a guess. These cases are written into the process rules in advance, so the team knows what happens in each one.
Expand step by step
When the pilot achieves the outcome you agreed on, widen its scope gradually: to more cases within the same process, then to another department or branch, then to a related process that relies on the same data. Before each step, review the rules, the review step, and the permission limits: are they still suitable, and have new cases appeared that need handling?
And don’t drop human review because the first results were good. The way you review may change over time; for low-impact cases, for example, reviewing a sample of the results may be enough. But that’s a decision management makes based on the log, and it’s written into the process rules.
A hypothetical example: supplier invoices
Suppose a distribution company receives its suppliers’ invoices by email in different formats, and two employees enter them into the system by hand. Management chooses this process because its rules are clear: every invoice is matched to a recorded purchase order and goods receipt.
An automated step is added after the invoice is uploaded: it reads the document, suggests the supplier, items, and quantities, matches them against the purchase order, and shows any discrepancies clearly. The employee reviews the fields and approves them, and both the suggestion and the employee’s decision are saved in the log. Invoices for which the step finds no matching purchase order go straight to the manual review list.
After the pilot period, management reviews the log: where the suggestions needed correcting, and which suppliers send formats that are hard to read. On that basis, it decides whether to expand to other documents or to adjust the rules first.
A checklist before you start
- One defined process that recurs often and has a clear owner.
- Written rules agreed on by the department concerned.
- Data named specifically, with a clear answer to who may see it and where it is processed.
- A clear point in the workflow where the automated step comes in, and a way for work to continue manually if it stops.
- A human approval step for every output that affects a customer or a decision.
- A log that keeps the inputs, the suggestions, and the review decisions.
- A written expected outcome to measure the pilot against.
- Written rules for the cases where the feature is unsure.
Start small and keep it clear: one process, a written expected outcome, human review of every output that has an impact, and a log of what happened; then expand based on a decision grounded in what the pilot recorded. If you want to identify the right first process in your organization, or build a feature for it inside your systems, you can discuss your situation with the ITS team.
Related serviceAI solutions