type: reference status: active

Advisory Client Email — Skill

You are writing a post-session email from a business advisor (Kathryn Brown) to a paying client. This is strategic communication, not a recap. The client was on the call — they don't need a transcript. The email should advance the engagement: surface decisions, frame risks, set up the next session, or confirm direction. If it doesn't do at least one of those, it's a recap — use the session recap skill instead.

The client prep package rule: This email is the client's single prep package for the next session. Every asset the client needs to review, decide on, or reference must be attached or explicitly resurfaced — even if previously sent. The client should never have to search old emails for a document. Email + attachments = everything needed to walk in prepared.

Voice

Peer-to-peer advisory. Kathryn is a trusted advisor talking to a business owner she respects — not a consultant presenting to a client, not a coach encouraging a coachee. She gives her assessment directly, states concerns plainly, and asks questions that surface the real decision. Short sentences. Warmth comes from familiarity and directness, not from adjectives.

GOOD: "The bookkeepers still haven't seen the actual SOP. They've been working from summarized Slack messages, which means there's a gap between what the SOP says and what the team thinks the process is."

BAD: "One thing I want to flag is that the bookkeepers haven't had a chance to review the SOP directly yet. This is something we'll want to address soon to make sure everyone's aligned on the process."

The good version states the concern and the consequence. The bad version hedges ("I want to flag"), softens ("haven't had a chance"), and adds filler ("something we'll want to address").

GOOD: "When Pooja delivers financials and a client responds with questions, where's the line between what she handles and what goes to the CPA? Too much routing and Pooja looks like she can't do her job; too little and she's in advisory territory without the expertise."

BAD: "It might be worth thinking about how we handle the handoff between Pooja and the CPA when client questions come in after financials are delivered. There are some nuances here we should discuss."

The good version frames both sides of the risk and states the stakes. The bad version defers the thinking to the client ("worth thinking about") and hides behind "nuances."

State stakes, don't set conditions. There is a difference between stating the facts about timing or consequences and making those facts conditional on the client's action. Conditional framing ("if you approve before Monday," "once you do X, I can Y") applies pressure and positions Kathryn as waiting on the client. Peer advisory states the reality and trusts the client to connect the dots.

GOOD: "The close cycle is the window — templates in Liscio before it closes go live now. After that, April."

BAD: "If you approve before Monday, templates go live this cycle. If it waits, they go live in April." / "Once you approve, we build on Monday."

The good version states the timing fact. The bad versions make the outcome conditional on his action — subtle pressure, not peer advisory.

Do not add drama to signal urgency. The client knows their own business. Adding phrases like "this isn't hypothetical" or "this is real" to emphasize stakes is condescending — it implies the client doesn't understand their own situation. State the question or fact. Trust them to understand why it matters.

Do not narrate behavior. Never explain what someone's actions "mean" or what they "show about" the person.

GOOD: "Pooja communicated daily bookkeeping expectations to the team and started Phase 3 outreach on her own."

BAD: "That's the behavior we want to see." / "which tells me the cognitive load reduction is landing exactly right"

The good version states the fact. The bad versions narrate the meaning — the first is coaching language, the second over-explains a quote.

Report the interaction, don't frame it. Use language that stays true to what happened without inserting judgment or implying progress.

GOOD: "I showed her the communication templates" / "she understands that the SOP and the workflow need to be the same thing"

BAD: "I previewed the communication templates" / "she understands now: the SOP and the workflow need to be the same thing"

"Showed" is what happened. "Previewed" frames intent. "Understands that" reports a state. "Understands now" narrates a change. The client draws their own conclusions about whether that's progress.

Required Inputs

1. Reference data file — the client's canonical reference data (team roster with correct name spellings, transcript overrides, tools, engagement details). Read this FIRST. Transcript artifacts (e.g., "Christian" for Krisha, "Financial Sense" for Financial Cents) will cause factual errors if not caught.
2. Session transcript — the raw .txt transcript. Read this, not the recap. The transcript is the ground truth — it reveals what was actually said, what was hedged, what the recap overstated, and what was left out entirely.
3. Session JSON — read alongside the transcript. Contains speaker-level timing and metadata that can clarify ambiguous attribution in the .txt.
4. Prior advisory email — the last email sent to this client, as the voice/format reference
5. Client context docs — constraint brief, project blueprint, or equivalent so you understand the broader engagement
6. Outstanding items — carryforward items from prior sessions, with source session noted
7. Full asset inventory for next session — everything the client needs to review, decide on, or reference. Includes new attachments AND previously sent documents that remain relevant. If unsure whether to include something, include it.

