Measure co-browsing success by following a defined group of customer journeys from the obstacle that prompted help to the bank-recorded outcome that proves the intended task is complete. Compare equivalent customers offered assistance and usual support, then measure subsequent unresolved contact over a consistent follow-up window.
The important distinction is between the obstacle assistance can address and the banking outcomes that follow. An advisor may help a customer past a funding-details error, but clearing that page, submitting an application and opening an account are separate events. A completed co-browsing session proves none of them.
Keeping those stages connected gives service, digital and analytics teams a useful investment test: did offering assistance improve the intended outcome, how much support did it require and which remaining obstacle should the bank fix?
Choose the finish line before counting assisted journeys
Start with one task and one obstacle. For this worked measurement design, use customers applying for a savings account who request help because a validation message on the funding-details page leaves them unsure which field needs correction.
Write the specification before the first assistance offer:
| Decision | Worked example |
| Intended task | Submit a savings-account application |
| Eligible population | Application journeys whose first qualifying help request for the specified funding-page problem occurs during enrollment, on supported pages and devices through a permitted assistance route |
| Cohort entry | First recorded qualifying help request for that problem, before an assistance offer |
| Unit counted | One application journey, regardless of retries, contacts or co-browsing sessions |
| Success event | The bank’s application system records receipt of an accepted submission |
| Completion window, W | An agreed period from cohort entry, based on observed customer behavior and processing needs |
| Repeat-contact window, R | An agreed period after the index support interaction ends, covering likely unresolved demand |
The index support interaction is the interaction containing the first qualifying help request, whether or not co-browsing connects. Set eligibility using information available before the offer. Defining the cohort as customers who successfully connected would remove failed delivery from the evaluation.
Keep the states separate. Moving beyond the funding page shows progress. Bank-recorded receipt shows submission. Pending checks, account opening and initial funding are later states with different meanings.
If the business objective is an opened account, retain opening as the primary endpoint and use submission as an intermediate measure. Follow the same cohort through a window long enough to capture the relevant processing. If initial funding belongs to the objective, define the bank event and funding threshold that count. Entering funding details is not proof that money arrived.
This issue cohort differs from the whole application funnel. Whole-funnel completion uses eligible application starts as its denominator and measures completion from application start. It can show overall journey performance, but it cannot replace measurement of customers who encountered the obstacle. Establish the issue-cohort baseline using the same entry rules and outcome windows as the pilot.
Track what assistance actually changes
Use the validation error to test a specific explanation for improvement. The customer knows the funding page will not proceed but cannot tell which field needs attention. The advisor first establishes the intended task, the error and the permitted support route.
During an appropriately permitted shared-page interaction, the advisor may be able to identify the field associated with the message and explain the required correction. The customer supplies or corrects their own information. The useful change is from broad troubleshooting to a specific next action, within the bank’s approved support scope and sensitive-data controls.
Record the blocked step, coded reason for help and subsequent progression beyond that step. Those events let the team test whether assistance addressed the obstacle it was offered to resolve. If the customer can now continue and submit independently, end the assistance there.
A pending bank review needs a different response. An advisor can explain the status and what happens next, but viewing the status cannot accelerate the bank’s decision. Keeping that distinction in the measurement design prevents downstream processing delays from being treated as failed form assistance.
Build a scorecard around journeys, not sessions
Use unique journeys for customer outcomes and attempts or sessions for delivery diagnostics. For every windowed rate, include only journeys with the full observation window available at the reporting cutoff. Show newer journeys separately as immature rather than treating them as failures.
| Measure | Calculation and clock | What it tells you |
| Issue-cohort task completion | Eligible journeys reaching the chosen success event within W of cohort entry ÷ all eligible journeys with full W observation × 100 | Whether the affected population finished the task |
| Connected-assisted completion | Connected-assisted journeys reaching that same event within W of cohort entry ÷ all connected-assisted journeys with full W observation × 100 | Outcomes among customers who received assistance, not its causal effect |
| Blocked-step progression | Eligible journeys progressing beyond the blocked step within a declared period P from cohort entry ÷ all eligible journeys with full P observation × 100 | Whether the immediate obstacle was cleared |
| Unresolved same-task repeat contact | Eligible journeys with at least one subsequent unplanned inbound contact about the unresolved task within R after the index support interaction ends ÷ all eligible journeys with full R follow-up × 100 | How much unresolved demand remained after initial support |
| Time to task completion | Elapsed time from cohort entry to the success event for journeys completing within W, reported as a median and a specified upper percentile | How long successful journeys took |
| Total support effort | Advisor handling and after-contact work minutes across task-linked contacts within a declared period F from cohort entry ÷ all eligible journeys with full F observation | Whether assistance reduced or increased overall support work |
Set P, W, R and F before enrollment and use the same definitions in both pilot groups. These clocks answer different questions: completion starts at cohort entry, while repeat contact starts after the initial support interaction ends. Do not reset the completion clock when co-browsing connects.
Break out blocked-step progression for the connected-assisted subset as a diagnostic, using the same period P. Report time to completion beside the completion, unresolved and unknown shares. Fast completions alone can conceal a large group still waiting.
For repeat contact, count only subsequent unplanned inbound demand about the unresolved original task. Report planned callbacks, requested document follow-up and new tasks separately. A customer calling because they cannot tell whether an application arrived is different from a scheduled call to supply missing evidence.
Add one consistently worded customer-effort or satisfaction question at the same follow-up point in each group. Report the response distribution, respondent count and response rate, defined as responses divided by invitations multiplied by 100. This provides a customer perspective alongside the banking records without treating survey respondents as the whole cohort.
Retain later ineligibility, customer withdrawal and pending processing in the original eligible denominator. Show them as separate statuses so operators can understand the result. Distinguish a customer’s decision not to proceed from inactivity with no known reason. Missing linkage remains an unknown outcome.
Give analytics a linkage brief they can implement
Follow the same application across digital activity, assistance and bank processing through a bank-approved journey identifier. The bank’s authorized records establish receipt, opening and funding; session logs describe the assistance interaction.
Ask analytics to connect these records:
- Original application start, first qualifying help request, blocked step and coded reason for help
- Assistance eligibility, offer, assigned pilot group, acceptance or decline
- Connection attempts, failures, successful connections and session endings
- Index support interaction start and end
- Progression beyond the blocked step
- Backend application receipt, subsequent account statuses and funding events where relevant
- Later task-coded contacts, including whether follow-up was planned and whether the task remained unresolved
Keep application start and cohort entry as separate timestamps. They answer different questions. Preserve session and attempt identifiers beneath the journey identifier so several attempts or advisor sessions do not become several customer tasks. Link through authorized identifiers rather than account details copied from the shared page.
Normalize timestamps, specify event ordering rules and allow for reporting latency before closing a reporting period. Banking operations should confirm exactly what each backend event means. A submit-button click or front-end confirmation counts as receipt only if the bank verifies that meaning.
Publish linkage coverage alongside the scorecard: journeys successfully linked to the outcome source divided by all journeys requiring that linkage, multiplied by 100. Report source outages, delayed records and missing statuses separately. Reconcile unmatched records and compare coverage between pilot groups before interpreting a difference in completion.
An unmatched journey remains in its eligible denominator with an unknown outcome until reconciled. Its absence from an outcome extract is not sufficient evidence of failure. Missing index-interaction end times also need reconciliation before the repeat-contact window can be calculated reliably.
Measure delivery without collecting the customer’s banking details
The scorecard needs event metadata, not credentials, account numbers, field contents or routine full-session recordings. A coded validation reason and progression timestamp can establish recovery without storing the customer’s entry.
Before enrolling customers, confirm consent, permitted pages, masking behavior, role-based advisor access and retention for the actual deployment. Test those controls on the relevant journey. Provide accessible alternative support and record when a customer chooses it or cannot use the proposed route.
Keep delivery guardrails explicit:
- Connection-failure rate: failed connection attempts ÷ all connection attempts × 100. Define when an attempt is considered failed and retain retries as separate attempts.
- Consent-withdrawal rate: connected sessions ended following consent withdrawal ÷ all connected sessions × 100.
- Material privacy incidents: count and severity, with the affected sessions and customers identified through authorized incident records. If reporting a rate, state the exposure denominator explicitly.
Review these alongside outcomes. A completion improvement does not excuse unacceptable exposure or an assistance route that leaves a material customer group unable to get help.
Test the offer against a fair comparison
Raw assisted-versus-unassisted conversion is a weak investment test. Customers receiving help may have harder problems. Customers accepting help may also differ in motivation, available time or confidence.
Where operationally appropriate, randomly assign the assistance offer among journeys meeting the same pre-established eligibility rules. Preserve access to necessary support in both groups and document what usual support includes.
Analyze every journey in its assigned group, including declined offers and failed connections. The primary comparison is the effect of offering the assistance route under real operating conditions. Acceptance and connected-assisted outcomes then explain how well that route was delivered.
Calculate the completion difference as the offer group’s task completion rate minus the comparison group’s rate, in percentage points. Report group counts, completed-task counts and an uncertainty interval. Use identical success events, clocks and maturity rules in both groups. Choose pilot duration and sample size around the bank’s baseline, meaningful decision threshold and outcome timing rather than a universal target.
If randomization is unavailable, compare journeys matched on task, blocked step, device, case complexity and relevant customer circumstances. Account for advisor or team differences where possible. Describe remaining imbalance and present the result as an association rather than proof that co-browsing caused the difference.
A historical before-and-after comparison also needs a record of changes to the form, traffic and bank processing. Those changes can affect outcomes independently of assistance. A high connected-assisted completion rate can help explain delivery, but it cannot replace a comparable offer-level test.
Use the result to assign the next fix
Agree decision criteria before reading the pilot result. Use the bank’s baseline, delivery costs and risk tolerances to define a worthwhile improvement and acceptable guardrails.
Review data quality first, then task outcomes, unresolved demand and material differences by step or customer circumstance. Assign the action to the team that can change the cause:
| Result pattern | Next operational action |
| Advisors repeatedly help customers recover from the same field error | Digital journey owner improves the validation message or form behavior, then retests demand for assistance |
| Customers accept help but connections frequently fail | Technical owner investigates connection delivery by device, browser and supported page |
| Progression improves but submission does not | Journey owner examines the next obstacle or submission failure |
| Submission is strong but account opening remains weak | Banking operations examines pending checks, eligibility outcomes and processing delays |
| Calls take longer but unresolved repeats fall | Service operations compares total support effort per eligible journey over the same F window |
| Completion or access differs materially by customer circumstance | Service and accessibility owners investigate whether the route meets those customers’ needs |
Expand assistance when the comparable pilot shows a worthwhile outcome improvement and delivery meets the agreed guardrails. Improve its delivery when failed connections or access barriers limit a promising route. Fix the underlying journey when assistance repeatedly compensates for the same avoidable problem.
For an investment decision, compare costs over a consistent boundary: advisor time, repeat-contact work and relevant technology and operating costs. With a credible comparison, incremental cost per additional completed task is the difference in cost per eligible journey divided by the difference in completion rates expressed as proportions. If there is no positive completion difference, that ratio does not establish a cost per additional completion. Avoid assigning account revenue to every application submission.
The strongest result may be that assistance works and the form should still change. Repeated recovery of the same error identifies an opportunity to remove the need for help. A successful measurement program gives the remaining obstacle to the team that can remove it, even when that means fewer future co-browsing sessions.
