A trial user tries to save a notification workflow three times, then leaves. Your funnel shows the stall. It does not tell you whether the recipient entry was invalid, the user lacked permission or the service failed.
Those problems need different responses. Clearer instructions may fix one. An administrator must resolve another. A shared view of the page will not repair an outage.
Co-browsing can recover SaaS onboarding drop-off when a customer still wants to finish setup but an advisor cannot understand the browser state well enough to help. Its value is specific: seeing the relevant setting and validation message can turn an uncertain conversation into a useful correction. The goal is a working configuration, not a completed support session.
Measure the setup milestone that matters
Before offering more assistance, decide what progress means. For a notification product, the setup path might be:
- Create a workspace.
- Configure a notification workflow.
- Save the configuration.
- Run a test and receive the expected notification.
Completing a product tour does not establish that any of this works. Even clicking Save may be insufficient if the configuration never persisted.
Define SaaS onboarding drop-off as failure to progress from a specified setup step to the next required milestone within a chosen observation window. A user whose window is still open is not yet a measured drop-off. Someone waiting for an administrator may be delayed rather than lost, though they can still count as non-progressing under your chosen definition.
For each step, calculate:
Step drop-off rate = eligible entrants who did not reach the next milestone within the observation window ÷ all eligible entrants × 100.
Define entry and progression before calculating the rate. Does entering workflow configuration mean opening the page or creating a draft? Does saving mean a click, a successful response or a configuration that can be retrieved afterward? Use evidence that matches the milestone.
Keep the counting unit consistent. In a user-level funnel, the same person must progress. In an account-level funnel, one person may create the workspace while another configures the workflow. Mixing those views can make a completed account look like several failed users.
Choose the window around the actual setup path and observed customer behavior. A task requiring administrator input needs different treatment from a short configuration step. Only evaluate cohorts that have had the full follow-up period, and separate materially different paths or customer types.
Finally, check event coverage. A missing event, an external setup step or an identity mismatch can resemble abandonment. Pair funnel patterns with validation errors, support questions and customer feedback. The funnel locates the stall; those details help explain it.
A failed save is a symptom, not a diagnosis
Start the support conversation with the customer’s intended outcome: “What notification are you trying to send, and to whom?” Then ask what happened when they saved, what message appeared and whether anything changed. Check available service-status information and known faults before asking the customer to repeat the process.
The same report, “It won’t save,” can lead to very different next actions:
| What the evidence shows | Useful next response |
| The recipient entry does not match the required format | Explain the requirement and help the customer correct the entry |
| The user cannot edit recipient settings | Identify the authorized administrator and the permission needed |
| Valid entries fail because of a service fault | Route the fault to the technical owner and set a follow-up expectation |
| The customer lacks a required recipient list or other source information | Explain what to prepare and preserve progress where the product allows |
| Setup requires too much work before anything useful can run | Find the smallest useful configuration and review unnecessary requirements |
| The customer cannot identify a relevant use for the workflow | Establish a meaningful first outcome rather than pushing them through setup |
Use ordinary guidance when it is enough. A precise explanation of a field requirement is less burdensome than starting another support step. Route known permission issues or backend faults to whoever can resolve them rather than extending troubleshooting.
When seeing the recipient setting changes the answer
Co-browsing lets an advisor and customer work from a shared view of a supported web journey.
Consider an illustrative trial user configuring their first notification workflow. They want a notification sent to their own inbox before inviting colleagues. They have reached the recipient-setting step but repeatedly fail to save.
The advisor first confirms that goal, asks about the failed attempts and checks for a known service problem. The customer says they have entered the recipient correctly. Verbal guidance does not establish what is in the field or how the validation message relates to it.
That is the point to offer permission-based co-browsing: “If you’re comfortable sharing this setup page, we can look at the recipient field and its message together. You can make the changes.”
In this example, shared inspection reveals that the customer entered a display name in a field requiring an email address. The useful context is the entry alongside the format requirement. Without it, the advisor was discussing a generic failed save. With it, the advisor can explain the specific mismatch.
The customer replaces the display name with an appropriate test email address and saves the workflow. The interaction then moves back to the SaaS product’s own functions: the customer confirms the saved configuration and initiates a test.
Recovery needs two pieces of evidence:
- The configuration persisted. Reopen the workflow or use available product evidence to confirm the recipient and settings were stored.
- The test produced the expected notification. Check receipt and, where available, the product’s test or delivery status.
A corrected field alone is not enough. If the configuration saves but the test notification does not arrive, setup is not yet verified. Investigate the test result rather than marking the task complete because the validation error disappeared.
Co-browsing supplies shared context. The SaaS product saves the workflow and sends the test notification.
There is no reason to add document review or acceptance to this interaction. The task was to configure and test a workflow. Once that works, the assistance has done its job.
Make the offer selective and keep the customer in control
Repeated validation failures can be a useful invitation signal, but they should not automatically launch a session. The customer may already know the issue or be waiting for someone else. An explicit request for help can be a stronger reason to intervene than an arbitrary error count.
Co-browsing is a good candidate when three conditions hold: the customer wants to finish, the obstacle is on a supported page and seeing that page could change the guidance or next permitted action.
Before making the offer operational, confirm which setup pages can be shared, what interaction is supported and how consent, sensitive-field protection and session ending work in the actual deployment. Do not assume that an external sign-in or integration page behaves like the SaaS setup page.
Explain the sharing scope and how the customer can stop. Keep them in control of changes and use verified controls and procedures to keep credentials and unrelated sensitive information out of view. If sharing is declined or unsupported, continue with text guidance, a description of the validation message or a suitably redacted screenshot through an approved channel.
If inspection reveals a dependency rather than a correctable entry, end the troubleshooting loop. Record what is needed, who owns it and how the customer will resume. “Administrator must enable workflow editing” is an actionable handoff. “Customer still unable to save” leaves the next advisor starting over.
Evaluate recovered setup, not session volume
An accepted offer, a co-browsing session and a closed contact are participation measures. None proves that onboarding recovered.
For a targeted pilot, track:
- Return to the stalled setup step.
- Verified setup recovery within a defined window, using the evidence established above.
- Later activation within a separate window, using a product-specific definition of meaningful use.
- Advisor effort, including preparation, session time and follow-up.
- Repeat contacts about the same setup task during a fixed follow-up period.
For example, a pilot might evaluate setup progression within seven days of eligibility and same-task repeat contacts over the following 14 days. These are illustrative windows, not benchmarks. Choose periods that fit the product and give every evaluated cohort the same opportunity to progress.
Keep setup completion separate from activation and retention. A working initial configuration does not establish that the account subsequently used the workflow for real work or stayed with the product.
Where practical, randomize the offer of assistance among comparable eligible stalled users. Analyze outcomes by the group assigned the offer, including people who decline it. Restricting the analysis to customers who accepted help can reintroduce differences in motivation or difficulty.
If randomization is impractical, use clearly described comparable cohorts. Account for setup path, customer type, blocker severity and signals of intent where available. A raw assisted-versus-self-service comparison can mislead because people seeking help may have harder tasks. Treat nonrandomized differences as associations, not proof that co-browsing caused them.
Read operational measures together. More advisor time may be worthwhile if it produces meaningful additional setup progress. Fewer repeat contacts may reflect successful recovery, but could also reflect customers giving up. Neither result should be interpreted alone.
Turn each rescue into less future assistance
Give advisors a small set of blocker reasons to record, tied to the setup step and observed outcome. Separate misunderstood recipient format from missing permission, service failure and missing information. A general “onboarding issue” category cannot tell the product team what to change.
If customers repeatedly confuse a display name with an email address, improve the field label, example and validation message. Then check whether that specific error and related support demand fall without weakening setup progression. If the real delay is administrator access, improve that handoff instead.
Expand co-browsing where it helps customers reach a verified working configuration at an acceptable operational cost. Narrow it where shared inspection rarely changes the next action. Redesign the setup where the same misunderstanding keeps requiring a person.
The strongest recovery program helps today’s customer finish while making tomorrow’s customer less likely to need the rescue.
