IT change communication: announcing system changes to your employees

Most guides in this library assume you built the thing you’re announcing. This one is for the people who didn’t: IT teams, sysadmins, and service desks announcing changes to software the company merely runs — the SSO migration, the VPN client swap, new retention rules in the mail system, the vendor’s redesign that lands on every employee’s screen on a Monday. You control the rollout schedule and almost nothing else. Your readers didn’t choose the software, and they can’t leave it either.

That last part changes the economics of the writing. Product changelogs are disciplined by churn: users who feel surprised or ignored can walk, so the notes get written. Employees can’t walk. The cost of bad change communication inside a company lands on different ledgers instead: a ticket spike the morning after every change, shadow IT as teams quietly route around tools that have surprised them once too often, and — the quietest and worst — announcements that stop being read at all, so the one that mattered gets deleted with the noise. Everything below is about spending your readers’ limited attention like it costs money, because it does.

You’re a relay, not the author

For most of what IT announces, someone else wrote the original release notes. The vendor’s notes are aimed at you — the admin who controls the rollout — and good vendors write them exactly that way (that’s the enterprise release notes playbook, seen from the other side of the table). Your job is the second translation: from admin-facing notes to employee-facing announcement. Two rules keep it honest.

Never forward the vendor’s notes raw. They name features your tenant has disabled, flags you haven’t turned on, and editions you don’t own. Of the vendor’s forty bullets, perhaps three apply to your configuration — and only you can know which three, because only you can see the tenant settings. The forwarded email makes every reader do that filtering individually, badly, or not at all. The tenant filter is the actual work of the announcement: your message is those three bullets, rewritten.

Write in the reader’s words, not the project’s. “We’re migrating tenant authentication to OIDC” is a status update for your own team. The employee-facing version names what appears on screen: “Starting Tuesday, signing in to company apps looks different — you’ll see a new ‘Sign in with Okta’ button.” The full translation discipline — UI labels not internal names, symptoms not causes, jargon banlist — is the same one product teams use for non-technical release notes; IT announcements are that genre with a captive audience.

Three kinds of change, three kinds of message

The fastest way to burn your readers’ attention is to announce everything at the same volume. Sort every change into one of three buckets before you write a word.

Invisible changes — routine patching, certificate rotations, backend upgrades nobody will perceive — don’t get announced individually. Publish the policy once (“we patch laptops on the second Tuesday of the month; expect a reboot prompt that afternoon”) and keep a dated log entry for each round for whoever asks. An all-staff email for every patch cycle is how you teach a company to delete your emails; the log-not-email treatment keeps the record without spending attention.

Visible but optional changes — a new feature switched on, a cosmetic refresh, a faster way to do something that still works the old way — get one entry in the change log, mirrored to the chat channel. No all-staff email. These are digest material: a monthly “what changed in our tools” roundup reads well precisely because each item didn’t interrupt anyone when it shipped.

Workflow-breaking changes — the SSO cutover, the VPN swap, the file-server move, a forced UI overhaul — get the full rhythm: advance notice with a date, a reminder as it approaches, a “starting now” at T-0, and an all-clear. That’s the same three-message shape as a scheduled maintenance announcement, plus the thing maintenance doesn’t need: training. Link the two-minute walkthrough, name the people who’ll be walking the floor (or the channel standing by) on cutover morning, and state the day-one fallback in the announcement itself — “if you can’t sign in after the change, here is the number that still works.”

What every announcement must contain

  • What changes, as the reader will see it. Name the button, the screen, the prompt. For anything visual, a before/after screenshot pair beats three paragraphs — employees recognize pictures of their own tools faster than descriptions of them.
  • When, precisely. Date, time, timezone — your company has remote workers even if it didn’t last year. For staged rollouts, give the window and tell readers how to know whether they’ve got the change yet.
  • What the reader must do — including nothing. “No action needed” is the single highest-value sentence in IT communication: it converts an announcement from a task into information, and readers who trust you to say it will actually read the announcements where you don’t. When action is required: numbered steps, an honest time estimate, the deadline, and what happens to people who miss it.
  • Where to get help — specifically. A help link or channel for this change, so the service desk can count and triage what the change causes, plus the known issues you already know about. The honest day-one list kills more duplicate tickets than any FAQ written after the fact.

