| Category | Client Onboarding |
|---|---|
| Time to Run | 10 min |
| Difficulty | Standard |
| Output | Script |
| Client-Facing | No — internal use |
You're in the kickoff meeting or you just finished it, and you realize you haven't explicitly said how you work together. The scope is clear. The deliverables are clear. But the operating norms — how fast you respond, what channel to use, what happens when something goes wrong — those are still unspoken assumptions. Unspoken assumptions are where client friction starts.
Run this during or immediately after the kickoff when you need to align on the working relationship itself. Not what you'll deliver, but how you'll deliver it — communication preferences, response time expectations, escalation protocols, and the boundaries that keep the engagement healthy for both sides.
Copy the code block below and save it as a .md file. Upload it to Claude as a Project Knowledge file or attach it directly to a conversation. Then provide the inputs listed above and Claude will generate your expectation-setting script.
---
name: expectation-setting-script
description: Generates talking points for aligning on working norms during onboarding — triggered during or immediately after the kickoff when operating expectations need to be explicit.
metadata:
author: "Kathryn Brown, Practice Builders"
version: "1.0.0"
date: "2026-04-25"
---
# Expectation-Setting Script
Generates a conversational script for establishing working norms, communication protocols, and escalation paths with a new client.
**Core Principle: State the norms before they're tested. Expectations set proactively are agreements. Expectations set after a conflict are corrections. The first costs you two minutes. The second costs you the relationship.**
## What This Skill Does
**Job 1: Norm Articulation** — Takes the user's working preferences and translates them into clear, conversational language. "I respond within 24 hours" becomes a specific talking point about when the client can expect to hear back, what happens on weekends, and what constitutes an urgent exception.
**Job 2: Boundary Framing** — Identifies the boundaries that need to be set based on the engagement type and frames them as collaborative norms rather than restrictions. A retainer client needs different boundaries than a project client. The skill adjusts tone and content accordingly.
**Job 3: Escalation Definition** — Creates a specific escalation path so that when something goes wrong (and it will), both sides know what to do. This prevents the midnight text, the passive-aggressive email, and the "I've been trying to reach you" conversation.
## Section 1: Communication Norms
Generate talking points covering:
- **Primary channel** — where day-to-day communication happens
- **Secondary channel** — what's reserved for what (email for deliverables, Slack for quick questions, phone for emergencies)
- **Response time** — specific commitment, not "I'll get back to you quickly"
- **Meeting cadence** — how often you meet, the default format (video, phone), and how meetings get rescheduled
Frame each as "Here's how I work" not "Here are my rules." The tone is collaborative: "I've found this works well" rather than "This is my policy."
**What to watch for:** If the client's preferred communication style conflicts with yours (they want texts, you prefer email), the script should acknowledge both preferences and propose a compromise rather than just stating yours.
## Section 2: Availability and Boundaries
Generate talking points covering:
- **Working hours** — when you're available and when you're not
- **Weekend/evening policy** — whether you respond outside hours and under what circumstances
- **Vacation/absence protocol** — how you handle planned absences
For retainer clients, this section is critical. The implicit expectation of a retainer is "available anytime" — the script must explicitly redefine that without making the client feel they're getting less than they paid for.
For project clients, this section can be lighter. Focus on turnaround times for deliverables rather than general availability.
## Section 3: Deliverable Review Process
Generate talking points covering:
- **How work products are shared** (email attachment, shared drive, project tool)
- **Review window** — how long the client has to review and provide feedback
- **Revision expectations** — how many rounds of revision are included, what constitutes a revision vs. a scope change
- **Approval protocol** — who signs off and how
This section prevents the open-ended revision loop that erodes profitability. Name the norms before the first deliverable goes out.
## Section 4: Escalation Protocol
Generate a simple escalation path:
- **Level 1:** Something's not right — raise it in the next scheduled meeting or via primary channel.
- **Level 2:** Something's urgent — here's how to reach me directly (phone, text, specific email subject line).
- **Level 3:** Something's broken — the engagement is at risk. Name the process for addressing it (emergency call within 24 hours, scope review, etc.).
Frame this as "for both of us." The escalation path applies to you raising issues with the client too, not just the client reaching you.
## Section 5: What to Skip / What to Watch For
**Leave alone:** Don't script every possible scenario. The goal is to establish 4-5 core norms that cover 90% of interactions. Edge cases get handled as they arise, but the foundation is in place.
**Watch for:** Clients who respond to expectation-setting with "oh, we're pretty flexible" or "whatever works for you." That's not agreement — it's deferral. They'll have specific expectations later, and they'll be annoyed when yours don't match. Push for specifics: "Great — so if I send a deliverable on Monday, when should I expect your feedback?"
## Quality Check (Internal — never shown to the user)
| # | Check | Pass? |
|---|-------|-------|
| 1 | Does every norm include a specific commitment (not vague language like "promptly" or "regularly")? | |
| 2 | Is the tone collaborative, not legalistic? Would you actually say these words out loud? | |
| 3 | Does the escalation path have at least three levels with clear triggers? | |
| 4 | Are the norms adjusted for the engagement type (retainer vs. project vs. advisory)? | |
| 5 | Is there at least one boundary that protects the consultant's time without sounding defensive? | |
**Enforcement:** Run all five checks. Identify the weakest section. Rewrite it. Verify the rewrite improved the output. Present only the finished version.
## Rules
- Write in conversational tone. These are talking points, not contract clauses. The user should be able to read them aloud naturally.
- Every norm must be bidirectional where applicable. If you commit to 24-hour response times, name what you expect from the client too.
- Adjust formality and detail based on engagement type. Retainers need more structure. Short projects need less.
- Keep the full script under 600 words of talking points (excluding the headings and instructions).
- Do not include pricing, scope, or deliverable details — those belong in the SOW and kickoff agenda.
- Never frame boundaries as apologies. "I don't check email after 6pm" not "Sorry, I'm not available evenings."
- Include at least one explicit permission for the client to push back: "If this cadence doesn't work for you, let's adjust now."
## Output Format
# Expectation-Setting Script: [Engagement Type] with [Client Name]
## Communication Norms
"Here's how I typically work with [engagement type] clients..."
- **Primary channel:** [Channel] for [type of communication]
- **Response time:** [Specific commitment, e.g., "within one business day"]
- **Meetings:** [Cadence, format, rescheduling protocol]
- [Additional norm based on inputs]
**Signal:** [What in the engagement type triggered this communication structure]
**Do This:** [State this in the kickoff; ask "does this work for your team?"]
## Availability
"I want to be upfront about when I'm available so there are no surprises..."
- **Working hours:** [Hours and timezone]
- **Outside hours:** [Policy]
- **Planned absences:** [Protocol]
## Deliverable Review
"When I send work your way, here's how the review process works..."
- **Delivery method:** [How work products are shared]
- **Review window:** [Timeframe for client feedback]
- **Revisions:** [What's included, what triggers a scope discussion]
## Escalation
"If something's not working — on either side — here's how we handle it..."
- **Not urgent:** [Raise in next meeting or via primary channel]
- **Urgent:** [Direct contact method]
- **Engagement at risk:** [Emergency protocol]
"And this goes both ways — if I see something that needs to be flagged, I'll use the same path."
## What Makes This Different
Most consultants set expectations implicitly and then correct them after friction. This skill front-loads the conversation, which means the first time a boundary gets tested, you're referencing an agreement instead of introducing a new rule. The difference between "as we discussed in our kickoff" and "actually, I don't do that" is the difference between professionalism and awkwardness.
---
Copyright (c) 2026 Kathryn Brown, Practice Builders
This skill is licensed for your personal and business use. You may run this skill inside your own practice and share the outputs it produces with your team and clients. "Your practice" includes employees and contractors engaged to perform work for your business under your direction — virtual assistants, operations support, bookkeepers, and similar team members.
You may not share, distribute, resell, or repackage the skill file itself — including this SKILL.md document, its prompts, frameworks, and structure — with anyone outside your practice. This includes peer practitioners, other consultants who would use it in their own client work, and anyone outside your operating team. Written permission from Kathryn Brown ([email protected]) is required for any redistribution.
This skill is provided "as is" without warranty of any kind, express or implied.