Skip to main content

Business Journey Mapping

Layer: business observability (the why)

Product and business operations own this layer. Platform teams support emission and storage; they do not define what "success" means for a regulated journey.

Outcome

For each critical journey, you can answer:

  • Is the customer completing the workflow?
  • Is revenue or obligation impact visible in near real time?
  • Which step drives drop-off when outcomes degrade?

Steps

1. Name the journeys

Pick journeys that matter for revenue, risk, or regulation (not every screen).

JourneyBusiness ownerExample outcome
Retail checkoutProduct / paymentsPayment success rate
Claims intakeOperationsFirst-touch resolution rate
KYC onboardingCompliance / productVerification completion

2. Define business KPIs per journey

KPI typeExampleAvoid
Success rate% payments completedRaw page views without outcome
ConversionApplication → approvalInfra CPU as proxy for business health
Drop-offAbandon at step 3 of 5Vanity metrics with no service mapping

3. Emit business events

Business events are first-class signals, not spreadsheet exports.

FieldPurpose
journey_idStable workflow identifier
stepNamed stage in the journey
outcomesuccess / failure / abandon
correlation_idJoin to service traces (required)
principalCustomer or case identity (policy-compliant)

4. Set business-facing SLOs

SLOExample targetConsumer
Payment success99.5% / 24hProduct + SRE
Claims submission completion95% / 7dOperations
Onboarding completion90% / 30dCompliance

5. Map KPI → service entry points

Document which API or event starts the journey slice you measure. Correlation playbook wires the rest.

Business KPIService entry
Payment successPOST /checkout/pay
Claims intakePOST /claims/submit

Release gate

  • Each priority journey has a named business owner
  • KPIs are outcome-based, not activity-based
  • Business events include correlation_id
  • Business SLOs are documented and alertable
  • KPI → service entry mapping exists for correlation