Where the announcement lives

Email is the default channel and the least-read one. Treat it as a pointer, not the archive. The canonical home is a dated, permalinked change log — an intranet page or a hosted one — because three weeks later, “wait, when did the VPN change?” should be answerable with a link, not an inbox excavation, and because new hires inherit a log but not your old all-staff emails. Mirror each entry to Teams or Slack as title-plus-link — the pointer-not-archive rules apply inside companies exactly as outside. When you control the tool itself, the banner in the product at the moment of use outperforms every other channel. And for the year’s big rocks — migrations, cutovers, audits — keep a change calendar and respect the company’s own rhythm: announcing a file-server move during quarter-close is self-sabotage, which is why mature IT teams borrow the release-freeze idea and schedule around it.

The log is also your diagnostic tool

The first question in triaging any “it worked on Friday” ticket is: did anything change? A dated, append-only change log answers that in seconds. Without one, the answer lives in tribal memory and gets reconstructed per-incident, expensively. The same log gives you your only honest measurement of change quality — ticket volume lined up against change dates — and it compounds: a year of dated entries with owners attached is halfway to what an auditor asks for, the same way a disciplined public changelog halves a compliance questionnaire. ITIL calls this a change record and wraps a framework around it; you don’t need the framework to keep the useful part. What changed, when, who to ask — written at change time, findable forever.

A template that survives contact with Monday

New sign-in screen for all company apps — Tuesday 3 March

What’s changing: signing in to email, chat, and the intranet
gets a new screen with a “Sign in with Okta” button.
Same password. [before/after screenshot]

When: Tuesday 3 March, 07:00–08:00 CET. Sign-in may be
unavailable for ~10 minutes inside that window.

What you need to do: nothing before Tuesday. On your first
sign-in after the change you’ll be asked to re-register
two-factor — takes about two minutes: [walkthrough link]

If something goes wrong: can’t sign in at all? Call the
service desk on [number] — that line doesn’t depend on
the new system.

Known issues: on Safari versions older than 17 the new screen
may load blank — update Safari or use Chrome for now.

Questions: #it-help — mention “sign-in” so we can
triage faster. Full change history: [permalink]

Anti-patterns

  • Forwarding the vendor’s email raw. Forty bullets, three relevant, zero filtered. Every reader now does your job, or nobody does.
  • The jargon announcement. “We are migrating tenant authentication to OIDC” teaches the reader nothing except that something scary is happening to signing in. Translate or don’t send.
  • Friday 17:00 notice for a Monday 08:00 change. The weekend swallows every question, and your reminder is the Monday-morning surprise. Announce breaking changes with at least one full working day for questions to come back.
  • Email-only, no permalink. Unfindable in three weeks, invisible to new hires, useless to the service desk mid-incident. Every announcement gets a URL that outlives the inbox.
  • Announcing everything. When every patch cycle is an all-staff email, employees automate the deletion — and the SSO cutover notice dies in the same filter. Volume discipline is what keeps the loud channel loud.
  • The silent change. Ship it quietly and it lands as a helpdesk mystery: support burns the morning discovering that the outage everyone’s reporting was your own change. The service desk should learn about changes from the log, never from the ticket queue — the same internal-changelog failure, with a budget attached.

Running it on Wakelog

The canonical-log half of this maps directly onto Wakelog: an unlisted project as the IT change log — dated entries, permalinks for helpdesk macros and the new-hire wiki, tags to separate routine patching from workflow-breaking changes, and RSS for whoever automates on top. Scheduled publishing (publish_at) lets you write the T-0 “starting now” entry during business hours and have it post itself at 07:00; the per-project webhook mirrors each entry into your Slack or Discord channel the moment it goes live. Two honest boundaries: unlisted means un-linked, not authenticated — fine for “what changed on our tools,” wrong for anything sensitive — and Wakelog is not an ITSM tool: no approvals, no CAB workflow, no ticket queue. It’s the communication layer, not the change-approval record.

Start your change log — free   Next: scheduled maintenance announcements →

Related guides

Last updated 2026-08-02 · All guides