1. Tell us the problem in writing
Each engagement opens with a short written brief, sent through the Start a project form or typed to the assistant in the corner of any page. A few lines in your own words are enough. Describe the symptom rather than the solution: “evening calls go unanswered” or “the team spends each morning on order-status questions” tells us more than a list of features.
Add where the work happens today, who does it and which systems it touches. If you already know who on your side will approve the result, name them as well.
2. Read the proposal within one business day
Within one business day you receive a proposal on paper. It sets out the scope, the delivery date, the approval points and the expected running cost on your own accounts, with a fixed price in the written proposal. Nothing is committed until you accept it.
The accepted proposal is the agreement. The brief does not grow quietly afterwards: any change is written up as a change of scope, and you accept or decline it in the same thread.
| In the proposal | Why it is there |
|---|---|
| Scope | What will be built, and what will not |
| Delivery date | When the staging copy opens for you |
| Approval points | Which actions wait for a person you name |
| Running cost | What your own accounts will be billed for the system each month |
| Price | Fixed before work starts, and changed only by a written change of scope |
3. The build, with approvals designed in
Work starts on the accepted proposal. Updates arrive in writing as each part is finished, and questions are collected and sent together, so you answer once rather than all week.
Approval gates are part of the design from the first day. Anything that moves money, closes an account or cannot be undone is drawn as a step that waits for a person, and it stays that way after go-live.
4. Watch the recorded demo before the final payment
Before the final payment falls due, you receive a recorded demo of your system doing its work on a copy of your setup. Watch it as often as you like, pass it to a colleague and take your time over the decision.
You can also try it on staging with your own cases. It moves to live only when you approve it in the thread.
5. Go live with the handover in hand
On the day it goes live you receive the handover: what runs, where it runs, how each connection is set up and how to change it, written for the people who will look after it. The accounts, the data and the keys are in your name.
From then on the system is yours to run. If you would rather we kept watching it, fixed it and reported on it each month, the AI Operations Partner engagement takes it over from there.
What you keep from each step
- The brief. Your own words about the problem, the systems and the person who approves.
- The proposal. Scope, date, approval points, running cost and the fixed price.
- The recorded demo and the staging record. The system at work on a copy of your setup, and your approval to go live.
- The handover note. What runs and how to change it, with every account in your name.
All four sit in one thread, so anyone on your side can see how each decision was reached. The steps behind them are set out on How we work.