The customer journey does not stop at the hand-off

Somewhere in the UK today, someone put the phone down after a difficult call about their debts. They were told: "we'll pass this over to the creditor," or "our partner will be in touch." Then the waiting starts. And waiting, when you're already anxious about money, is its own kind of stress.

They don't know - and shouldn't have to know - that 'passing it over' might mean a CSV file landing on an SFTP server, an email into a shared mailbox, a note logged in a CRM the other organisation will never see. To them, none of that matters. What matters is that the next person actually knows what's happening, the promised action happens and they won't be asked to repeat their story from scratch to someone new.

Sounds simple. It isn't. I've spent most of my career inside regulated customer journeys - debt advice, debt management plans, IVAs - where nothing works unless several teams, systems and partner organisations each hold up their end. And the hand-off is where information tends to fall through the cracks. Context gets crushed into a handful of form fields. Ownership blurs the moment a case crosses an organisational boundary. Everyone can point to their piece and say 'done' - while the customer is still waiting. That's why I've stopped treating partner collaboration as back-office plumbing. It affects front-line customer experience. And it deserves to be designed - and measured - with that in mind.

The cracks between systems

Most organisations can tell you a great deal about work that stays within their own walls: when a case opened, which queue it sat in, who handled it, when it closed. But cross an organisational boundary, and that picture degrades fast.

A referral goes out. An email lands in a shared mailbox. A spreadsheet gets uploaded on Friday afternoon, because it's always been uploaded on Friday afternoon. Days later, a status comes back - often in a different format, rarely with enough detail to explain what actually happened. When something stalls, the first job isn't usually fixing it. It's figuring out who owns it.

The sector I work in makes this especially visible. An adviser agrees a plan with a customer and needs a creditor to confirm balances, pause interest or accept an offer. Partway through, the creditor might sell the account to a debt purchaser, sending much of that conversation back to square one. An IVA referral moves from an advice provider to an insolvency practitioner. A Breathing Space notification lands with a dozen creditors at once, each of whom has to identify the debt and apply the right protections inside their own systems. Every one of those steps crosses a boundary. And at every boundary, each system can be working exactly as designed while the customer's journey quietly falls apart underneath it.

The failure I see most often isn't a partner doing nothing. It's that everyone involved is using a different definition of done. One organisation has sent the work. Another has received a file. A third is waiting on missing information. Each local measure looks perfectly reasonable yet nobody holds a reliable view of the end-to-end commitment made to the customer. That is the hand-off gap: it's easy to record individual actions, but harder to address the issues raised by shared responsibility.

Email is a communication tool, not an operating model

Email and spreadsheets persist because they are flexible, familiar and cheap. They are also remarkably good at hiding operational weakness. An inbox can prove a message was sent. It creates no structured ownership of the next action. A spreadsheet can move five hundred records in a minute, but it cannot tell you which version is authoritative, who changed a status, whether an exception was ever resolved or what the customer was told in the meantime.

Teams compensate, and they often compensate brilliantly. There are reconciliation exercises, shared mailboxes with colour-coded categories and a tracker that lives on one person's desktop. There is always a colleague who knows exactly which creditor contact to chase when something goes missing. I have real respect for those people. I have also seen what happens to an operation in the week they are on leave. If a process depends on somebody noticing that yesterday's return file contained 498 responses to 500 requests, the control is not the spreadsheet. The control is the person who spotted the missing responses. Good people will bridge poor systems for a surprisingly long time. That does not make the systems safe. It makes the weakness harder to see.

Consumer Duty makes the boundary harder to ignore

The regulatory direction is not subtle. The Financial Conduct Authority's (FCA's) Consumer Duty expects a firm to ensure good outcomes across the distribution chain, not just within the slice of the journey in which it happens to operate. The FCA and Information Commissioner's (ICO's) joint statement on vulnerability-related data published in March 2026 says manufacturers and distributors should work collaboratively and share relevant information where that is necessary to deliver good outcomes. It also recognises that, in some circumstances, an individual customer's needs may have to be disclosed to partners so appropriate support can continue.

None of that makes a firm responsible for every action of another firm it deals with. It certainly doesn't licence moving customer data around a partner network without restriction. What it does is close off a familiar excuse. An organisational boundary is no longer an excuse for losing sight of a customer outcome that depends on the chain working as intended. The FCA's own work on vulnerable customers found gaps in data from distributors and third parties that limited firms' understanding of outcomes across the chain. It also found that firms were failing to monitor third-party interactions less as well as in-house work. Read that as a technologist and it's not a request for another dashboard, it's a traceability requirement.

A controlled hand-off: 5 questions you should be able to answer

Whenever work passes between organisations, you should be able to answer five questions.

1. What has been handed over?

