Staff & Member Enablement Guides

Rolling a product out across hundreds of locations means the actual moment of adoption happens at a front desk, between a staff member and a customer, in under two minutes. These guides existed so that moment had a script.

Setup paths differed depending on which billing system a location used and whether a member was being migrated from an older platform. Staff were being asked to explain a flow they had never seen, to customers who were already slightly annoyed. Support volume during rollout weeks was largely made up of questions the front desk could have answered if anyone had shown them how.

• One screen, one step, one instruction. Anything denser will not be read while a customer waits.
• Write separate versions for genuinely different paths instead of one document with conditional branches. Branching guides get read wrong under pressure.
• Show the actual interface state at each step, redrawn, so recognition does the work instead of description.
• End on success. The last screen should show what done looks like, which prevents the most common support question: did that work.
• Anticipate the migration case explicitly. A returning member with an existing account fails differently from a new one.

1. 01

   Path-specific setup guides

   Separate five-step walkthroughs for each account creation path, so a staff member followed one linear document rather than deciding which branch applied.

2. 02

   A platform migration guide

   A verification walkthrough for members moving from a previous billing system, covering the credential step that generated most of the confusion.

3. 03

   A consistent visual grammar

   Numbered steps, one annotated screen per step, and a closing success state. Once staff had seen one guide they could follow any of them.

4. 04

   A troubleshooting boundary

   What the front desk should attempt, and the exact point at which the issue goes to support instead. Removing the guesswork removed most of the escalation noise.

1. 01

   Duplicate rather than branch

   Maintaining several near-identical guides costs more to write and far less to use. Under pressure, people follow a straight line.

2. 02

   Design for the desk, not the intranet

   Guides were built to be readable on a phone at arm's length, which drove nearly every layout decision.

• Gave rollout teams a consistent, reusable enablement pattern across very different locations and systems.
• Reduced the class of support contacts that were really training gaps.
• Became the model I use for internal SOPs: linear, visual, and ending in a definition of done.

Enablement work never appears in a results deck, which is exactly why it gets cut. The guides that worked were the ones written after watching someone fail at the task, not the ones written from the spec. If I could change one thing, I would have measured completion at the desk rather than assuming distribution meant delivery.

• Enablement & Training
  Product & Dashboard Training →

  A structured walkthrough of a product's full feature set, organized the way a user encounters it rather than the way it was built.

• Enterprise Customer Success
  User Acceptance Testing Program →

  Instructions and expectation-setting that let non-technical client stakeholders test a pre-release build without breaking anything or misreading what they found.