The short answer
- Test one complete journey, not six disconnected tools.
- A successful payment is not proof that onboarding worked.
- Fix the confirmed break first; measure commercial outcomes separately.
1. Lead capture → CRM
Use a clearly labelled test record. Submit the actual form and check that the CRM receives the correct contact details, source, campaign and relevant permission fields. Confirm that a repeat submission updates the intended record rather than creating a second sales conversation.
- Does the confirmation match the offer?
- Can the team find the lead and its source?
- Is there an owner when the integration fails?
2. Registration → webinar follow-up
Check that a registrant receives the right joining instructions for the right session. Then test the attended, missed-session and purchased paths separately. A single generic sequence can continue asking someone to buy after they have already paid.
- Correct session, date and timezone
- Attendee and no-show paths checked
- Purchasers exit acquisition follow-up
3. Qualified lead → sales owner
Follow a lead that is ready for a conversation. Check that the assigned person receives the context, can see the previous interactions and knows the next action. Agree a response target the team can actually meet; do not let an automation silently stand in for ownership.
- Named owner and visible next action
- Booking confirmation and rescheduling route
- Unassigned leads visible for review
4. Checkout → payment status
With approved access, use the payment provider’s supported test environment where available. Check successful, failed and repeated events. The CRM should reflect the real payment state without granting access on an abandoned checkout or counting a retried event as a second sale. Do not create a real charge just to test a journey without approval.
- Order and customer identifiers match
- Failed payments do not trigger paid access
- Repeated events do not repeat fulfilment
5. Payment → onboarding and access
A receipt is not onboarding. Check that the buyer receives the promised access, a clear first action and a working support route. If the course platform and payment system are separate, test the connection between them explicitly. Agree how the team handles exceptions such as a paid customer with no access.
- Correct product and access level
- Welcome message and first step delivered
- Visible exception queue and responsible person
6. System event → useful reporting
Reconcile registrations, qualified leads, payments and successful onboarding using consistent identifiers and a defined period. Keep gross processed payments separate from net revenue and profit. Check refunds, duplicates and overlapping payment sources before adding figures together. A technically repaired journey does not establish that the repair caused a later increase in sales.
- One definition for each stage
- Duplicates and source overlap checked
- Outcome and failure counts reviewed together
What this looks like at Cyfer
Blancc’s Cyfer work connected funnels, CRM, follow-up and onboarding for an active education business. The published case study reports £300K+ in gross processed payments and 15K+ webinar registrations. Payment figures were supplied by the client/founder; they are not revenue attributed solely to Blancc. See the case study below for the work and evidence.[1]
Your next step: record one confirmed break
Write down the expected event, what actually happened, the affected system and the responsible owner. Prioritise the break with the clearest customer impact, then scope the repair, test it and leave operating notes. If you need help tracing the journey, Blancc’s Revenue Systems Diagnostic is the starting point.
- This is a practical testing framework, not a guarantee of revenue or an exhaustive platform audit.
- Use approved access and minimise test data. Messaging permissions and provider-specific implementation need their own checks.
Sources and further guidance
Blancc uses primary guidance where factual or regulatory context matters. Recommendations remain general and should be assessed against the specific business, audience, product, and risk.
Read Blancc’s editorial standards and corrections policy for source selection, illustrative labels, update dates, software assistance and corrections.