The website plan has been approved, the customer relationship management (CRM) implementation is under way and the portal supplier has its own release date. Finance is discussing payments separately. Each workstream can explain its scope and report progress, but nobody can yet show one member renewing from the first website visit through authentication, payment, updated membership status, finance reconciliation and a supportable record.
That gap matters because the organisation may be managing four successful technology projects while creating one unreliable service.
Systems, departments, budgets and suppliers are legitimate management boundaries. They are not user journeys. A member, candidate, employer or member of staff crosses them without knowing they exist.
The service fails at the hand-offs
A public website can send a person to the correct portal page. The portal can submit a renewal. The CRM can update a record. A payment provider can authorise a transaction. Every component has behaved as designed.
The service still fails if the person is matched to a duplicate record, the CRM does not receive the final payment status, finance cannot reconcile the money or support cannot tell what happened.
No single component must be defective. The failure sits between products, contracts or teams.
Those hand-offs are where assumptions gather. The website expects the portal to preserve the intended action after sign-in. The portal trusts the CRM’s identity and eligibility, while the CRM waits for one ordered payment result. Finance expects a usable reference and support assumes that one supplier will be able to explain the transaction.
In delivery reviews, each assumption is often reasonable. The problem is that reasonable local assumptions have not been combined into one explicit operating design.
A boundary is where local completion becomes organisational risk.
The Journey Spine
We use a simple exercise called the Journey Spine. Start with the outcome a person is trying to achieve, then follow it to the final organisational result. For a renewal, it might look like this:
For each stage and hand-off, record:
| Journey question | What to make explicit |
|---|---|
| User outcome | What the person believes they have completed |
| Business state | What must now be true in membership, qualification, finance or another operation |
| Information | The data that moves and the authoritative source |
| Decision | The rule being applied and who owns it |
| Exception | What happens when the expected path does not complete |
| Responsibility | The internal owner and supplier contribution |
| Evidence | How the end-to-end result will be demonstrated and accepted |
The Journey Spine gives separate workstreams a common frame without requiring one supplier, one platform or one enormous project plan.
Use a small number of journeys that determine organisational success. For a membership organisation they might be joining, renewing, booking, paying and updating details. For a qualifications organisation they might include applying, submitting evidence, receiving a result and appearing on a public register.
Do not begin by mapping every screen. Begin with business state. “The form submitted” is a system event. “The eligible candidate has a complete application that staff can assess and finance can reconcile” is an outcome.
The first journey map in a programme can end at “confirmation sent”, several steps before finance, support or the authoritative record can confirm the outcome.
Settle identity and data ownership early
Identity is often treated as a portal concern until testing reveals that the same person exists differently across the website, CRM, learning service and payment records.
The journey needs clear answers to practical questions:
- How is a new person distinguished from an existing one?
- Which identifiers are shared between services?
- Which system owns contact details, membership status and organisational relationships?
- What happens when two records appear to match?
- How are changes made in one service reflected elsewhere?
- Who can merge or correct information, with what audit trail?
These are not merely integration fields. They affect access, price, eligibility, communications and the ability of staff to support somebody.
An experienced project team will test a clean new user early because it is easy to prepare. The more revealing scenarios involve an existing member with an old email address, overlapping organisational relationships or an interrupted transaction. Those are normal conditions in a long-running service.
Data ownership should therefore be expressed as an operating decision, not only a technical source-of-truth label. The authoritative system must have a capable owner, a correction process and a way to distribute changes safely.
The Journey Spine makes cross-service decisions visible through one journey. The Client Architecture Function gives those decisions an authorised client owner across the outsourced estate.
Follow payments beyond the success screen
A payment confirmation page does not prove that money, status and finance records agree. Follow the amount and reference from creation through authorisation, failure or abandonment; then trace the notifications returned to the portal and CRM, the resulting invoice, receipt and membership status, finance settlement and reconciliation, any refund or duplicate handling and the record available to support staff.
Test partial completion. A member may pay successfully while the portal loses its connection before showing confirmation. A payment provider may retry a notification. A staff member may correct status manually while finance still holds the original reference.
Many organisations discover their first reconciliation problem after go-live, when finance closes the month rather than during system testing. The technology appears complete while the organisation still cannot close the transaction.
Payments expose the broader point: operational completion usually occurs later than the user-facing success message.
Design exceptions and support as part of the journey
Happy paths make good demonstrations. Exceptions reveal whether the service has an owner.
Map the few failure modes that are material or common enough to affect launch:
- identity cannot be matched;
- eligibility or price is disputed;
- a payment partly completes;
- an integration message is delayed or duplicated;
- a communication is not sent;
- staff must override a rule; or
- the user returns after abandoning the journey.
For each one, decide what the user sees, what staff can see, which team leads the response and how the service returns to a consistent state.
In support workshops, the hardest incident to assign is the one where the user has clear evidence of failure but every supplier can show that its own component completed.
“Raise it with the other supplier” is not an operating model. At the start of an incident, the source may be unknown. The organisation needs one route for the user, a client owner for cross-system diagnosis and agreed supplier participation.
Support design also improves delivery. If staff cannot trace the transaction state in a controlled test, they will not be able to do so when a real person is waiting.
Govern one service across separate plans
A joined-up programme does not require every detail to reach one committee. It requires important cross-service decisions and dependencies to be visible in one place.
The sponsor should be able to see the priority Journey Spines and the evidence behind them, the decisions and dependencies crossing workstreams and any hand-off without an owner. That view should continue through end-to-end testing, operational preparation and support to one complete-service release recommendation.
Each supplier can still manage its own plan. Contracts should make integration work, test support, defect collaboration and release coordination explicit. The organisation should maintain the whole-service view.
Cross-workstream meetings can expose shared dependencies and then return each one to a separate plan, so the common date moves without appearing as a change in any single workstream.
When choosing a CRM, the five supplier questions help expose whether these cross-system responsibilities are demonstrated, included, dependent on discovery or left to the client.
Test and release the complete journey
Component tests remain necessary. They show that individual products and connections behave as intended. They do not show that the operating service works.
End-to-end evidence needs representative users, data, permissions, rules, emails, payments, integrations and staff handling. It should continue past the user’s final click to the business record, reconciliation and support view.
A familiar test report shows green components while the end-to-end row remains blank because no workstream has been asked to own it.
The distinction matters:
- Activity: a supplier configures the renewal workflow.
- Progress: the workflow operates within that product.
- Demonstration: selected components exchange a successful transaction.
- Evidence: representative complete journeys and material exceptions produce the agreed state.
- Operational readiness: people, support, monitoring and business controls can sustain the service.
- Business sign-off: the accountable owner accepts the evidence and remaining risk.
A platform release date is not automatically a service release date. If each workstream can approve itself but nobody can approve the Journey Spine, governance still has a gap.
Map one journey in the next working session
Choose the journey with the greatest operational or income consequence. Bring the business owner, frontline operations, finance where relevant, technology owner and affected suppliers into one 90-minute session.
Draw the Journey Spine from the person’s first action to the final operational outcome. At every hand-off, capture the information, decision, exception, client owner, supplier responsibility and evidence required.
The first hand-off to produce silence in the workshop is more valuable than the ten stages everybody can already explain.
Do not try to solve every gap in the room. Classify it, name the person who must decide and give it a latest safe date.
The result is not just a journey map. It is a shared definition of the service the separate projects must collectively deliver.