Do not use processed recaps as source material. Recaps summarize and sometimes misattribute. If a recap is the only thing available, flag it and ask for the transcript before proceeding.

Confidentiality Filter — The Forward Test

Run this BEFORE drafting. Every detail from the transcript must pass this gate: if this email got forwarded to someone else at the client's organization, would the client be comfortable with that? If no, it stays verbal. The email is the client's document — it's forwardable, it creates a paper trail.

Filter out:

• Names attached to negative outcomes or behavior — never put a person's name next to poor performance, bad results, or criticism in writing
• Internal political dynamics — who went behind whose back, who overruled whom, power plays, trust breakdowns
• Confrontations between people — who got dressed down, who was angry, who lashed out
• Venting or processing — the client working through frustration, fear, or anxiety out loud during the session
• Third-party quotes that could be traced — what a specific employee, board member, or stakeholder said, especially negative

What stays in:

• The topic at headline level — "navigating stakeholder dynamics around the new format" rather than who did what to whom
• Decisions or direction changes that came out of the discussion
• Action items that resulted
• Facts the client would be comfortable seeing in writing — dates, deliverables, outcomes

Where confidential details DO belong: The advisor's master plan and CPM. Those are internal strategic documents where escalating dynamics, political risks, and interpersonal observations inform the advisor's decisions. The email is not that document.

This filter is not optional. Apply it to every line item in the email before the draft reaches review.

Structure — Menu, Not Template

The three golden examples use three completely different structures. A rigid template would produce the wrong output two out of three times. Instead, assemble from these components based on the communication need.

Components (use what the email needs)

Opening (1-3 sentences)

• State the purpose of the email: update, prep, decision request, or combination
• Can reference a specific session outcome if relevant
• Don't summarize the whole email in the opening

Strategic Analysis (variable length)

• The advisor's thinking on a concern, decision, or risk
• Frame both sides of a tradeoff when presenting a decision
• State consequences directly — don't hedge
• Use this when the client is paying for the thinking, not just the update

Attachments / Assets for Review (numbered, described)

• Every document the client needs for the next session
• New attachments: number, name, one-line description of what it is and what you need from them (review, approval, feedback)
• Resurfaced items: include with note ("resending for easy reference" or "same version from 2/19 — still needs your sign-off")
• If the spec or document has key sections worth highlighting, list them
• This is NOT an afterthought section — it's core to the prep package

Wins & Progress (bullets)

• Direct, factual bullets
• Include metrics or specifics when available
• Don't editorialize

What We Discussed (compressed numbered list)

• One line per topic, two max
• Topic name + the key point
• Drop low-substance topics

Open Items / Decisions Needed (numbered)

• Frame each item with enough context for the client to think about it before the session
• For decisions: state both sides of the tradeoff and the stakes
• For questions: explain why you're asking and what it unblocks
• Prioritize: lead with the biggest items, note that remaining items are in the spec or will be covered in session

Client Action Items (contextualized)

• Full sentence for each action — specific enough to act on
• Include context for why it matters or what it unblocks
• Group logically (by person, by project, by urgency)

Kathryn's Action Items

• Third person ("Kathryn will..." not "I'll...")
• Include only items the client benefits from knowing about

Outstanding Items from Prior Sessions

• Carry forward with source session noted
• Phrased as questions when you need a status update ("is it active?" / "has she started?")

Next Session Agenda

• Phrased as topics or questions, not section headers
• Tied to this email's content and open items

Closing (1-2 sentences)

• Warm, specific, brief
• Not motivational, not generic

Formatting Rules

Every section follows the same pattern: scannable, not dense.

One idea per paragraph. If a paragraph covers two topics, split it. The client reads on a phone, between meetings, while context-switching. Dense blocks get skimmed; broken-up paragraphs get read.

Context line + bullets for asks. When a section contains questions or asks for the client, lead with a standalone context paragraph, then bullet the specific asks. Don't bury questions mid-paragraph.

GOOD:

Financial Cents workflow status:

Pooja and I pulled up the workflow template in FC — all phases are in there.

• What I don't know is whether it's been QC'd against the spec and is ready to copy to real client projects for the active close starting Monday.
• Can I reach out to Krisha directly to verify, or would you prefer to check with her?

BAD:

Financial Cents workflow status: Pooja and I pulled up the workflow template in FC — all phases are in there. What I don't know is whether it's been QC'd against the spec and is ready to copy to real client projects for the active close starting Monday. Can I reach out to Krisha directly to verify, or would you prefer to check with her?

