Turn “we need AI” into a specific job.
AI implementation means introducing AI into a process with an input, an expected output and an owner. An assistant that drafts replies from approved documents is a defined use case. “AI across the company” still needs a scope.
We start with work that involves reading, classifying, finding or rewriting information. We identify where AI may help, where rules are enough and where a person’s judgement remains essential. The first project should establish usefulness in everyday work.
| Situation | First output to evaluate |
|---|---|
| Orders in emails and attachments | A draft with extracted fields, missing information flagged and review before entry into the business system. |
| Recurring support questions | A proposed response using approved sources, with uncovered cases passed to an operator. |
| Information spread across tools | A summary linked to source information and available only to authorised people. |
What an implementation project includes.
Process and feasibility assessment
Map the current workflow, effort, exceptions and tools. The output is a project scope with constraints, required data and evaluation criteria.
A prototype on representative examples
Build a sample that includes ordinary, incomplete and difficult cases. Compare outputs with expected results before connecting real actions.
Integration and controls
Connect agreed tools, separate reading from writing and provide review, error handling and records of outcomes.
Supported introduction and team handover
Define who handles exceptions, how to stop the flow, which costs to monitor and how to update instructions and sources. Documentation and support arrangements form part of the agreed scope.
A first pilot with explicit boundaries.
One possible pilot prepares draft orders from one inbox for one product family. The system proposes fields; a person checks and approves them. Missing prices, unknown products and ambiguous requests go to an exception queue. This is a project example, not a reported client result.
- One process, one operational owner and a defined set of inputs.
- An evaluation sample kept separate from examples used to configure the system.
- Agreed measures: field accuracy, review time, rework and cost per case.
- An explicit decision at the end: expand, revise or stop.
When AI is not the right next investment.
If the rule is stable and the input already structured, conventional automation may be simpler to control. At low volumes, recoverable time may not justify maintenance and review. If no one can assess the output, the project is missing a way to evaluate success.
Inconsistent data, unclear ownership or a process that changes every week may need organisational work first. We make these constraints visible alongside alternatives already available in your tools.
How to evaluate an AI implementation partner.
- Ask for a demonstration on relevant cases, including exceptions, and written acceptance criteria.
- Clarify ownership of accounts, configurations and data, and what the handover includes.
- Separate implementation fees, usage, licences, maintenance and internal work.
- Ask how access, provider changes, failures and manual recovery will work.
- Agree on the process owner after launch and the support arrangement.
A template to work from.
First AI pilot brief
An editable Markdown template for your process, data, owners and go/no-go criteria.
Download the Markdown templatePractical questions
Do we need an internal technical team?
You need at least an owner who understands the process and can assess outputs. IT involvement depends on access, integrations and data. These dependencies should be identified before the project scope is agreed.
How long does AI implementation take?
Timing depends on scope, usable examples and access to the tools involved. A credible schedule needs a defined workflow, a usable sample and an integration assessment. The plan should distinguish assessment, pilot and operational introduction.
Do we have to replace our CRM or business software?
Not necessarily. We first assess native features, APIs or exports in the existing tools. If access is unavailable, we identify the constraint and agree on an alternative or narrower scope.
Can you guarantee savings before the pilot?
No. We can model a scenario using your inputs, then measure review time, errors and costs during the pilot. Recovered time becomes an economic saving only when it changes resource use or productive capacity.