How it works
Investigate a workflow from your description, or measure SaaS onboarding from recorded activity. These are different products with different inputs.
The 5-Step Intake Process
The detailed intake typically takes 20–40 minutes. It asks about workflow identity, boundaries, participants and systems, friction and evidence, and constraints.
The Diagnostic Report
The AI-assisted report covers possible failure points, alternative explanations, evidence limitations and a practical experiment. Your team validates the findings. The general Process Autopsy is $19 once; the recurring general Handoff Diagnostic is $149/month. The dedicated SaaS Customer Onboarding Audit is a separate $199 one-time product. None automatically includes a SaaS evidence-monitoring workspace.
General diagnostic example · SaaS audit example · Workspace walkthrough and roles · General diagnostic pricing
Measure SaaS customer onboarding from recorded activity
Workflow Inspector's SaaS customer onboarding evidence workspaces turn activity records into measurements of handoff delays, work without a clear owner, repeated work, and the time it takes to finish onboarding. See the underlying customer or case timeline, save a starting measurement, and compare a later period after your team changes the process.
Choose the right product: the free screen uses your ratings; the $199 one-time SaaS Customer Onboarding Audit uses a detailed intake to produce a report. The evidence monitor is part of the separate SaaS Onboarding Team ($499/month) and Organization ($1,199/month) workspaces. Buying an audit does not buy a monitoring subscription, and buying a workspace does not include a separate audit. Your team carries out the changes; this is self-service software, not an implementation consultancy.
How to add your activity
Start with a CSV spreadsheet. Open the Onboarding progress monitor in your workspace, then use Upload customer activity to choose the file and press Upload activity. Use the example files to see the required format: a case reference, the step, what happened, and when it happened. Use reference codes rather than customer names, and include only the information needed for the review.
Your administrator can also create a scoped, revocable API credential for your own systems to send activity, or configure a signed GitHub Issues webhook. GitHub collection covers supported issue activity after setup; it is not automatic historical backfill.
Check Connections in your workspace for current Jira Cloud and HubSpot availability. You must give permission before activity can be imported. Salesforce has an additional package-installation step; check Connections for its availability and setup instructions. A connection alone does not confirm that history has been imported. You can also add supported activity files or use the event API and GitHub Issues webhooks.
See a software-generated example with fictional activity · Compare SaaS customer onboarding products · Open your onboarding workspace
Understand your measurements
- Handoff Reliability Index (HRI)
- A proprietary, versioned indicator for reviewing recorded handoffs. It is different from the free questionnaire score. It is not a scientifically validated benchmark, a staff-performance rating, or proof of savings. Insufficient observations stay unscored.
- Waiting between teams
- Review handoff and decision delays, missed service deadlines, and how long onboarding took from the recorded start to completion.
- Missing ownership and repeated work
- Review explicitly recorded ownership gaps, reopened work, handoff problems, process exceptions, and recorded manual actions. A missing record is not proof that no problem occurred.
- Disagreements between systems
- Compare compatible records where the evidence supports a comparison. Unrelated identifiers or missing history are not automatically treated as disagreement.
- Rework-cost estimate
- Available only when the required recorded effort and your labor-cost input exist. This is an estimate of recorded rework, not measured lost revenue or a guarantee of savings.
See whether your changes helped
- Choose the process and observation period. Review the timeline and missing information before relying on a number.
- Save the initial period as your baseline. Saved evidence and measurement snapshots cannot be overwritten.
- Have your team test one change. Upload or collect the next period's activity and save a follow-up.
- Compare similar customers, process definitions, periods, and settings. A change in the measurements does not establish that your intervention caused it.
You can export the applicable evidence and measurements. Workspace roles, department access, and credentials control who can read or add evidence. The proprietary scoring method, weights, thresholds, classification rules, and internal implementation are not published in this guide.
A working example: before and after an onboarding change
Fictional demonstration, not a customer case study. These two files contain three invented onboardings in each period. The numbers below are checked during the website build by the same server-side measurement engine used by the evidence monitor. No customer account, payment, or customer data is used.
In the first file, the receiving team accepts the three handoffs after 6, 10, and 18 hours. In the follow-up file, acceptance happens after 2, 3, and 5 hours. The middle handoff time is shown below. The files also include recorded onboarding starts and completions.
Software output from fictional activity: 3 completed cases in each period| Measurement | Baseline: May 1–5, 2026 | Follow-up: May 8–12, 2026 |
|---|
| Median time waiting for the next team | 10 hours | 3 hours |
|---|
| Median onboarding start-to-finish time | 40 hours | 22 hours |
|---|
Download fictional baseline activity (CSV) · Download fictional follow-up activity (CSV) · Download the example's measurement results (JSON)
To try these files in an active SaaS Onboarding workspace, use a separate demonstration process so fictional activity is never mixed into your real measurements. Upload the baseline file, select May 1–5, and save a baseline. Upload the follow-up file, select May 8–12, and save a follow-up. Review the sample sizes and timelines before comparing. The public example can be read and downloaded without purchasing.
This small, deliberately constructed example demonstrates the software's input-to-output path. It is not evidence of typical results, customer adoption, a validated benchmark, causal improvement, or financial return. The public files contain only fictional inputs and selected measurement outputs, not the HRI formula or internal rules.
How this was created
AI assisted the explanation and fictional fixture preparation. Product claims were checked against the implementation, and the displayed measurements are verified against the server-side engine during the build. The proprietary calculation remains on the server.