Plan support before and after launch

Use this plan before introducing a new system or set of steps. Complete it with the person leading the change and the people who will handle requests for help.

You will leave with a support plan that names who can help, how to reach them, and what happens when they are unavailable.

1. Agree how support will work

Test each contact route with the people receiving it before sharing it. Urgent problems need a way to get help outside office hours.

2. Prepare people before the change

• ☐ Explain why the process is changing, which tasks change, and what stays the same.
• ☐ Update the SOPs so people know who does each part, who makes decisions, and how handoffs happen.
• ☐ Check the work instructions for the right steps, needed information, and result checks.
• ☐ Provide job aids, including the old-to-new task guide, that users can find and use during the task.
• ☐ Check access, owner, and version for each guide. Remove old guides or clearly mark them as replaced.
• ☐ Let people practice key tasks with the guides and suitable supervision. Watch what they can do. Attending training is not enough.
• ☐ Give affected owners, residents, and vendors clear instructions and a way to get help.
• ☐ Explain what the system cannot do yet and any approved temporary steps.
• ☐ Explain how to report a problem, what details to include, and how users will know someone has taken it.
• ☐ Check that support staff and backups have time to help. Name who can approve a pause and manage recovery.

Use these terms to choose the right guides:

One guide can serve more than one purpose. You do not need a separate document of every type for every task.

For help choosing what to write and how the pieces connect, see Four layers of operating support. It explains the domain overview, SOP, work instruction, and job aid, with worked examples and an editable starter pack. Start with the support this launch actually needs.

For each unchecked item, record who will fix it, by when, what could go wrong, and whether it must be fixed before launch. Add anything still needed to the readiness review.

3. Decide which problems need help first

Triage means deciding which requests need help first. Set times for confirming receipt, responding, and giving updates. Use targets your team can meet. Base them on staffing and the impact of waiting.

If the impact is unclear, ask the person in charge to check before giving the request a lower priority. Change the priority if new facts show a different impact. Your team still owns the user's issue when a vendor is helping.

4. Track each problem until it is resolved

Copy this record for each problem. Use record numbers or links instead of pasting private resident or financial details into an open channel.

• Issue ID / time reported / reporter contact: [Complete]
• Task / who or what is affected / expected and actual result: [Complete]
• Link or note showing the problem: [Record, setting, or walkthrough]
• Request type / current impact / who received it: [Complete]
• Who owns it / time confirmed: [Name; confirmation]
• How to limit harm or use temporary steps: [Action; who approves; end date; records to check and merge]
• Next action / who / by when / next update: [Complete]
• What you checked and found: [Use the gap map if helpful; possible cause and findings]
• What was fixed and how it was tested: [Change and result]
• Who checked it / date / reporter told: [Complete]
• Guide or training update / who will do it: [Current guide and owner]
• Status: [New / Accepted / Investigating / Awaiting dependency / Ready for check / Closed]

“Awaiting dependency” means waiting for a vendor or another task. It still needs an internal owner and a next update. Close the issue only after checking and sharing the result or an agreed resolution. Reopen it if the same failure remains.

Illustrative issue record informed by a turn problem from my experience: A turn-related order was created but does not appear under its turn. Treat impact as unknown until the responsible person checks service, records, and downstream work; raise the priority if a required task or safeguard is affected. Assign the launch support owner to preserve the existing order reference, check its link, and arrange a safe correction with the process owner. The next update goes to the reporter and the person relying on the turn record. Resolution evidence is one valid order under the correct turn, the affected records checked for duplicates, and the task guide revised if the steps were unclear. The roles and response are proposed examples, not a report of how Northpoint resolved the case.

5. Use what you learn to improve the guides

Review open issues, missed updates, repeated questions, and problems that keep happening. Decide what needs a better SOP, work instruction, job aid, practice session, system setting, or process. Some findings may mean changing what launches. Use the gap map to help choose the response.

Before reducing launch support, check that:

• Open issues that could cause harm have a named ongoing owner.
• Normal support has enough people and time for the expected requests.
• Temporary methods have ended or remain under clear rules.
• Guides include what the team learned.
• People know how to get help next.

Reduce support when the team is ready, not just because a date has passed.

Supporting source

• Year One, Episode 5: Property Meld to AppFolio — The Hardest Maintenance Migration — I discuss the recurring help we used and the preparation I had missed before launch. The plan fields, request types, and example response are proposed guidance.