# Adoption friction record Follow one case from arrival to a result someone can check, and find where the person doing the work gets stuck. This worksheet provides one completed hypothetical onboarding design and a blank record. No operator trial, customer adoption rate, business benefit, or release approval is claimed. ## Completed hypothetical boundary Rina needs to resolve or hold a region-setting discrepancy in OB-17. That immediate operator job is different from the later customer activation: the customer completing an agreed first task and Leo checking it. The example does not define that customer's task; a real trial must. In this record, exposure means the operator received and opened the case in a place where they could work on it. | Field | Entry | | ------------------------------- | ------------------------------------------------------------------------------------------------------------------- | | Work | Prepare a supported customer-onboarding case for one agreed first task | | Case | OB-17; newly authored hypothetical example | | Initial segment | A permitted account with supported configuration and required sponsor | | Exclusions | Unsupported configurations, missing required sponsor, or no permitted account | | Accepted outcome | Authorized customer completes the agreed first task and Leo independently accepts its evidence | | Earlier events | Account creation, login, prepared checklist, and operator exposure; none establishes accepted first use | | Assumed exposure | Assignment and view evidence are assumed available for this paper case; no event was collected from an actual trial | | First suspected weak transition | Exposed answer to a completed, held, or rejected case with a named next owner | | Current outcome | Not accepted; first use has not occurred | | Existing fallback | Current onboarding checklist and established support route | ## Sketch A: isolated answer ```text Case: OB-17 Answer: Account looks ready. Send the welcome message. Sources: Not shown Case status: Not shown Correction: Send another chat message Next owner: Not shown Support handoff: Copy the conversation elsewhere ``` Candidate frictions: the operator cannot inspect a source revision, record a durable correction, identify the case's current state, or route an unresolved decision to its owner. These are consequences to check in a proposed rehearsal, not observed abandonment results. ## Sketch B: proposed case record ```text Case: OB-17 | Assigned operator: Rina Status: Blocked, configuration review required Prepared result: Draft first-task checklist, revision 2 Evidence: Requirements R-3; permitted configuration C-8 Unresolved item: Region setting differs from R-3 Correction: Edit the draft; retain revision and reason Permitted actions: Hold, reject, ask owner, resume review Configuration decision owner: Priya Service support owner: Sam Completion condition: Customer completes the first task; Leo independently accepts it Current outcome: Not accepted; first use has not occurred ``` This is a textual design, not implemented software. R-3, C-8, OB-17, and the role names are hypothetical labels. Source access still needs current permissions. The model cannot grant entitlement, waive a requirement, or declare activation complete. A held case needs an owner and a safe support path; resumption needs current evidence. Embedding the proposed record in the usual case system is a starting hypothesis. Compare it with a separate review surface if the existing tool cannot preserve source permissions, correction history, or clear state and ownership. Neither sketch proves adoption. ## Proposed working session | Participant | Bring | Proposed contribution | | ------------------------------------------------- | --------------------------------------------------------------------------------- | --------------------------------------------------------------------------- | | Rina, operator | OB-17, the current checklist, and the missing evidence/correction/status friction | Show which actions she needs and which copying the proposal adds or removes | | Leo, workflow owner and proposed outcome verifier | First-task definition and acceptance evidence requirements | Confirm the bounded job, current fallback, and review decision | | Sam, service owner | Proposed case-record change and support route | Own product/integration work through normal review and release | | Priya, configuration owner | Authoritative requirement/configuration revisions and access scope | Decide the source conflict within her authority | These roles do not grant one another policy, access, or release authority. A named owner is not evidence of available review or support capacity; confirm time and backup coverage before a trial. | Response | Hypothetical owner / due date | Evidence destination | Follow-up | | ------------------------------------------------------------------------ | ----------------------------- | ---------------------------------------------------- | ------------------------------------------------------------------------------------------------ | | Confirm authoritative configuration revision and permitted evidence path | Priya / 15 October 2026 | Approved OB-17 evidence register and source decision | Does the proposed record expose current evidence to the permitted operator? | | Draft a bounded held-case surface with correction history and ownership | Sam / 16 October 2026 | Product backlog and change-review record | Can a rehearsal show hold, correction, rejection, escalation, and resumption without lost state? | | Review the source decision and proposed rehearsal | Leo / 19 October 2026 | Workflow review record | Test / narrow / defer; current checklist remains available | All dates above are proposed teaching commitments. The session and trial have not occurred. Meeting attendance, enthusiasm, or a demonstration would not establish adoption or benefit. ## Measures to define before testing - Which cases count as opportunities to use the service, which are excluded, and over what period and timezone? Keep one case ID across repeated attempts. - What saved event shows the operator received the case in a usable place with permitted access? - What records show completed, held, and rejected cases? Do not relabel a held or rejected case as successful first use. - What evidence shows the customer's first task happened, and who independently checks it? Keep that acceptance separate from the operator's case completion. - Correction effort, copying, abandonment, case age, reviewer wait, support demand, and capacity limits. - Later business-effect and full-cost measures, with comparison method and limitations. - Where do the counts come from, which source revisions were used, who checks the measure, and what change would require a new comparison period? No counts or rates are supplied. Absence of an event is a question for inspection, not automatic proof of user resistance or training need. ## Your working copy ### Start with these questions 1. What is the person doing the work trying to finish in this case? 2. Where did they get stuck, and what evidence shows the obstacle? 3. Can they inspect the source, correct the record, and find who takes over? 4. What separate evidence would show the customer's first task was accepted? ### Define the case and follow the transitions - Which workflow is this, and what result can be accepted? - Who owns operation, and who independently verifies the result? - Which cases qualify, and which are excluded? What current manual path and safe fallback remain available? - Which cases and period are included, which source revisions supply the counts, and how are repeats and unfinished cases kept visible? - Which evidence may you access, where may it be stored, and which redaction and retention rules apply? - Which case are you following? Mark each fact as observed, reported, assumed, or unknown. | Transition | Declared source event | Reached / eligible cases | Representative friction and evidence | First weak step or still unknown | | -------------------------------------------- | --------------------- | ------------------------ | ------------------------------------ | -------------------------------- | | Eligible work to exposed in usable surface | | | | | | Exposed to completed, held, or rejected case | | | | | | Completed to independently accepted | | | | | | Accepted to verified business effect | | | | | | Effect to sustained value after full costs | | | | | Do not infer an earlier event from a later one. Preserve inconvenient cases and the earlier metric definition when the segment or event rules change. - Where does the person work today, and which corrections or handoffs must that system support? - Where would they work in the proposal? How would they see source references, current status, owner, permitted actions, uncertainty, and correction history? - Could the existing system support those needs, or is a separate screen necessary? Which constraints remain unresolved? - What is the first transition with evidence of a problem? What contradicts that diagnosis, and what remains unanswered? - Who can fix the observed obstacle: the access owner, case-assignment team, source or policy owner, product team, model team, staffing owner, or trainer? - Who needs to join the working session, and have they or an authorized delegate confirmed time? - For this one case, which obstacle and response will you investigate? - Should the owner preserve, repair, remove, escalate, test, narrow, or defer that part of the process? - Who is accountable, when is the work due, where will the evidence go, and when will it be reviewed? - What rehearsal and later trial are proposed? Will they prevent all external changes or permit only specified controlled changes? - What will you count after the change, out of which cases, using which saved events? Who checks the result, what improvement is required, and what would stop the trial? - Which support, incident, and change routes stay available, and when must the trial stop? A completed record supports a scoped decision. It does not approve a release or establish that users will adopt the design.