Why do support requests continue after go-live?
At the end of an implementation project, knowledge sits in the consultant’s head and in the project’s emails. Training happens, but when the people who attended leave or someone new joins, the knowledge is gone. The client asks the same questions again and tickets keep arriving after the project is closed.
A written, illustrated handover package lets the client team move on by itself and lets you close the project at a defined point. For a ready skeleton see the customer handover document template.
What belongs in a handover package?
| Section | Content | Format |
|---|---|---|
| Project summary | Scope, what was delivered, what was out of scope | Short text |
| Roles and permissions | Which role can access what, who is admin | Table, RACI |
| Daily tasks | Create a customer, build a quote, enter an order, issue an invoice | Illustrated guides |
| Admin tasks | Add users, change permissions, add a field, take a backup | Illustrated guides |
| Integrations | Connected systems, data flows, what to do on failure | Diagram and short text |
| Known limits | What was deliberately not configured, notes for later versions | Bullet list |
| Support | Whom to contact, through which channel, with what information | Short text |
| Acceptance | Handover checklist and sign-off | List |
How do you prepare the handover guides?
- List the client’s daily tasks. Which role does which task? Base it on what users do, not on what was configured.
- Record one guide per task. Work in the client’s own test or training environment so the guide shows the client’s terms.
- Group admin tasks separately. Steps that ordinary users should not see go into a separate section.
- Remove client data. If records show real customer and employee data, redact it permanently before it goes into the package.
- Review with the client. Try the guides with someone from the client team; where they cannot do the task from the guide is a gap.
- Collect the package under one list. Add the guides as links and PDFs.
- Record acceptance. Tick and date the handover checklist with the client.
Who should update the guides after handover?
This must be settled at handover: one person on the client team becomes the owner and updates the guides when the system or the process changes. If your agreement includes an update service, state it explicitly. Otherwise the guides go stale within months and the client may read that as “the software does not work”. For principles see keeping docs current.
What mistakes are common in handover documentation?
- Describing features. Clients want to do their work, not read a feature list. Write guides by task.
- One very long document. Prefer short guides per task over a manual of hundreds of pages.
- Consultant vocabulary. Write in the words the client uses.
- Leaking data. Screenshots can keep real client records and passwords; check.
- No owner after handover. If nobody is accountable for updates, the package ages.
How do you build ERP and CRM handover guides with Izly?
This is the most direct use for implementation teams: the setup team records every setting and every daily task in the client’s environment once, and the client follows it step by step.
- Use the Chrome extension on the ERP or CRM web interface and do the task. Each click becomes a step with a marked screenshot.
- In the editor use the client’s terms, add tip and warning blocks and order the steps.
- Redact real customer and employee data by hand; redaction permanently replaces the pixels, and shared outputs use only the redacted copies.
- Share the guides by link, or download a PDF and add it to the handover package. The PDF can go in the handover folder.
- Seats are for the people who record. The client team reads the guides as viewers and needs no seats for that.
Izly records only interfaces that run in the browser; if the ERP needs a desktop client, those steps cannot be recorded with Izly. For pricing, see the pricing page.
Frequently asked questions
Should the handover document be a PDF or a link?
Both. A PDF is a fixed copy of the handover moment and stays in the project file; you collect the signature separately. A link shows the current state as guides are updated; prefer the link for day-to-day use.
Can screens with client data go into the handover package?
First try recording in a training environment or with test data. If real data remains, redact it permanently before sharing and check the confidentiality terms in your agreement.
Do guides replace training?
No. Training builds the first understanding; guides let people do the task alone after training and for new joiners. They complement each other.
Who should update the guides after handover?
A named owner on the client team. If you offer an update service as a consultant, write it into the agreement explicitly.
Related pages
Record it once and let the guide write itself
With Izly you do the task once in the browser. Clicks and screenshots become a step-by-step guide that you edit and share by link.