Example — Professional Services Firm, Growth Stage

Firm Profile

• Type: Professional services firm (B2B, recurring client work with monthly deliverables)
• Revenue: Mid-six figures, growing
• Team: ~12 people — founder/owner, operations manager (new hire, ~6 weeks in), 4-5 primary service delivery staff, tool champion, client success coordinator, specialists, senior advisors (escalation only)
• Clients: 55-60 active accounts with monthly service cycles
• Stage: Growth mode — team has doubled in the past year, processes haven't kept up

Beat 1 — What Would Have Been Built at Project Scaffolding

This engagement predated the two-beat model. Change communication was triggered reactively in Week 4. Here's what Beat 1 would have produced if it had existed:

At project scaffolding (Week 1-2):

• Team filter: Yes — 10+ team members affected by Build 1 (core operating SOP) and Build 2 (workflow platform)
• Skeleton communication sequence: Owner announcement → process owner walkthrough → tool rollout → first cycle monitoring → first win acknowledgment
• Ownership mapping: Owner = gold in all communication documents (inverse of SOP where operations manager = gold)
• Affected team: All delivery staff (4-5 people), tool champion, client success coordinator
• Likely resistance patterns from constraint matrix: "Right Person, No System" pattern suggests team may question new manager's authority or interpret structured process as micromanagement

What Beat 1 would have prevented: By Week 4, the operations manager had already summarized the SOP via Slack without the owner's announcement. Beat 1 would have flagged this as a sequencing violation — the owner hadn't spoken yet, so nothing downstream should have moved.

Beat 2 — What Was Actually Built (Week 4)

Engagement State When Change Communication Triggered

Week 4 of a 6-month Advisory OS engagement. Four builds sequenced. The engagement was hired to solve a constraint matrix showing one missing operating system creating nine downstream expressions — the "Right Person, No System" pattern (third occurrence for this firm).

Build Status at Trigger Point

Evidence That Triggered Change Communication

Signal 1 — Proxy communication instead of direct introduction. The operations manager summarized Phase 3 of the SOP to the delivery team via a Slack message. The team received a text summary of one-third of a 16-step, three-phase operating system. They had not seen the actual document.

Signal 2 — Team member resistance. One delivery staff member escalated directly to the owner, expressing that the new process felt like micromanagement. Key detail: this person had never seen the SOP. They were responding to the experience of being managed by a system they hadn't been introduced to.

Signal 3 — Owner acting as participant, not sponsor. In email communication about the resistance, the owner used language like "we're all in this together" and positioned himself alongside the team rather than as the person who made the decision. The operations manager was uncertain about sharing the SOP directly with the team — she asked the consultant whether she should, rather than knowing that was the plan.

Signal 4 — Escalation routing. The team member went directly to the owner with concerns rather than to the operations manager. This told us: the team didn't know the operations manager had authority over this process. The owner had never said so publicly.

The Gap — Stated Plainly

The SOP was well-designed, thoroughly reviewed, and the operations manager understood it. The bottleneck had shifted from design quality to organizational adoption. The builds were good enough — but nobody had told the team what was changing, who owned it, and what it meant for them. The communication track was informal and incomplete.

What Was Built

Three deliverables, all in the client's brand system, designed to sit alongside the existing SOP and project plan as part of the same engagement.

Document 1: Change Communication Plan

Format: Single-page grid with context block, principles section, 11-step communication sequence table, First Win Protocol, and action items for the owner.

Key structural decisions:

