"An AI-based management system" sounds like a single product you install, after which the business runs itself. In practice it is not a product but a way of building: you take a process that exists in your business today, decide which of its steps suit software and an AI agent and which stay with a person, and connect it to the systems that already work. This guide is for someone who runs a business or operations and wants to understand what they are actually buying, where it pays off and where it does not.
What it means in practice: software and agents on top of what you already have
Three components recur in every such system. The first is ordinary software: workflows, rules, connections between systems — the part that does exactly what was defined. The second is an AI capability where the input is not uniform: a document in a new format, a free-text enquiry, a case no rule was written for in advance. The third is an agent, meaning a sequence of actions against your systems within permissions and limits defined in advance. Above all three sits human oversight.
| What people think it is | What it is in practice |
|---|---|
| A new ERP replacing the old one | A layer that connects to the CRM, ERP and existing systems and performs steps in them |
| One chatbot that knows everything about the business | Several focused capabilities, each on one process with clear limits |
| An off-the-shelf product you install | A system tailored to the business's processes and data, including integrations |
| A replacement for staff | A different split of the work: the system handles the routine, a person handles exceptions and decisions |
The business automation page describes what we offer in this area, and the approach: map the process, plan, build and connect, then measure and improve. Business automation with AI — what we build and how we work
Four processes that recur in almost every business
Instead of talking about "AI in business" in general, it helps to talk about a process. These are four processes almost every business has a version of. Each shows what the system does and what stays with a person.
| Process | What the system does | What stays with a person |
|---|---|---|
| Documents and invoices | Takes in documents from any channel, extracts fields, classifies, and checks them against the order or contract | Mismatches and exceptions, and approval of sensitive documents |
| Back office and operations | Puts a request into a flow with clear ownership, performs the manual steps against the systems, and shows a single status | The business rules: what passes on its own and what needs approval |
| Service and leads | Gathers enquiries from several channels into one queue, answers recurring questions, and hands a complex enquiry to a rep with a summary | Complex or sensitive enquiries, and ones the system is unsure about |
| Reporting and control | Collects data from different systems, computes operational measures and alerts on deviation | Interpretation, and the decision on what to do about a deviation |
What to automate first: five questions for choosing a process
The common mistake is to start with the most impressive process, or the most painful one, without checking whether it can be automated. This decision table helps sort them. Every "yes" moves a process closer to being a first candidate.
| Question | Why it matters | If the answer is "no" |
|---|---|---|
| Does the process repeat regularly? | A repeating process gives enough cases to check whether the system works | There is nothing to measure against; better left manual |
| Can its steps and rules be written down? | What is not defined for a person will not be defined for an agent either | Define the process first, then talk about automation |
| Does it cross several people or systems? | That is where time is lost: handoffs, waiting, manual copying | The benefit is smaller; a simple improvement may be enough |
| Is there a process owner who will define what a good result is? | Without that there is no acceptance criterion, and the project is judged by impression | Appoint a process owner before starting |
| What does an error cost, and can it be caught before it reaches a customer or money? | This determines how much human oversight is required | Start with a lower-risk process, or route every action through approval |
How to build a test plan for the process you chose — action and user, success conditions, test data and a decision at the end — is covered in a separate guide, so we do not repeat it here. How to plan an AI pilot you can decide on
Human oversight: where the person stays in the picture
Safe automation does not mean there are no people. It means the split between them and the system is defined in advance and recorded. Seven mechanisms recur, and they are also the ones to demand in any proposal:
- Roles and permissions — who may run, approve and change is defined up front.
- Human approval — a sensitive step, or an action that changes data, sends a message or charges money, waits for a person's decision.
- Audit logs — every action is recorded, including who approved it and when.
- Exception handling — whatever fails the rules is routed for handling and does not disappear silently.
- Privacy and security — which data is exposed, where it flows and how long it is kept.
- Monitoring — alerts on failure, slowdown or unusual behaviour.
- Stop and hand over — any flow can be paused or handed back to a person at any point.
A good default is that human approval is broad at the start and narrows only for the types of action that proved themselves when measured against the current state. Not the other way around.
Cost logic: what it is made of
We give no numbers here, because cost depends on the process, the systems being connected and the volume. What can be given is the structure, so you know what to ask to be itemised in a proposal:
| Component | What it consists of | What to ask |
|---|---|---|
| Scoping and build | Mapping the process, designing the flow and controls, building the software and agents | What exactly is included, and what counts as a change of scope? |
| Integrations | Connection to the CRM, ERP, email and legacy systems, including permissions, rate and API limits | Which systems, and what happens when one side is unavailable? |
| Ongoing usage | Use of models and services — usually per call or per action, or a subscription per seat | Is there a ceiling? What happens when volume rises? |
| Maintenance and monitoring | Updating information sources and the model, handling failures, process changes | Who is responsible after go-live? |
| Human work that remains | Approvals, exception handling and spot checks | How much time does this take, and is it included in the comparison? |
When not to do it
There are situations where the honest answer is "not yet", and sometimes "no". Five of them:
- The process is not defined. If every employee does it differently, fix the process first — and sometimes that is all that was needed.
- The process is rare. If it happens a few times a year, the cost of building and maintaining will not be justified, and you cannot measure whether it works either.
- There is no process owner. Without someone who defines what a good result is and checks it, the project is judged by impression.
- An error is too costly to go unchecked, and there is no way to catch it before the damage. In that case the person remains the decider and the system at most prepares material for them.
- The problem is not in the process. If the team is overloaded because people are missing, or the systems do not talk because a simple integration is absent — a solution without AI will be cheaper and steadier.
That is exactly why our first step is mapping the process and the cases where it fails, not building.
What has been built: two cases from the site
We do not present business results here, only what is documented on the case pages. With OneAI we worked for five years alongside the team as a technology partner on a conversational AI platform that developed language understanding, AI agents and voice conversations for businesses. With JUSK we built an employee onboarding platform that includes automations — automatic access opening and reminders over three channels — and tools for building training and tests with AI assistance. Case study: OneAI — a conversational AI platform
The details on JUSK, including what the automations do in the platform, are on its case page. Case study: JUSK — employee onboarding and training
What we do at this stage
If you have a process that answers the five questions, the first stage is mapping: what happens in the process today, where it gets stuck, which systems are involved and what will count as success. The design, the controls and the success measures follow from that. Business automation with AI — process mapping and build
If the question is whether a specific AI capability suits your product, rather than an internal process, there is a page explaining what a pilot includes and how it becomes a stable product. AI in your product — what a pilot includes