KrelunaWhich business processes should you automate first?
The best first project is rarely the largest. Choose a frequent, sufficiently stable, measurable and reversible part of a process so the organisation can learn within a controlled scope.
1. Define the outcome before the tool
“Use AI” is not an operational objective. Better outcomes include reducing request-classification time, making stalled work visible, preparing a first draft while retaining approval, or consistently recording information already present in a document.
Also document what must not change: who decides, which checks remain mandatory, which data is excluded and which systems must not be changed automatically.
- One concrete problem and baseline
- An accountable owner
- In-scope data and systems
- Decisions that remain human
2. Map the process as it actually works
Observe real cases rather than relying only on the written procedure. Record the trigger, input, owner, system, rules, approvals, exceptions, output, working and waiting time, errors and rework.
Remove obsolete steps and resolve unclear ownership before automating. Technology should not preserve an avoidable defect.
- Clear beginning and end
- Manual work and system hand-offs
- Exceptions and incomplete cases
- Time, errors and reviews
- A route back to the manual method
3. Score candidates consistently
Compare candidates using the same criteria. Strong first projects tend to have high frequency, standardisation and measurability but lower data sensitivity, error impact and dependencies. The score makes assumptions visible; it does not replace judgement.
- Frequency and time consumed
- Clarity of the rules
- Input quality and availability
- Measurability
- Error reversibility
- Data sensitivity and potential impact
- Systems, teams and suppliers involved
4. Strong first-automation candidates
These examples may be suitable only after data, tools, responsibilities and integrations are verified.
- Initial request classification with human confirmation.
- Proposed organisation of non-critical documents without automatic deletion.
- Field extraction from regular formats with operator review.
- Reminders and checklists based on a defined source.
- Internal drafts and summaries that include review time in the measurement.
5. Processes to defer
A first project should avoid irreversible or high-consequence activities. Some may become appropriate later with proportionate expertise and controls.
- Automatic payments, orders or transfers
- Irreversible deletion or modification
- External communication without approval
- Legal, tax, medical, disciplinary or hiring decisions
- Unnecessary broad access to confidential data
- Unsupported integrations using shared credentials
- Processes without an accountable owner
6. Design exceptions and a safe stop
Reliable automation does not attempt to handle every case. It recognises when to stop, makes the exception visible and assigns it to the right person.
- Conditions requiring review
- Exception queue and owner
- Escalation timing
- Traceability of input, output and approval
- Access revocation and manual fallback
- Behaviour during outages or errors
7. Measure the pilot without inventing certainty
Collect a baseline before testing. Consider total time, active work, correction rate, errors by category, exception volume, review time, incidents and user experience.
A faster process that is less accurate, controllable or safe is not necessarily better. Choosing not to automate can be a valuable result when it prevents a larger fragile investment.
Do not rely on “hours saved” alone. Quality, control, exceptions and reliability are part of the outcome.
A practical 30-day plan
- Week 1 — observe one process, collect examples and measure the baseline.
- Week 2 — define data, roles, permissions, exceptions and stop criteria.
- Week 3 — test a small sample, preferably in recommendation mode.
- Week 4 — compare measures and feedback; expand, revise, retain assistance or stop.
Kreluna is in active development. Capabilities and integrations are verified before a pilot is proposed.
A scorecard to complete with the process team
Assess every candidate with the same questions. Do not treat the score as certainty; use it to make differences and objections explicit.
- Frequency and effort
How often it happens and how much human effort it takes, separating activity from waiting.
- Stability and rules
How often the flow changes and which parts can be described without hidden knowledge.
- Data and exceptions
Source quality, out-of-pattern cases and the consequence of error.
- Value and control
Expected outcome, accountable owner, measure, safe stop and maintenance cost.
Prioritisation questions
Should the most expensive process always go first?
No. It may be unstable, risky or lack suitable data. A smaller candidate can deliver more reliable learning.
How many exceptions are too many?
There is no universal threshold. What matters is whether exceptions are recognisable, manageable and compatible with the workflow’s value.
How should ROI be estimated?
Compare time, errors, rework and operating cost with an observed baseline. The guide’s example is not a promise of results.
Institutional sources and further reading
- NIST — AI Risk Management Framework CoreGovern, map, measure and manage risks throughout an AI-enabled workflow.
- European Commission — GDPR principlesPurpose limitation, minimisation and data protection considerations.
Start with one defined use case
Describe the objective, current workflow and general type of information involved. Do not send credentials, personal data or confidential documents in an initial message.