Who this is for.
You’re in a meeting with your team discussing the overhaul of your digital infrastructure. The rest of the room looks satisfied; the supplier’s project proposal ticks the boxes for scope, timeline, deliverables, and budget. But that nagging feeling appears again.
You flick through the plan again. Hold on, what does our team look like six months after this project closes? You ask. Someone replies something vague about efficiency, and it’s here you realise that the team has spent all their time on the project and not the aftermath.
You look at the training section again. It’s in the appendix, two pages from the end, and just three bullet points. You know the team well enough to know there’s a gap between where they are now and where they’d need to be to run this themselves. But it hasn’t occurred to them to ask the supplier to address it. It wasn’t in the brief, but it should be.
The backstory.
Wales Air Ambulance is the only air ambulance charity dedicated to the people of Wales. It runs four helicopters from bases across the country, is on standby 24 hours a day, and has completed more than 43,000 missions. It relies entirely on charitable donations to keep flying.
One of its main income streams is the Lifesaving Lottery, a membership-based lottery that generates recurring donor income. Running it required staff to manage two separate systems manually, with tasks including inputting player data, generating sign-up letters, processing direct debits, managing cancellations and running the lottery draw itself. There was an administrative burden which grew as the lottery grew.
In 2022, the charity brought in an external partner to begin automating its back-office, retail and contact channel operations, starting with the lottery, with the aim of increasing efficiency and enabling operations to scale without manual overhead.
Reality check.
The 2024 Charity Digital Skills Report revealed that 60% of charities identify securing funding for infrastructure, systems and tools as the biggest barrier to digital progress. This represents a significant increase from the 49% who reported the same issue the previous year.
When the majority of charities struggle to fund ongoing digital infrastructure, and Wales Air Ambulance was an example of this, with limited funds for moving manual processes to digital, any transformation that creates dependency on suppliers beyond the project period poses not only an operational risk but also a mismatch in the funding model.
New digital systems need to be designed to be viable and manageable for charities before the project engagement concludes, as there is typically no line item in the subsequent budget to sustain the supplier’s involvement.
The real problem.
For Wales Air Ambulance, every newly acquired lottery player generated a celebration and a plethora of manual tasks. Whether players were retained, cancelled or dormant, their actions required human processing. The team’s capacity hit a ceiling that could not keep up with the organisation’s ambitions.
Every ops leader knows the obvious fix is automation. The less obvious problem, however, hides beneath every conversation about scope, timeline, and cost, and it rarely surfaces.
It is common for small teams looking to scale on limited funds to miss the question of what happens when the supplier steps away. Will the system work? Of course it will. But what does the handover process look like? And the unnoticed risk is will the team be able to run it, adapt and troubleshoot themselves? That is less often asked, and frustratingly, many suppliers sidestep this accountability too.
The handover in the charity sector is made more complex by a funding landscape that often ties digital infrastructure work to restricted grants or one-off project budgets that are fully spent by the time the digital build ends. There is often no buffer or ongoing budget line for supplier support, and rarely is there a contractual requirement for how post-project ownership is handled.
What they did.
The digital transformation began with a strategic decision to narrow the scope, using the lottery as a proof of concept. This was easily done, as it was a single, well-defined process involving high volumes and repetitive tasks, making it an ideal candidate for automation. The lottery also generated enough activity for the team to manage the changes effectively before expanding the scope to other areas. From the outset, the guiding principle was to validate the model in one area before extending it further.
An external partner built a digital worker solution, an automated process that handles daily BACS payment reports, adds new lottery members, processes cancellations, and runs the draw.
Training and knowledge transfer were included as deliverables from the start of the engagement, with the explicit aim of eliminating the need for future third-party support.
By the time the engagement concluded, Mandy Dunell, Lottery Administration Manager, and her team were running the digital worker themselves.
The toolkit.
Most digital transformation briefs describe what the supplier will build. These tools describe what your team will be able to do when the supplier leaves.
Ownership brief. | Written before any engagement begins and added to the supplier brief as a formal deliverable, so that it becomes part of the contractual requirements, this is a one-page document that identifies the specific capabilities your team should have by the end of the project. This is less about outcomes like “the team owns efficient processes” and more about capabilities such as: “the team can run the BACS payment reports and troubleshoot common issues without supplier support.” |
Capability sign-off checklist. | Used at the end of the engagement to verify the brief has been met, this is a list of tasks that your team should be able to complete independently before the supplier steps away. Both parties should agree on the list and sign off on it. Each task should be easy to observe: can the team run the process, handle a failure, or make a configuration change? The supplier should not exit until the checklist is complete. |
Change narrative document. | A one-page document written and shared before go-live that explains what has changed, why, and what it means for each role in your team. If staff can describe what an automated process does, they are more likely to engage with it, flag problems early and adapt around it. |
What shifted.
The team transitioned from manually running the lottery to overseeing it, with the time saved redirected towards supporter engagement.
Wales Air Ambulance saw an impact quickly, with the time spent on daily BACS reports reduced by 50%. The time required to add new lottery members has decreased by 92%. Processing membership cancellations has freed up half a day per week for the team. Sending new member letters by email instead of by post has saved £20,000 annually. And by delivering improvements across the whole organisation, from operations to governance, in ways that manual processes struggled to meet, the automated process is also fully auditable and complies with statutory and legal requirements.
The numbers indicate released capacity. The lottery can now accommodate more members with less manual effort than before automation. However, it is unclear whether this change represents a permanent reduction in operating costs or a productivity gain that allows for more capacity to be directed towards other tasks. What is evident is that the manual support, the minimum staff effort needed to keep the lottery running, has decreased, and it is not likely to increase even as membership continues to grow.
Why it worked.
Two key design choices made a significant difference, and both are replicable.
The proof-of-concept structure ensured that learning was manageable. By starting with a single, contained process, the Wales Air Ambulance team could absorb changes and build confidence before expanding scope. If a transformation is too broad or moves too quickly, it can lead to dependency, as the team may never fully master any individual part. By limiting the first phase to time, scope or action, the team could achieve self-sufficiency before moving on to the next phase. The main idea is to organise your scope so that capability is developed before it is stretched.
Training was considered a key deliverable. Knowledge transfer occurred concurrently with the project build, with the expectation that the team would be able to manage, troubleshoot, and adapt the new process by the end of the project. This approach requires the supplier not only to build the solution but also to teach the team. The project brief must explicitly require this level of involvement, thereby making self-sufficiency a success criterion rather than assuming it will naturally arise from effective delivery.
Where this breaks.
Capability is not fully established simply because training has occurred once. It is truly established when ownership persists despite challenges such as scaling, complexity, and staff turnover.
Often, the proof-of-concept succeeds, boosting confidence as the scope expands, even though the internal capability may not yet be fully developed. While the team feels confident about the new process, they are uncertain about everything that follows. If something goes wrong in the second phase, the team tends to rely on the supplier again, leading to dependency re-emerging on a larger scale.
For Wales Air Ambulance, the next phases saw the internal capability tested at a greater scale and complexity, with the implementation of an automated, real-time operational dashboard, an omnichannel donor experience centre, and AI-driven identification across departments. When something breaks in the new scope, does the team fix it themselves, or does the call go back to the supplier? The early warning sign here is whether the team is operating the expanded system but has not yet made a single change on their own.
Another challenge arises when the internal champion, who facilitated knowledge transfer, leaves the organisation. The process may continue to run smoothly at first. But when issues arise or when configuration adjustments are necessary, no one on the team has the depth of knowledge to address them. What seemed like an embedded capability was, in fact, concentrated in just one individual. The early warning sign in this scenario is that all troubleshooting questions are directed to the same person.
Finally, when the brief specifies a training plan without a focus on capability outcomes, the supplier provides the training, and the team attends. However, six months later, the organisation struggles to adapt the system without external support. While training was conducted, the actual transfer of capability did not occur. The usual indicator here is that during the handover, the team is able to provide a comprehensive explanation of how the system functions. However, they are unable to demonstrate the procedures for addressing potential issues that may arise. This gap in their ability to respond to problems casts doubt on the system's reliability and the team's preparedness to manage unexpected challenges.
Still brewing.
For Wales Air Ambulance, the outcome of self-sufficiency was determined primarily by the supplier’s approach. While it is essential to include self-sufficiency in the brief, if the supplier’s model does not prioritise knowledge transfer, the desired outcome may not be achieved. The brief and the supplier’s model need to be aligned; otherwise, the brief may look strong on paper, while the supplier’s execution determines whether the project is successful six months down the line.
Most charities don’t consider ownership strategies, leaving supplier selection to procurement decision-making. Can the suppliers you are evaluating for your next project tell you specifically how they approach knowledge transfer? Can they point to engagements where they have done it and show you what the outcome looked like? If the answer is vague, training is probably an appendix item for them too, and you already know where that ends up.
Sources for this case study: https://www.arvatoconnect.co.uk/
Third Sector, April 2023; Wales Air Ambulance Annual Report 2023–24; The Business Desk, August 2023; Charity Digital Skills Report 2024.
Note: the specific document titles used here reflect Coffee Break Ops’ interpretation of the framework's requirements. The source case study describes the approach and outcomes. Some document names have been inferred from common practice in equivalent implementations.
Every week, a real ops problem from a real charity:
What they did, what it reveals, and what you can take back to your desk.
Sign up to get it in your inbox.
