Website maintenance
Write a maintenance window notice customers can act on
A guide to maintenance notices that tell customers what will stop, what still works, and what to do instead, without alarm or vague promises.
Start with repeatable IT work that has a clear owner, clear access limits, and a review cadence. Keep risky technical decisions with the manager or provider who owns the system.
Delegation playbook
On this pageJump to section
A maintenance notice often says more about the company's process than about the customer's problem. It lists a date, apologizes for any inconvenience, and leaves the reader unsure whether checkout will work at noon. The result is a support queue filled with questions the notice could have answered. A useful notice is a short operational brief: what changes, when, what still works, and where to go if something fails. It respects the customer's time and reduces avoidable tickets.
Start with the customer's decision
Before writing a word, name the decision the customer has to make. They may need to schedule an order, download a file, call a support line, or simply wait. A notice that does not support one of those decisions is probably a status update for the team, not a customer message. Put the decision in the first two sentences and keep the internal schedule detail below it. The reader should not have to infer what to do.
Different audiences need different notices even for the same window. A payroll customer and a blog reader do not care about the same risk. Write one message for the people who depend on the service and a shorter note for everyone else. If the business has account managers, give them the same wording so the story does not change between channels. Consistency is more useful than clever phrasing.
State the window in the customer's time zone
Publish the start and end time with a time zone label, and show the local equivalent for the main customer regions. Avoid phrases like tonight or early morning, because they mean different things to a reader in another country. Include the date as well as the day of the week. If the window could move, say what would trigger the change and where the update will appear.
Give yourself a realistic end time rather than the most optimistic estimate. Customers forgive a longer window that finishes early; they remember a short window that overruns by three hours. Add a buffer for verification and rollback, not only for the change itself. State whether the service will be degraded or unavailable during the buffer. A precise window is a promise, so make the promise one the team can keep.
Say what still works
Customers hear maintenance and assume everything is down. Correct that assumption if it is wrong. Say whether login, checkout, email, or the mobile app will keep working. If only the reporting screen is affected, say so in plain language. A short list of what remains available is more reassuring than a general statement that the team is working hard.
Be careful not to promise availability the team cannot guarantee. If the fallback depends on a second system, name it and say whether it has the same hours. A customer who plans around a partial outage and then finds a full outage will trust the next notice less. When the scope is uncertain, describe the most likely case and the worst case separately. Honest scoping is better than a confident guess.
Give a fallback that does not depend on the website
Provide a phone number, an email address, or an alternate portal that works during the window. Test the fallback before publishing the notice, because a dead support line is worse than no instruction. Say what the fallback can and cannot do, especially for payments or sensitive account changes. If there is no fallback, say that work should wait until the window closes. Customers can plan around a clear limit.
Keep the fallback message short enough to copy into a chat or a social post. Include the hours and the expected response time so people know what to expect. Do not route every enquiry to the same queue unless that queue can absorb the volume. A maintenance window is a bad time to discover that the contact form also depends on the system being updated. Test the path end to end.
Time the notice to the risk
Send the first notice far enough ahead that customers can change a scheduled job or move a payment. For a routine update that may mean three business days, while a disruptive change may need two weeks. Send a reminder on the day of the window with the same link and the same times. Do not rely on a single post that most customers will never see.
Put the notice where customers already look, such as the account dashboard, the status page, or the transactional email footer. Use the same message in every channel and link to one page that will be updated during the window. If the work finishes early, update the page instead of sending another long email. A stable link is easier to trust than a stream of conflicting announcements.
Review the notice after the window
After the change, compare the actual outage with what the notice promised. Record the start, the end, and the number of support contacts that referenced the maintenance. Ask the support team which questions repeated, then rewrite the notice template for the next window. The review is more useful than a satisfaction survey because it points to specific missing information.
Keep the notice and the timeline with the change record so the next owner can see what customers were told. If the window overran, add a short follow-up that explains the delay without blaming an individual. Update the fallback and the status page while the details are fresh. Over time, a small library of tested notices reduces both writing time and customer confusion.
Sources and next step
Use the CISA Cross-Sector Cybersecurity Performance Goals and the NIST Cybersecurity Framework 2.0 as primary references for the access, asset, and recovery practices discussed in this guide. Apply your own policies, contracts, and system documentation to the workflow. Compare this guide with the shared mailbox handover checklist and the maintenance window notice guide before changing a live process.
Keep decisions, approvals, and evidence in systems the business already controls. If the coordination is recurring and your technical owner can define the boundaries, review the IT virtual assistant service areas and contact ITVirtualAssistant to discuss a limited pilot.
Operating brief
What this guide should help you decide
Routine intake, status updates, records, screenshots, and documentation upkeep.
Approvals, risky system changes, security decisions, and final technical judgment.
How to use this guide
Use this page to decide what an IT virtual assistant should handle first. If the task is recurring, documented, and easy to review, it is usually a better first delegation candidate than work that requires live technical judgment.
Treat the article as an operating brief, not just a topic overview. The goal is to turn loose IT work into a named workflow with inputs, outputs, permissions, review cadence, and a handoff rule that protects the business while reducing manager load.
Workflow
Recommended operating workflow
Define the request
Write what write a maintenance window notice customers can act on means in your company, where requests enter, and what finished work looks like.
Limit the access
Give the assistant only the tool permissions needed for intake, records, status updates, or documentation.
Run a pilot
Use a two-week sample period so the manager can review accuracy before expanding the workflow.
Review patterns
Summarize repeat issues, blocked requests, and escalation volume so the technical owner can improve the process.
Decision rules
| Question | VA fit signal | Escalate when |
|---|---|---|
| Is the work repeatable? | The same request appears weekly and can be described in steps. | The request changes business policy or system design. |
| Can quality be reviewed? | The manager can inspect the output without redoing the work. | Only a senior technical person can judge correctness. |
| Is access contained? | The assistant can work with read-only or role-limited access. | Admin rights, customer data, or security settings are involved. |
Delegation checklist
- Write the intake source, expected output, and manager review cadence.
- Confirm the assistant has only the permissions needed for the workflow.
- List the events that require escalation before work continues.
- Track examples for two weeks before changing the workflow.
- Save examples of good and bad outputs so the assistant has concrete references.
- Review the workflow monthly and remove permissions that are no longer needed.
Example first-week agenda
Day one should cover the workflow owner, tools, allowed actions, forbidden actions, and escalation language. By the end of week one, the assistant should have produced a small sample of completed work, a list of unclear requests, and a manager-reviewed improvement note.
What to review before delegating
Confirm the owner, access level, review cadence, and escalation path before assigning any recurring IT workflow to a remote assistant.
What should an IT virtual assistant handle first?
Start with repeatable, reviewable work such as ticket summaries, account records, documentation updates, and checklist follow up.
Get free IT support review