Behavioral State Model Example: A Worked Diagnosis

A company introduces a reporting tool. Account managers receive training, managers send reminders, and the operations team publishes a dashboard showing who has completed each report. Three weeks later, only 18 percent of client meetings have a report.

The obvious diagnosis is an ability problem: people must not understand the tool. So the company schedules more training.

That diagnosis is possible. It is also a guess.

This worked example shows how to use the Behavioral State Model to turn a vague adoption problem into a set of testable explanations. The case is entirely hypothetical. Its people, observations, percentages, and results are invented for teaching; they do not describe a client engagement or scientific study.

Step 1: Define the target behavior

“Use the reporting tool” can mean almost anything. A person who opens the homepage once has used it. So has a person who completes every report a week late. Neither action may produce the outcome the company wants.

The team rewrites the target:

Within 30 minutes after each client meeting, the account manager opens the account record and enters the meeting outcome, one current risk, and the next agreed action.

Now the behavior has an actor, an occasion, a deadline, and observable steps. The team can distinguish failure to begin, failure to complete, and late completion. It can also ask whether this is the best behavior for the outcome. Perhaps a transcript, a two-field update inside the existing customer system, or a shared note during the meeting would capture the same information with less recurring effort.

That is the first protection against wasted intervention work: compare possible behaviors before optimizing one. Behavior Matching covers that selection problem. For this example, assume the team has reason to keep the target long enough to diagnose it.

Step 2: Gather evidence across all eight components

The team watches account managers attempt the task, interviews people who complete and skip it, reviews login and completion data, and examines how managers use the reports. It records what it knows and what remains uncertain.

BSM component	Hypothetical evidence	Current interpretation
Personality	Most account managers complete similar records in the customer system. Completion does not cluster clearly around any measured recurring tendency.	No strong evidence of a broad personality mismatch.
Perception	Several managers believe risk notes will be used in performance reviews. Leaders intended the notes for account planning but never explained access or use.	Expected surveillance may make honest reporting unattractive.
Emotions	People describe entering a risk after a difficult client call as “admitting failure.” The reaction is strongest before weekly account reviews.	Shame or anxiety may inhibit completion, especially when evaluation is near.
Abilities	During observation, users complete the form accurately without help. Error rates are low. The extra training covers steps they can already perform.	Ability is unlikely to be the main constraint.
Social Status/Situation	Junior account managers believe that recording a risk will make them look unable to control the client. Senior managers report risks more often.	The behavior may carry a status cost that differs by role.
Motivations	The report helps leaders plan staffing, but account managers see no immediate benefit. Their urgent post-meeting task is usually a client follow-up.	A competing goal has an immediate payoff; reporting has a delayed benefit for someone else.
Social Environment	Leaders ask for reports but rarely discuss their contents. The fastest-closing managers receive public praise even when their reports are missing.	Observed priorities conflict with the stated rule.
Physical Environment	The tool requires a separate login, performs poorly on phones, and cannot be opened from the client record. A complete report takes about seven minutes.	The workflow adds friction at the moment when people are switching to urgent follow-up work.

Notice what the table does not say. It does not prove that status, emotion, motivation, or the physical workflow caused the missing reports. It makes the team’s current evidence and uncertainty visible. That is enough to rule out reflexive training as the first response.

Step 3: Build competing explanations

The team writes four candidate explanations:

Workflow friction: A separate, mobile-unfriendly tool makes the action too costly at the required time.
Perceived evaluation: People expect an honest risk note to count against them.
Visible norms: Leaders’ behavior and rewards show that speed matters more than complete reporting.
Competing motivation: Immediate client follow-up beats a delayed organizational benefit.

These explanations can interact. If the form took 20 seconds, the delayed benefit might be enough. If leaders routinely used risk notes to provide help, the same entry might feel less threatening. If the behavior had no status cost, managers might tolerate more friction.

The interaction is a reason to think carefully, not a reason to test everything at once.

Step 4: Design an informative first test

The team wants to learn whether workflow friction explains a meaningful share of the gap. It places a short version of the report inside the existing customer record. The new version keeps the three required fields but removes the separate login and works on mobile.

For a defined trial period, comparable teams use the old and integrated workflows. The company measures:

the share of eligible meetings followed by a complete report;
time from meeting end to submission;
time spent completing the report;
accuracy and usefulness of the entries;
reported difficulty and expected consequences;
whether effects differ by role or meeting type.

Completion alone is not enough. If the integrated form produces more entries but strips out the detail leaders need, it may improve the proxy and harm the outcome. If reported difficulty falls while completion does not move, workflow friction was real but not sufficient.

Step 5: Interpret the result without inventing a story

Suppose completion rises from 18 percent under the old workflow to 43 percent under the integrated workflow during the trial. This hypothetical difference supports the claim that the workflow matters under those conditions. It does not prove that the physical environment was the only cause, that the effect will persist, or that every account manager responded for the same reason.

The remaining 57 percent is not “resistance.” It is unexplained behavior.

Follow-up interviews show that junior managers still avoid recording risks before the weekly account review. The effect is smaller for risk notes than for meeting outcomes and next actions. That pattern strengthens the status-and-evaluation explanation.

The team’s second test changes who can see a draft risk note and makes the support process explicit. It measures both expected evaluation and reporting. Again, the point is not to make a score rise. The point is to learn whether the proposed constraint changed and whether behavior changed with it.

Step 6: Know when to change the behavior

After two trials, reporting improves but remains late and costly. Account managers already write a short client email after most meetings. The team tests extracting the outcome and next action from that existing behavior, then asks for a separate risk note only when needed.

This alternative may fit the workflow better than a universal after-meeting form. If it captures useful information with lower burden and no new errors, the right move is to replace the target behavior instead of polishing the original because the company has already paid for the tool.

The Behavioral State Model helps diagnose a selected behavior. It should never trap you inside that selection.

What this example teaches

Define the behavior before explaining it. A vague target produces vague causes and meaningless measurement.
Inspect every component once. The first pass protects against solving the most familiar problem instead of the observed one.
Separate evidence from interpretation. “Users completed the form during observation” is evidence. “Ability is not the main constraint” is a current judgment.
Treat a weak component as a hypothesis. A low rating is not a causal result or behavior probability.
Measure the proposed mechanism and the behavior. Otherwise a successful test can still leave you with an unsupported explanation.
Return to behavior selection. When a target remains a poor fit, choose a different path to the outcome.

For the component definitions, model history, relationship map, and evidence limits, read the full Behavioral State Model guide. For a broader comparison, see 16 behavior change models compared.