How it works
How an AI installation actually happens.
Thirteen steps take a company from first conversation to a monitored, documented AI system its team actually uses. No strategy decks — a working installation, built inside the tools you already run on.
The full process
Thirteen steps, four phases
Every installation follows the same discipline: understand the work, design the system, build and prove it, then run it in production. Here is what happens at each step — and what you have in hand when it is done.
Phase 1 · Steps 01–05
Understand
Before anything is designed, we learn how your company actually operates — from the people who do the work, not just the org chart.
- 01
Discovery
Structured conversations with leadership, team leads, and the people who actually do the work. We ask how work flows day to day, where it stalls, what it costs when it goes wrong, and what a good outcome would look like. Nothing is proposed yet — this step exists to understand, not to pitch.
Deliverable — a written summary of how the business operates and what it wants to change.
- 02
Process mapping
We document the relevant processes step by step: who does what, in which system, with what information, and where the handovers happen. The map almost always differs from the official procedure — real work rarely matches the manual — and both versions matter. You review the map and correct anything we misread.
Deliverable — a step-by-step process map verified by your team.
- 03
Opportunity prioritization
Each mapped process is assessed on practical value, complexity, risk, data availability, and how much change it asks of employees. We recommend a shortlist and explain the reasoning; leadership decides what is in scope. The goal is one focused first installation, not a company-wide program on day one.
Deliverable — a prioritized shortlist and an agreed first process.
- 04
Technical assessment
We examine the systems behind the chosen process — what has an API, what can be integrated directly, and where a different route is needed. This is where feasibility gets honest: some ideas are inexpensive to build, others are not worth their cost yet. You get a clear read on effort before anything is committed.
Deliverable — a feasibility assessment for the chosen process.
- 05
Data and access review
We map what data the system will touch, where it lives, who is allowed to see it, and which actions need sign-off before they run without a human. Access boundaries and permissions are agreed with you before development starts, and the installation is then built within the security, access, and approval requirements defined for your specific implementation.
Deliverable — an agreed access, data, and approval plan.
Phase 2 · Steps 06–07
Design
The installation is agreed on paper and proven at a small scale before serious build effort is committed.
- 06
System design
The installation is designed in full before it is built: the workflow, every integration, what the AI is responsible for, what employees remain responsible for, and exactly where a human must approve before anything is sent or saved. Success criteria are defined now, so that “working” is measurable later. You sign off on the design before development begins.
Deliverable — a signed-off system design with success criteria.
- 07
Prototype
We build a first working version of the core workflow and run it on real examples from your business — real emails, real documents, real cases. You see actual output early, while changing direction is still cheap. Weak assumptions surface here instead of after launch.
Deliverable — a working prototype demonstrated on your own cases.
Phase 3 · Steps 08–10
Build
The system is connected to your real tools, tested against real cases, and put in the hands of the people who will use it.
- 08
Integration
The system is connected to the tools your company already uses — CRM, inbox, calendar, documents, internal databases — through official interfaces wherever they exist. Data flows are designed to be traceable, so it is always possible to see what was read and what was written. Everything runs in a controlled environment; nothing goes live in this step.
Deliverable — a fully connected system running in a controlled environment.
- 09
Testing
The full workflow is tested against real historical cases and deliberately awkward ones — incomplete information, unusual requests, the edge cases your team knows well. Approval checkpoints are exercised and tuned, not just designed. Testing continues until behavior is consistent enough to put in front of your team.
Deliverable — documented test results across real and edge cases.
- 10
Employee training
The people who will use and supervise the system are trained on real scenarios: what it does, what it must never do on its own, how to review its output, and how to correct it. Documentation is written in plain language for your team, not for developers. Adoption is treated as part of the installation — a system nobody uses has failed.
Deliverable — trained employees and plain-language documentation.
Phase 4 · Steps 11–13
Run
Launch is the beginning, not the end — the installation is monitored, improved, and expanded based on how it performs on live work.
- 11
Launch
The installation goes live on real work — usually gradually, starting with one team or a subset of cases. Human approval checkpoints stay exactly where the design put them. Your team knows what changed, from what date, and who to contact the moment something looks wrong.
Deliverable — a live installation with a clear support route.
- 12
Monitoring
After launch, we watch how the system performs on live work: what it handles well, where it hesitates, and what your team overrides. Logs and reports make its behavior reviewable rather than mysterious. Weak points are fixed as they appear, and every change is documented.
Deliverable — regular performance reviews and a documented change history.
- 13
Expansion
Once the first installation is doing its job, we look at what should come next — a neighboring process, another department, or a deeper version of the same workflow. Expansion follows evidence from the running system, not a pre-sold roadmap. Each addition goes through the same design, testing, and approval discipline as the first.
Deliverable — an evidence-based proposal for the next installation.
Sample project architecture
What an installed system looks like
One possible implementation: inquiries arrive by email, phone, and web; an AI layer extracts, classifies, and drafts; a named person approves; connected business systems are updated; and every stage is logged.
Input channels
AI processing layer
Human approval
A named reviewer approves output before anything leaves the system
Business systems
Monitoring & logs
Every stage writes to an activity log your team can review — the basis for reporting and improvement
Who does what
Responsibilities during an installation
An installation succeeds when responsibilities are explicit. This is how the work divides between us, your team, and the people around your systems.
- AI Installer
- Runs the process end to end: discovery, design, development, integration, testing, documentation, and training. After launch, monitors the installation, fixes weak points, and proposes what to improve or expand next. Accountable for the system doing what the agreed design says it does.
- Client leadership
- Decides which processes are in scope, approves the system design and the rules the AI must follow, and makes the final call on launch and expansion. Leadership sets the boundaries; we build within them. Most decisions are compact and well-prepared — approve a design, confirm a checkpoint, choose a next step.
- Employees
- Work alongside the system day to day. They use its output, correct it when it is wrong, and flag anything unusual — their feedback is a primary input for improvement, not an afterthought. The installation is shaped around how they work, not the other way around.
- IT or software providers
- Provide access to the systems the installation connects to — accounts, permissions, API credentials, and test environments where they exist. Where a company has no internal IT team, we coordinate directly with the software vendors involved.
- Human reviewers
- Named people on your team who approve the system’s output at the checkpoints defined in the design — before an email is sent, an offer goes out, or a record is changed. Approval rights sit with your team. Removing or relaxing a checkpoint is a leadership decision, never something the system does on its own.
See this process applied to your company.
The thirteen steps start with a conversation: how one of your processes runs today, and what steps 01 and 02 would look like in practice.