Ownership mapping: The firm owner was gold (process owner of the communication). The operations manager was stone (executes communication steps within the owner's plan). This was the inverse of the SOP, where the operations manager was gold. The principle: gold follows the process owner of the specific document, not the person who happens to be most involved in the engagement overall.

Communication sequence: 11 steps organized into three phases — Before Active Close, During First Close Cycle, After First Close. Each step had five columns: What Gets Communicated, To Whom, By Whom (color-tagged), Prerequisite, By When.

Gate mechanism: A gate row between Step 1 (owner's authority announcement) and Steps 2-7. The gate was labeled with a lock icon and the text: "Steps 2-7 are sequenced after the owner speaks to the team. This is the prerequisite for everything below." Nothing downstream could proceed until the owner made the announcement.

Three principles:

1. Your Voice Comes First — owner speaks before process owner walks through the SOP
2. Show the System Before Enforcing It — team sees the SOP on screen before accountability
3. Name the Win When It Happens — owner acknowledges first result publicly

First Win Protocol: Defined the trigger (operations manager's first snapshot delivered OR first close cycle completing at target on-time rate), the acknowledgment mechanism (1-2 sentences in the owner's existing Friday CEO memo), example language, and a note explaining why it matters.

"What This Needs from You" section: Three timing blocks — Before Monday's Close (authority announcement + review Build 3 templates), During Close (read weekly snapshot, be available for 1:1s), After Close (First Win acknowledgment in CEO memo). Each item had a what and a why. Owner-colored borders on action items.

Document 2: Sponsor Activation Brief

Format: Reference document with context block, team announcement framework, 1:1 conversation scenarios, sponsor moments, coaching block, and change network definition.

Key structural decisions:

Team announcement framework: Three-part structure — What's Changing (standardized process with defined SOP), Who Owns It (operations manager with owner's full authority), What It Means for You (expectations written down, one process, one system). Labeled explicitly as "adapt to your voice" — starting points, not scripts. Optional context paragraph for growth framing.

1:1 conversation scenarios: Three scenarios extracted from the actual evidence:

• Scenario A — "Feels like micromanagement": Acknowledge → Redirect from "oversight of you" to "removing owner as bottleneck" → Be specific about what changes. Avoid note: don't agree it's micromanagement (it isn't), don't criticize previous work quality (change is structural, not corrective).

• Scenario B — "Why is [operations manager] in charge?": Separate process (owner's decision) from coordination (operations manager's job) → Acknowledge team member's experience without undermining operations manager → Hold firm: "that's my call." Avoid note: don't hedge on operations manager's authority, don't promise the team member can bypass them.

• Scenario C — "Why now — we're in our busy season": Validate the timing pressure → Hold the decision (there's never a perfect month) → Reframe as relief (the system makes this period easier, not harder). Avoid note: don't apologize for timing, don't suggest the change is optional.

Coaching block: Dark background. Framing: "Leading your team through operational transition is a skill you're building. This is the first time you've had a system to transition to." Ask: record next team meeting and next 1:1 with operations manager, send transcripts, consultant provides feedback on communication patterns. Explicitly framed as building capability, not catching mistakes.

Change network: Three people — operations manager (process owner), tool champion (platform expertise and training), client success coordinator (onboarding communication coordination). Each one had a role definition and a note explaining why the team needs to understand their function.

Document 3: Team Communication Playbook

Format: Interactive tabbed document with four communication types, each self-contained.

Key structural decisions:

Navigation: Four tabs across the top — Team Meeting (Monday, 5-10 min, prep: 5 min), 1:1 Concerns (as needed, 10-15 min, prep: 2 min), CEO Memo (after close, 2 sentences, prep: 2 min), Weekly Check-In with Operations Manager (weekly, 5 min, prep: 0).

Team Meeting section: Four numbered talking points with time estimates. Each had a direction (what you're doing), a language block (starting point to adapt), and where relevant, a note. The fourth point (Close) included the instruction: "Then stop. The instinct will be to keep talking, add caveats, soften it. The message is clear as-is."

1:1 Concerns section: Three scenario tabs matching the sponsor brief scenarios. Each had: trigger box ("You'll hear something like..."), numbered steps with language blocks, and an avoid note. Tab interface let the owner click to the relevant scenario without scrolling through all three.

CEO Memo section: Three trigger templates — (A) first snapshot delivered, (B) close cycle completed on new process, (C) something went wrong but the system caught it. Each had draft language with fill-in-the-blank placeholders. The third template was the insight: even when something breaks, if the system identified it early, that's the win to name.

Weekly Check-In section: Three structured questions — "Anything need my attention?", "How's the team responding?", "What do you need from me?" Outcome box explicitly named what this replaces: "The pattern where you check in on specific clients, ask about individual staff members, and end up back in the details. Three questions, five minutes, then you're out."

Print mode: All sections expanded, all scenario panels visible. JavaScript tab switching for screen use.

Corrections Made During QC

Month Accuracy

Initial build referenced "March close" throughout. The close cycle being deployed was February (active close starting the first business day of March for February's books). Every reference was corrected: phase headers, memo draft language, speech framework text, prerequisite descriptions. The principle: the month of the close is the month whose books are being closed, not the calendar month the work happens in.

Ownership Color Mapping

Initial build had the firm owner in copper (approver) and the operations manager in gold (process owner). This was correct for the SOP but wrong for the communication documents. In the communication plan, the owner is the process owner — they own the communication sequence. Corrected: owner to gold across all three documents, operations manager to stone. All CSS definitions, tag classes, legend dots, border colors, and card backgrounds updated. Zero copper remaining in any document.

Content Rule Violations

Four AI writing pattern violations caught and fixed:

1. "People don't resist better systems. They resist being managed differently" — negation pattern ("It's not X, it's Y" structure). Rewritten.
2. "Not a celebration speech. A factual acknowledgment" — negation pattern. Rewritten.
3. "This isn't about catching mistakes. It's about helping develop..." — negation pattern. Rewritten.
4. "She's not a layer between them and you — she's the person who owns this" — negation pattern. Rewritten.

Role Title vs. Owner Name in Tags

One row in the communication sequence used a generic role title ("Senior Advisor") in the owner tag instead of the owner's name. Inconsistent with every other row. Fixed: tag uses the person's name, prerequisite text explains the role ("senior advisor — owner or partner, depending on the client — approves before send").

Speech Framework — "Not More Oversight, Better Structure"

One language block in the communication plan's action items section contained the phrase "not more oversight, better structure." This is a negation pattern disguised as a reassurance. Rewritten to affirmative: "a defined process that makes expectations clear, with better structure than what they've been working with."

Key Lessons from This Build

1. The ownership mapping decision is the first decision, not the last. Getting gold wrong cascades through every tag, border, legend, and visual hierarchy in the document. Decide who owns the process in each document before writing any HTML.

2. Month accuracy requires active verification. The natural instinct is to name the calendar month the work happens in. The correct reference is the month whose books/work/cycle is being completed. This distinction caused errors in all three documents and required a full audit to fix.

3. The playbook is the document that gets used. The brief gets read once. The communication plan gets checked for sequencing. The playbook gets opened before every conversation. Design accordingly — the playbook needs the most polish, the most self-contained sections, and the lowest prep time.

4. AI writing patterns hide in speech frameworks. The "It's not X, it's Y" pattern is especially insidious in language blocks because it feels like natural speech. It isn't — it's a consultant construction that sounds artificial. Real speech is affirmative: "She owns this process" not "She's not a layer between you — she's the one who owns this."

5. Resistance scenarios must come from evidence, not templates. The three 1:1 scenarios were extracted from what actually happened in the engagement — a team member who felt micromanaged, the dynamic of a newer operations manager directing more senior staff, and timing pressure during the firm's busiest season. Generic resistance templates ("people resist change because...") would have been useless.

6. The weekly check-in section was not in the original spec. It was added during the playbook build because the pattern was visible: the owner's old behavior (stepping into details, checking on individual accounts) needed a structured replacement, not just removal. The three questions give the owner an exit from the old pattern while keeping them informed at the right altitude.

7. The gate mechanism is the most important structural element in the communication plan. Without it, the sequence is a suggestion. With it, Step 1 (owner speaks to team) becomes a hard prerequisite that visibly blocks everything downstream. The owner sees: "Nothing moves until I do this." That's what creates urgency.

8. Beat 1 would have caught the sequencing violation. The operations manager's Slack summary (Signal 1) happened because no one had mapped the communication sequence. If the skeleton sequence existed from project scaffolding, the prerequisite structure would have flagged: "owner hasn't spoken yet — nothing downstream should move."