The task and expected action should be explicit, with both parties working from the same reference. A file called 'March referrals v2 FINAL' and an email subject line are not a shared understanding.

2. Who owns the next action?

Ownership should move deliberately, not vanish somewhere between an outbound queue and an inbound mailbox. If an item is rejected or cannot progress, responsibility for resolving the exception needs to be just as clear as responsibility for the happy path.

3. What does completion mean?

Sent, Received, Opened and Completed are different states. In this sector, creditor contacted is not the same as interest frozen, and referral made is not the same as advice given. The agreed outcome should be defined in operational terms that both organisations use consistently.

4. What does the customer need while the work is moving?

A customer may need an update, a different contact channel, extra time or continuity of personalised support for reasons they have already disclosed. They should not have to repeat those needs simply because a different organisation now owns the task.

5. Can the journey be reconstructed afterwards?

There should be an auditable history of allocation, access, status changes, exceptions and completion. When a complaint arrives or a case is escalated, the answer should not depend on desperately scouring four inboxes and asking colleagues what they remember.

These questions are deliberately unglamorous. If the technology can't answer them, adding more automation will simply move unclear work around faster.

Avoid oversharing

Better continuity does not mean sharing customer data without restriction. The FCA and ICO statement is useful here. It describes data protection law as an enabler of responsible data sharing, while reinforcing purpose limitation, accuracy, minimisation, transparency and security.

In practice, organisations need to know why information is being shared, whether sharing it is necessary, who can see it, how long it will be kept and what the customer has been told. This matters most where the information touches health, vulnerability or other sensitive circumstances. The receiving partner may need to know the support requirement without needing the customer's full history. 'Please communicate in writing and allow additional time' may be operationally necessary. The medical detail behind that request may not be. Good partner technology should make that distinction easy.

Access should be determined by rules and permissions. Required fields should relate to the purpose of the hand-off. Changes should be recorded, and access removed when a user or partner no longer needs it. Data minimisation is sometimes presented as the reason systems can't share useful context. I see it the other way round: it is the design requirement that forces us to share the right context deliberately.

A notification isn't accountability

One of the easiest mistakes in workflow design is confusing telling somebody something needs doing with making sure something happens. Notifications have their place. They can tell a partner that work is waiting or alert a team to an exception. But a notification without a visible queue, an owner, an expected action and an escalation route is just another message competing for attention in an inbox that may already be bursting at the seams. The control is the state of the work item, not the number of emails generated about it.

This is why I prefer shared queues and explicit statuses to chains of free-text updates. They create a common operating language and make the exceptions visible: unallocated work, rejected records, overdue actions, incomplete responses and changes awaiting review. The objective is not to remove conversation between partners. It is to stop the operation depending on that conversation being remembered and manually translated back into several systems.

Measure the customer outcome, not just partner throughput

Partner performance is usually measured in volume and turnaround time. Those numbers matter, but they are not the outcome. A fast hand-off can still be a poor one if the information is incomplete. A case can close within target while the customer receives conflicting letters from two organisations. A partner can clear its queue by rejecting work that then sits unresolved elsewhere. That may satisfy a local measure, but it is useless to the customer.

Alongside throughput, I want the measures that expose friction across the chain: how often work is returned, how many items need manual reconciliation, whether customers are repeating information, whether promised actions were completed, how long exceptions sit unowned and whether different customer groups experience different results. That changes the conversation with partners. Instead of asking only Did you meet the target, both organisations can ask what happened to the customer, where the journey weakened and what they should change together. Shared evidence is a much healthier basis for a partnership than periodic blame.

A partner portal should be an operating system, not a file drop

This thinking sits behind Partner Connect at Better Outcomz. We designed it as a secure, UK-hosted workspace where debt-advice providers and creditor organisations can allocate work, manage shared queues, exchange bulk data, govern user access and keep a complete audit history. The point was never to digitise the existing file-transfer routine. It was to make the state, ownership and history of partner work visible to the people responsible for it. That distinction matters.

A portal that only uploads and downloads files may be more secure than email, but the operation has barely improved. The value comes from connecting the transfer to allocation, notification, access control, exception handling and completion. Partner Connect also sits within a wider view of customer outcomes. Better Outcomes examines evidence across customer interactions. InsolVatrack brings structure to casework. Partner Connect preserves control when the next action sits outside your own organisation. The products do different jobs, but the principle is the same: the customer journey should remain understandable and accountable throughout.

My test for partner technology: If a customer asked, "What happened after you passed my case to your partner?", could both organisations give the same answer from the same evidence? If the honest response starts with checking a mailbox, hunting for the latest spreadsheet or asking who normally deals with that partner, the process is still relying on people to compensate for missing control. The customer journey does not stop at the hand-off. The technology, accountability and evidence should not stop there either.