At this stage in the project we were given the opportunity to pitch our idea to a panel of key figures from within the Northern Ireland Prison Service. The format was a short 90 second pitch followed by a question, with the goal of getting two panel members interested enough to sit down with us afterwards for a more detailed conversation. Those follow up conversations were where the real value lay, a chance to stress test our thinking against people with genuine firsthand experience of the system we were designing for.
As a group we divided up the responsibilities for this session. Paul took on the service blueprint, working with input from the rest of the group to produce a visual map of how our proposed system would function across the full journey from day one of incarceration through to life after release. My responsibility was to deliver the pitch itself.
Public speaking is something I have always found challenging and it is an area I am actively trying to improve. When it came to deciding who would pitch I put myself forward deliberately. I felt this was too good an opportunity to pass up, not just for the project but for my own development. Pitching a real idea to real industry professionals in a high stakes setting is exactly the kind of experience that builds the skill, and I was not going to learn anything by sitting it out.
The pitch was structured around four parts. Opening with the person, then the problem, then the intervention, and closing on a genuine question for the panel. The goal was to make it feel human and grounded rather than abstract, which is why I opened with Dean rather than a statistic.
<aside> 🗣️
We are designing for someone like Dean. 34 years old, walking out of prison on a Tuesday morning with £46 in gate money and a debt collection letter waiting at his mum's house for a broadband contract he forgot he even had.
The problem is that the moment someone is sentenced, their financial life on the outside does not pause. Direct debits keep firing, interest keeps building and by the time they are released months or years later the debt has snowballed into something they cannot recover from. There is no system in place to catch this and nobody whose job it is to stop it.
Our intervention sits between the prison and service providers. At the point of sentencing it fires an automated alert, pausing billing and financial obligations immediately. It uses existing infrastructure that providers already have and takes inspiration from financial triage models already working in Australia and the US. The technology is not the barrier here. APIs and webhooks make this buildable today.
What we are genuinely unsure about is where the legal responsibility sits. Is this a data privacy problem, a question of getting providers on board, or does it need a change in legislation? We would love to hear from the panel whether this is a technical problem waiting to be built or a policy problem that needs to come first.
</aside>
Alongside the pitch Paul produced a service blueprint mapping out how the proposed system would function in practice across five timeframes. Day one, weeks one to two, sentence duration, day of release, and one to two months after. The blueprint traces the customer actions, touchpoints, frontstage interactions, backstage processes and supporting systems at each stage, as well as identifying the opportunities and risks associated with each phase.
What the blueprint makes clear is that the heaviest lift in our system happens early. The first two weeks are where the most critical actions need to take place, the initial record being created, GDPR consent being obtained, and the API firing verified pause requests to service providers. Once those steps are completed the system essentially maintains itself throughout the sentence duration, with payments remaining paused as an automated state that requires no ongoing human intervention. The day of release then triggers the reverse process, notifications going out to resume payments that the person has chosen to reinstate, and the post release phase connecting them with job centre and financial support services to help them rebuild.
The opportunities and risks section at the bottom of the blueprint is particularly useful as a design tool. It makes visible not just what the system does but where it could fail, from incorrect personal details slowing down the process on day one, to consent not being properly obtained creating GDPR compliance risks in weeks one to two, to a lack of monitoring during the sentence duration meaning system errors could go unresolved.
