You’re deep in a complex deliverable when the Slack notification arrives. Then another. Then an email with the same content, in case you missed the Slack. Then a text: “Hey did you see my messages?” Then a follow-up the next morning: “Just wanted to make sure this didn’t fall through the cracks.”
The client who does this isn’t malicious. They’re anxious, and nobody told them how to interact with you. So they use every channel simultaneously, interpret silence as abandonment, and escalate based on their previous experiences with unreliable freelancers.
The communication norms document doesn’t just protect your time and focus. It protects the client from their own anxiety by giving them a reliable, explicit framework for what to expect from you. That certainty, knowing you’ll respond within 1 business day, knowing Slack is for project updates and email is for decisions, knowing what “urgent” actually means, reduces the anxiety that drives messaging chaos in the first place.
Write it once. Use it forever.
Clause 1: Channel Assignments
Every channel has one job. When channels overlap, messages get lost, context gets repeated, and both parties end up confused about where the “real” conversation is happening.
Define each channel you use with its specific purpose:
Exact language:
Email is for: proposals, approvals, formal feedback, billing questions, and anything that needs a permanent written record. Use email when you need a response that becomes part of the project record.
[Slack / Basecamp / ClickUp / Teams] is for: day-to-day project updates, file sharing, quick questions about in-progress work, and scheduling discussions. This is where the live project conversation happens.
Phone or video call is for: pre-scheduled meetings only, and genuine emergencies where immediate conversation is required. Don’t call without scheduling unless it’s an emergency as defined in Clause 3.
Text message is for: emergencies only (see Clause 3). I do not use text for project questions or updates.
Four channels, four jobs, zero overlap. When a client sends a project update via email, you can gently redirect: “Going to move this over to our Slack channel to keep the project thread in one place, replying there.”
Clause 2: Response Time Commitments
This is the clause that prevents “did you see my message?” spirals. Your response time commitment should be specific, realistic, and achievable on your worst days, not your best.
Exact language:
Email: I respond within 1 business day. If you email before noon [your time zone], you’ll have a response by end of business the same day. If you email after noon, you’ll have a response by noon the next business day.
[Project platform]: I check [Slack/Basecamp] twice daily during business hours, once in the morning and once in the afternoon. You’ll receive a response within 4 business hours during [your working hours].
Phone/video: Pre-scheduled only. If you need a call, request it via [email/Slack] and I’ll confirm a time within 1 business day.
I will proactively communicate if I’m unavailable for longer than my standard response window (illness, travel, prior commitment). You’ll know before a gap happens, not after.
The last sentence is the one that builds the most trust. Proactive communication about availability is the single fastest way to reduce client anxiety. They don’t need you available 24/7, they need you predictable.
Clause 3: Defining Urgent vs. Non-Urgent
Without an explicit definition, every client thinks their requests are urgent. With one, genuine emergencies are easy to identify, and they’re also easy to justify responding to outside normal hours.
Exact language:
Urgent means: something that will cause a live, revenue-affecting problem if not addressed within 2 hours. Examples: a broken link in a live campaign, a critical error in a published document, an unexpired credential causing a production system to fail.
Non-urgent means: everything else, including questions about upcoming deliverables, feedback on drafts, scheduling requests, and general project questions. Non-urgent requests receive a response within my standard response window, even if they feel time-sensitive to you.
For genuine emergencies, [your phone number] reaches me directly. I will respond within 30 minutes during business hours, and within 2 hours outside business hours.
Giving your phone number for genuine emergencies is not a risk, clients who receive this level of clarity almost never misuse it. The ones who would abuse an emergency line are the same ones who send 11 Slack messages per day, and the communication norms doc addresses that behavior before it starts.
The freelancers who get the most “urgent” messages are usually the ones who haven’t defined what urgent means. When everything is potentially urgent, everything gets treated as urgent. The moment you define urgent precisely, live, revenue-affecting problem, needs a response in 2 hours, clients stop treating every request as urgent. They’ve been given a standard to evaluate against.
Clause 4: Working Hours and Out-of-Hours Policy
Exact language:
My standard working hours are [hours] [time zone], [days of week]. During these hours, I’m actively working and checking communications on schedule.
I don’t check messages on weekends unless a project is in an agreed critical phase (e.g., live launch, pending deadline). Weekend messages will receive a response on Monday morning.
If I’m going to be unavailable during what would normally be a business day (illness, travel, personal), I’ll email you the day before with a note on when I’ll be back and whether coverage is needed.
I ask the same courtesy in return: if you’ll be unavailable for more than 2 business days, please let me know in advance so I can plan the project timeline accordingly.
The reciprocal request at the end is important. It establishes that communication norms are mutual, not a set of restrictions you’re imposing on the client. They apply to both parties.
Clause 5: How to Request a Meeting
Unstructured meeting requests fragment work schedules. “Do you have 20 minutes sometime this week?” is a coordination burden that requires multiple back-and-forth messages.
Exact language:
To request a meeting, use [Calendly link / “send a proposed time via Slack”]. I block [specific time periods] for focused work and don’t take unscheduled calls during those windows.
For a meeting that requires preparation on my part (a review, a feedback session, a strategy discussion), please send me the agenda or topic 24 hours in advance. This ensures the time is used well.
Regular project cadence meetings (such as our weekly check-ins) will be standing calendar events, no need to re-request those.
Clause 6: Formal Request Submission
Any request that changes scope, budget, or timeline should go through a specific channel to avoid confusion about what’s been agreed.
Exact language:
Scope change requests: Send via email with a description of the requested change. I’ll respond within 2 business days with a quote or clarification. Work on scope changes doesn’t begin without written confirmation from both of us.
Feedback and revisions: Submit in writing, either as comments in the document/design tool or as a written summary in email. Verbal feedback from a call should be followed up with a written summary within 24 hours. I won’t begin revisions based on verbal notes alone.
Approvals: An approval is a written statement: “Approved” or “Approved with the following changes: [list].” Anything short of that, “looks good” in a Slack message, a thumbs-up emoji, a verbal “I think we’re good”, is not an approval and doesn’t trigger my move to the next phase.
That last paragraph about approvals prevents the most common project ambiguity: work that was “approved” verbally, then revised after the next phase had already begun.
The 1-Page Format
After writing all six clauses, format as a clean 1-page document:
- Your name / business name at the top
- Project name (or “all projects” if this is your standing document)
- Date
- Six clauses, each with a header and 3-6 sentences
- A simple acknowledgment line at the bottom: “We’ve reviewed and agreed to the communication norms above.”
At the kickoff meeting, say: “One quick document I want to go over, our communication norms. It covers how we’ll communicate and what to expect from each other. Does anything need adjusting?” Read through it together. Ask if there are concerns. Note their verbal confirmation in the kickoff recap email.
For clients who prefer a formal sign-off, have them add their initials in the document. For most clients, the verbal acknowledgment confirmed in the kickoff recap is sufficient.
Build the template version this week. Customize the channel names, response windows, and working hours for your specific situation. Save it as a PDF named [YourName]_CommunicationNorms.pdf. Attach it to every kickoff.
The first time a client starts to message you across 4 platforms simultaneously, you send back: “Per our communication norms, [link/attachment], Slack is our project channel. Moving this conversation there.” Clean, professional, no friction.
That’s the doc doing its job.
Ready to send stronger proposals?
Build, send, and track proposals in one place so follow-up is easier.
Start your free trial →
