Should internal comms have an SLA?
We didn't have the answer, so we made it the question.
At a recent ICology Campfire, a room of internal communicators spent an hour on it. Should comms commit to a service level agreement with the business, or does a turnaround promise quietly turn the team into an order desk? Nobody walked in certain, which is what made it worth the hour.
Campfires are our monthly member roundtables. One person brings a real problem, and the room works it out together. This one started because a member asked for an SLA template, and it turned out half the room was wrestling with the same thing.
Here's what came out of it.
The most useful SLA might not be the one you'd expect
The conversation opened where you'd expect. An SLA is a promise to stakeholders: you give us lead time, we give you a turnaround.
Then it flipped. The agreement that matters most isn't the one with the business at all. It's the one your comms team makes with itself, so every communicator gives the same answer and no partner can shop around for a different one.
That's harder than it sounds, because of the precedent problem. Do a favor once and it becomes the expectation, cited back to you forever. The SLA only holds if the whole team holds it. The moment one person breaks ranks, it's gone for everyone.
What goes in one
The back half turned practical. The pieces a real SLA needs:
Who it covers. Which leaders and business units get what level of support.
Lead time and complexity. How much notice before comms commits, and what you get at each level. Short notice means less help, not no help.
Tiers of support. Full strategic partnership at the top, self-serve templates at the bottom, a clear line between.
Scope. What comms does, and what it doesn't. Pulling the distribution list, for example, belongs to HR. Name the handoffs up front.
The approval maze came up too. The version that works names who signs off at each gate instead of looping through endless rounds of "how's this one now." For an earnings release, that might be finance on the concept, then investor relations, then legal before publish. Specific roles at specific steps, with time built in for each.
There was also the filter for deciding what earns full support: how many people it touches, one location or all, whether it's safety or business critical, and the real deadline. Headcount alone doesn't settle it. Ten people losing a benefit can outrank two hundred getting an FYI.
We built a tool from it
A blank page is the enemy, and a Fortune 500 SLA and a mid-size one probably look 80% alike. So the structure can be shared.
We turned the conversation into a prompt. Drop it into Claude, Copilot, or Gemini, answer a handful of questions, and it drafts your own SLA, tiers and approval gates included. It won't be finished. It'll get you most of the way there, which beats starting from zero.
That prompt is the first entry in a community-led prompt library we're starting, made for internal communicators, by internal communicators. The model is simple. A real conversation surfaces a real problem, and the community builds something you can use on Monday.
Come have the next one with us
The best conversations in internal comms happen when practitioners work through the hard stuff together, before it's a webinar title or a tidy framework.
That's what ICology is for. Join us in the community and come to the next Campfire.
Internal comms SLA builder
Copy the prompt, paste it into Claude, Copilot, or Gemini, and answer its questions. It drafts your own SLA, approval gates included.
You are helping me, an internal communications practitioner, build a service level agreement (SLA) for my team. An internal comms SLA does two jobs: it sets expectations between comms and the rest of the business, and it keeps my own team giving one consistent answer so partners can't shop around for a different one. Do not write the SLA yet. First, ask me the questions below in small batches (three or four at a time), wait for my answers, and use them to tailor the draft. If an answer is vague, ask a follow-up before moving on. If I don't know an answer, suggest a sensible default and tell me it's a default. Ask me about: **1. Who this covers.** - Who does my comms team support? (whole company, specific business units, leadership tiers) - Do different leaders or levels get different levels of support? Describe the tiers if so. - Who on my side is bound by this agreement? (just me, a full team, agency partners) **2. Levels of support.** - What does full support look like versus self-service? Give me your split. - What can partners do themselves with a template, and what requires a communicator? **3. Lead time and complexity.** - How much notice do I need before I'll commit to a deadline? - What's realistic turnaround for a simple request versus a complex one? (drafting days, review days, translation or localization days) - If someone gives me less notice than that, what happens? Do they get a reduced scope, a later date, or no help? **4. Scope: what comms does and does not do.** - What work is squarely comms? - What work do people wrongly assume is comms but isn't? (for example, pulling distribution lists, owning HR systems) - For those, who owns it instead, and where's the handoff? **5. Approvals and sign-offs.** - For a standard piece of work, who reviews and who approves, in order? - Do reviewers know whether they're giving conceptual approval, line edits, or final sign-off? (name the type at each step) - For high-visibility recurring work (earnings, town halls, restructures), map the specific approval chain and who's needed at each gate. - How much time does each approval step get, working backward from the publish date? **6. Emergencies and exceptions.** - What counts as a true emergency that jumps the queue? - Who is allowed to declare an emergency? (not everyone should be able to) - What's the reduced process for genuine emergencies? **7. The intake filter.** - Do I want an intake form or a set of qualifying questions partners answer before comms engages? - Which impact questions decide whether something gets full support: number of people affected, one location or all, safety or critical status, whether it changes or removes a benefit, and the real deadline? - Include a question that ties every request to a business objective, mission, or value. If it doesn't ladder up to one, it may not need comms. **8. Enforcement.** - What happens when someone on my team makes a one-off exception? (because that exception becomes the new precedent) - What's the repercussion, if any, for breaking the agreement, on either side? - How do we re-standardize when someone drifts? Once you have my answers, produce TWO versions: **A. The one-pager.** A clean, scannable SLA someone can actually read and remember. Tiers, lead times, scope, the emergency rule, and the approval summary. This is the traveling version. **B. The fine print.** The full document. Every tier spelled out, the complete approval maps for recurring high-visibility work, the intake questions, the exception process, and the enforcement terms. Rules for the output: - Write it in plain, direct language a busy communicator and a skeptical stakeholder would both accept. - Frame my team as strategic advisors, not order takers, without being preachy about it. - Make the two-way nature obvious: what the business gets, and what the business owes me (lead time, a real brief, a single approver) to make it possible. - Flag anything I left blank that a real SLA would need, so I know what's still missing. After both drafts, give me a short list of the three or four decisions I should pressure-test with my own team before this goes live.
Written by Chuck Gose, founder of ICology.