Embed

Embed is the phase where we make sure the system gets used. We train your team, support go-live, and hand over ownership. Build delivers something that works; embed makes sure it sticks.

Why this step exists

Plenty of well-built systems fail because nobody adopted them. People revert to spreadsheets, email, or "the old way." Embed exists to prevent that. We run practical training—how to use the system, how to follow the workflow, what to do when something breaks. We leave you with clear documentation so you can onboard new people or remind existing staff. We support you through go-live and the first few weeks so that teething issues get fixed and the new way of working becomes normal.

We also formalise handover. You take ownership of the system: you run it, you maintain it, you decide when to change it. We’re available for support or evolution work if you want it, but we’re not permanently in the loop. Embed closes the loop between "we built it" and "you run it."

What happens in this phase

Training your team

We run training sessions for the people who’ll use the system. We keep them practical and scenario-based: "here’s an enquiry, here’s how you assign it, here’s what happens next." We train key users first so they can support their peers. We leave time for questions and edge cases. We don’t do generic slides; we use your flows and your examples.

Producing and handing over documentation

We give you clear, up-to-date documentation: how to perform core tasks, what to do when something breaks, who to ask for what. The goal is that someone new can get going without us. We keep it in a format you can access and update—shared docs, runbooks, or similar. We avoid long manuals nobody reads.

Supporting go-live

We’re available through go-live to answer questions, fix teething issues, and reinforce the new way of working. We help you spot when people drift back to old habits and suggest simple corrections. We don’t disappear the day you switch on. We’ll agree how long this support lasts.

Transitioning ownership

We agree who owns the system going forward: who runs it, who maintains it, who fields "how do I…?" questions. We hand over access, documentation, and enough context for you to operate and iterate. We can stay on for ongoing support or evolution if you want it, but we’re not assumed to be in the loop forever.

Reviewing and iterating

We do a short post–go-live review. What’s working? What’s not? What needs a tweak? We’ll fix quick wins and flag anything that might need a follow-on phase. We don’t leave you with a list of "we should have done X" and nowhere to go.

What we need from you

We need your team available for training and someone empowered to own the system after we’re done. We also need you to communicate the change—why we’re doing this, what’s in it for them—so people don’t feel it’s being imposed without context.

• Key users and broader teams available for training as we agree
• A clear owner for the system post–handover (could be you or a designate)
• Communication to the team about the change and why it matters
• Feedback during go-live so we can fix issues quickly

What you get out of it

You get a team that can use the system confidently and the materials to sustain it.

• Training delivered to the right people, with scenarios that match your workflow
• Documentation: how to do key tasks, what to do when things go wrong, who to ask
• Support through go-live and early use so adoption sticks
• Clear ownership: you run and maintain the system; we’re available if you need us

Common concerns

Time commitment. Embed usually runs over a few weeks—training, go-live, and a short support window. We’ll propose a schedule. Training sessions are typically 1–2 hours; we’re not locking people in all day.

Disruption. Go-live is a change. We’ll agree when it happens and how we cut over (e.g. pilot first, then full). We minimise disruption by training ahead of time and being available when you flip the switch. We’ve seen teams adapt quickly when the system actually makes their job easier.

Cost anxiety. Embed is a defined phase. We’ll scope and price it up front. Skipping it often means poor adoption, workarounds, and eventually "the system doesn’t work"—which costs more than doing embed properly.

Tool access. We don’t need new tool access for embed. We’re training on what we’ve built and configured. If we need to tweak something during go-live, we’ll use the same access we had in build.

Confidentiality. Training and docs will reflect your workflows and sometimes your data structures. We treat them as yours. We don’t reuse them elsewhere without your permission.

Internal buy-in. Some people are reluctant to change. We design training around how they actually work, and we help you message the "why." We’ve found that early wins—e.g. fewer chasing emails, clearer ownership—often convert sceptics. We’ll help you identify and talk about those.

A typical example

Illustrative example. A home-services business had just finished build: intake from web and two job boards, assignment by region, and handover to their job system. Embed ran over three weeks. Week 1: we trained the office manager and two team leads on intake, assignment, and status. We gave them a one-page cheat sheet and a short runbook for common issues. Week 2: we switched on for real and stayed available. We fixed a few routing edge cases and answered "how do I…?" questions. Week 3: we did a short review, handed over ownership, and stepped back. They’d already been using it daily; embed made it official and made sure they could run it without us.

Next step

Once embed is complete and you’re running the system, evolve is optional: we can help you iterate, fix issues, and add small improvements over time. Read about the evolve phase, or get in touch to discuss training and go-live.