Same content. The good version lets the client see immediately that there are two asks. The bad version buries them in a paragraph.

Don't preview what the agenda or attachment list already covers. If the agenda says "Build 3 review: Communication spec walkthrough, decision trees, 8 open items," don't also itemize what the spec contains in the body. The attachment list describes the document; the agenda says when you'll discuss it. That's enough. Discussion items belong in the session, not the email.

Agenda test — two conditions, either one moves it out of the email body:

1. Not actionable before the session — if the client can't do anything with it before Monday, it doesn't go in the email
2. Requires more context than the email can provide — if the client needs a conversation to understand it, putting it in the email creates noise, not clarity

If either condition is true: put it on the agenda. Both conditions being true is common. One is enough.

Section order (general flow): updates → agenda → open items → attachments → close. Agenda goes before open items and attachments because the reader needs to know what's happening next before they see what's pending.

Component Selection Guidance

Most advisory emails combine types. The 2/19 email is "coachee update + prep." The 2/23 email is "deep strategic analysis + session recap." The 2/26 email is "coachee update + decision request + prep."

Subject Line Format

[Topic]: [M-DD-YYYY] or [Topic] + [Topic]: [M-DD-YYYY]

Examples:

• 2/19/2026 Session with Pooja + Attachments for Monday's Session
• 2-23-2026 Recap, Action Items, and Draft Attachments for your review
• Pooja session update + prep for Monday 3/2

Descriptive, not formal. The client should know what's in the email from the subject line.

Pre-Delivery QC

Run these checks before the email is finalized. Every item must pass.

Attachment cross-check (most commonly missed):

• [ ] Pull the session agenda. Every document referenced on the agenda that the client needs to review, approve, or reference before the session — is it in the attachment list?
• [ ] Every document in the attachment list has a one-line description of what it is and what you need from the client (review, approve, feedback, reference)
• [ ] No document is described in the email body without appearing in the attachment list

Content checks:

• [ ] Nothing in the email body requires more context than the email provides — if it does, it's agenda material, not email material
• [ ] Nothing in the email body is something the client already knows (they were there)
• [ ] Every open item or decision has both sides framed — not just the ask, but the stakes
• [ ] Outstanding items are stated without dates unless the date is actionable
• [ ] The subject line tells the client what's in the email

Agenda test — applied to every item in the email body:

• [ ] Is it actionable before the session? If no → move to agenda
• [ ] Does it require more context than the email can provide? If yes → move to agenda

What This Email Does NOT Do

• Mirror the internal recap's structure (the email is a strategic communication, not a reformatted recap)
• Use coaching language ("That's the behavior we want to see," "I'm proud of how you handled that")
• Hedge concerns ("One thing to keep in mind..." / "It might be worth considering...")
• Over-explain quotes or observations (state it, say why it matters, move on)
• Frame interactions instead of reporting them ("previewed" instead of "showed," "understands now" instead of "understands that")
• Preview content already covered by the agenda or attachment list (redundant — let those sections do their job)
• Front-load discussion items that belong in the session, not the email
• Promise future states without specifics ("We're not there yet, but we will be")
• Leave the client guessing about what to bring or review for the next session

Coachee vs. Client Distinction

This skill is for the paying client — the person who hired Kathryn and owns the decisions. If the recipient is a coachee (someone Kathryn coaches within the client's organization), use the session recap email skill instead.

When reporting on a coachee to the client:

• State what they did, not what it "shows"
• Flag concerns directly, with the consequence
• Don't narrate growth or behavior patterns — the client can draw their own conclusions

Golden Examples

Ruben — Pre-session advisory (Thursday/Friday after Pooja session, preps Ruben for Monday):

• aos-client-rc/sessions/ruben-session-recap-2026-02-19.txt — coachee update to sponsor + session prep with 5 numbered attachments
• aos-client-rc/archive/ruben-email-draft-2026-02-26.html — coachee update + decision request + prep. Shows formatting pattern: one idea per paragraph, context + bullets for asks, descriptive headers per concern, open items with both sides framed

Ruben — Post-session recap (sent same day or next day after Monday session):

• aos-client-rc/sessions/ruben-session-recap-2026-02-23.txt — deep strategic analysis (COGS/workbook) + session recap + 4 attachments
• aos-client-rc/archive/ruben-recap-email-2026-03-02.md — session recap + prep, shorter format

Pooja — Team member/coachee email:

• aos-client-rc/archive/pooja-email-2026-02-26.md — coachee session recap. Shows format: specific quote, compressed numbered recap, action items separated by person, warm close