Six steps from first conversation to a running system

Nothing is built before the journey is mapped, and nothing is launched before it is tested against real cases. How long each step takes depends entirely on what discovery finds — which is why there are no durations on this page.

1. Step 1

   Discovery

   Understanding the business before proposing anything.

   A structured conversation about how your business actually operates: what you sell, who buys it, how many enquiries you get and through which channels, who handles them today, and what happens when that person is unavailable. We are looking for the specific points where customers are lost — not for an opportunity to sell every service in the catalogue.

   What you provide

   • Time with the people who handle enquiries today
   • A realistic sense of enquiry volume and seasonality
   • The tools you currently use, and which ones you actually rely on
   • Any constraint we should design around — budget, staffing, legal, or contractual

   What you get

   • A written summary of what we understood
   • The specific gaps we think are costing you customers
   • An honest view on whether automation is the right answer at all

2. Step 2

   Customer journey mapping

   Drawing the path a customer actually takes, including the broken parts.

   We map every route a customer can take from first contact to purchase and beyond — every channel, every handoff, every point where a person has to do something for the process to continue. The point of the map is to make failure points visible: from inside the business they are hard to see, because from inside they look like normal busy days.

   What you provide

   • Access to observe or review how enquiries are handled now
   • Examples of recent enquiries, including ones that went badly
   • Confirmation of what the process is supposed to be, so we can compare it to what it is

   What you get

   • A journey map covering every channel you use
   • The failure points, ranked by how much they are likely costing
   • A recommendation on which to address first, and which to leave alone

3. Step 3

   Solution design

   Deciding what will be built, and agreeing it in writing.

   The design names each component, what it does, which systems it touches, and what has to be true for it to work. Qualification rules, handover conditions, follow-up intervals, and message content are all decided here rather than during build, because these are your decisions and they are cheaper to change on paper.

   What you provide

   • Decisions on qualification criteria and routing
   • Approval of message content in each language
   • Confirmation of which channels are in scope
   • Named owners for anything the system escalates

   What you get

   • A written scope covering every component and integration
   • The service level the work falls under, and what drives the cost
   • A clear list of dependencies and anything we consider a risk

4. Step 4

   Implementation and integration

   Building it, and connecting it to what you already run.

   Agents are built and trained against your knowledge base, forms and touchpoints are created, capture and qualification are wired up, and the integrations are connected using credentials issued from your own accounts. You keep ownership of every account throughout — nothing is created under ours.

   What you provide

   • Access and credentials for each system in scope
   • Content, service details, and the answers the agent will use
   • Availability to answer questions as edge cases surface

   What you get

   • Each component built and connected
   • Integration error handling and alerting
   • Progress you can see, rather than a status update at the end

5. Step 5

   Testing and launch

   Running real cases through it before customers do.

   We test against real enquiries, including the awkward ones: the customer who changes their mind halfway, the message in a third language, the caller who wants something you do not offer. Launch is staged where it can be — one channel first, then the rest — so problems surface at a small scale.

   What you provide

   • Test cases from your own experience, especially the difficult ones
   • Review and sign-off on how the agent responds
   • A decision on launch order across channels

   What you get

   • Testing across languages, channels, and failure paths
   • A staged launch with the ability to roll back
   • Handover documentation and training for whoever operates it

6. Step 6

   Support and optimisation

   Keeping it correct as the business changes.

   Automations drift. Prices change, services are added, a platform changes its rules, and a conversation flow that was right in March is wrong by September. Ongoing support covers monitoring, adjusting the flows, extending the system, and telling you when something has stopped working — which is the part that is easy to notice too late.

   What you provide

   • Notice when your services, prices, or hours change
   • A point of contact for questions and adjustments
   • Feedback on where the system is getting things wrong

   What you get

   • Monitoring and alerting on failures
   • Adjustments to conversation flows and rules
   • Regular reporting on what the system handled
   • Extension of the system as new needs appear