A launch is a milestone. Adoption needs its own evidence.
Start with the checkpoint that needs attention: is the partner live, can workers find the option, and what happens when eligible workers try it?
Keep launch progress, benefit availability and worker use separate. Where the embedded model requires no employer activation, availability is a coverage check—not another employer conversion stage. The Clair embedded On-Demand Pay model is one reference for this distinction; confirm how availability and eligibility work in your own integration.
| Signal | Working definition | Read it alongside |
|---|---|---|
| Launch progress | Actual or expected go-live versus the agreed launch date. | Current milestone, dependencies and the source of any revised date. |
| Worker reach | Unique workers shown the option ÷ workers with platform access where the benefit is available. | Employer access count and scope; the product surfaces included in the observation. |
| First advances | Unique exposed workers taking a first advance ÷ unique exposed workers. | Eligibility and application outcomes for the same cohort and observation window. |
Match the denominator before interpreting the result. Use the same partner, cohort and observation window. If a denominator is zero, unavailable or defined differently, record the rate as unavailable rather than treating it as zero.
A low rate alone does not establish the cause, a broken implementation or renewal risk. Check whether timing, infrequent use, differing worker roles, incomplete reporting or a small sample makes the comparison misleading. Use an agreed launch plan or a genuinely comparable cohort; this playbook supplies no universal threshold.
Turn a signal into an owned next step.
Keep the partner context in HubSpot, bring in approved aggregate evidence and use the review to agree one bounded action. The sequence below is the complete workflow; the selector that follows is a shortcut through its decision points.
- Start with the partner record.Record the named partner owner, target and actual go-live dates, rollout status and the next review date on the company or agreed Partner record.
- Attach a comparable snapshot.Include employer access count and scope, worker reach and first advances. Record the cohort, observation period, source timestamp and evidence link. Use approved aggregates; keep individual worker identity and financial activity in the originating systems.
- Choose the review question.Check freshness and comparability first. Then compare launch with the plan, or reach and first use with the agreed baseline. Select the question in the decision table below; verify the possible explanation before choosing a fix.
- Create an owned task.Capture the issue, named owner, next action, due date, next review date and evidence link. HubSpot supports creating and assigning tasks; the record design and automation depend on your setup.
- Refresh, then close or revise.At the next review, refresh the snapshot using the same definitions. Close the task when the agreed action is complete, or record the revised action, owner and dates. Task completion alone is not evidence that adoption improved.
Every path through the review
| Observed signal | Question & evidence check | Owner & next action |
|---|---|---|
| Launch behind plan | What is preventing the next milestone? Check the agreed launch date, current milestone and documented blocker. | Implementation owner. Confirm the blocker and agree a revised milestone; record its owner and due date. |
| Reach below baseline | Can workers find the option in the product? Check access scope, exposure counts and the discovery path against a comparable cohort. | Partner lead. Check in-product visibility and the discovery path; agree the specific check or change to review. |
| First use below baseline | What do eligibility and application outcomes show? Check matched exposure and first-advance counts, eligibility and application outcomes. | Product / analytics owner. Inspect those outcomes before proposing a fix; distinguish access or eligibility constraints from a usage hypothesis. |
| Missing or stale data | Is this snapshot current and comparable? Check source timestamp, observation period, cohort and definitions. | Owner agreed with your team. Reconcile the data before choosing a rollout action. Set a date for a refreshed snapshot. |
What is preventing the next milestone?
- Illustrative owner
- Implementation owner
- Next action
- Confirm the blocker and agree a revised milestone.
- Evidence to bring
- The agreed launch date, current milestone and documented blocker.
An illustration, not an assessment of your partner. All four paths appear in the table above.
A prompt for your review
Which checkpoint needs attention, what does the matched evidence show, and who owns the next action before our next review?
What belongs in the partner review?
A useful review should be repeatable by someone who was not in the previous meeting. Keep the minimum context needed to understand the signal and follow the decision.
- Partner context: partner identifier, named owner, agreed launch date, actual or expected go-live, rollout status and employer access scope.
- Comparable evidence: counts behind each rate, cohort definition, observation window, source timestamp and approved aggregate report or source link.
- Interpretation: the observed signal, baseline used, relevant eligibility or application outcomes, and any reporting or sampling caveat. Separate a confirmed blocker from a working hypothesis.
- Decision: one bounded action, one accountable person, a due date and the evidence that the team will bring to the next review.
When the evidence is missing, the next action is to reconcile it. An automated alert is a reason to investigate; it should not silently convert an unknown into an adoption problem.
Start with one partner and one review cycle.
Agree the definitions, choose the source of each aggregate and name the people responsible for the review. Run the loop with one live partner before expanding it. Add automation only where data access and the HubSpot edition support the intended workflow.
Leave the review with an observation, supporting evidence, a named owner and the next review date. Check the outcome of the action when you meet again.
Sources & scope
This illustrative SpecSavi framework uses public product information. Adapt the review criteria and owners to your partner model.
- Clair: embedded On-Demand Pay — public reference for the embedded model. Confirm availability and eligibility for the actual integration and population.
- HubSpot: create tasks — product documentation for recording and assigning follow-up work. Check account permissions and edition before designing automation.
- SpecSavi: CRM & Revenue Systems — the scope of SpecSavi's implementation support.