Support models, SLAs and documentation
You will be able to: Design a post-go-live support model; Write an SLA with severities and targets; Write documentation people actually use.
- Read not done yet
- Self-check: not taken not done yet
- Lesson complete not done yet
After hypercare, the client still needs help. Define who supports what before the project ends, or support will be an argument.
Levels of support
| Level | Who | Handles |
|---|---|---|
| 1 | Client's key user or administrator | How-to questions, password resets, simple checks, first look at the Zeyto Support Report |
| 2 | Partner consultant or support desk | Configuration, data corrections through Zeyto's own screens, training, reports |
| 3 | Zeyto | Product faults, missing features, licence issues, anything needing engineering |
On Zeyto, the customer has first-line tools on the Zeyto computer (backup, restore, restart, login reset, Support Report). For level 2 you should prefer a time-limited support window opened by the customer in Diagnostics Bundle and a diagnostics file. Zeyto's own deeper tools, which read or change the database directly, need administrator access to the machine and belong to Zeyto engineers. A partner corrects books through the product's normal documents, adjustments and openings edit, not by changing the database.
A sample SLA
| Severity | Example | First response | Workaround or fix target |
|---|---|---|---|
| 1 Critical | Nobody can sell or post | 1 hour | 4 working hours |
| 2 High | A key function fails with no easy workaround | 4 hours | 2 working days |
| 3 Medium | Function fails but a workaround exists | 1 working day | 5 working days |
| 4 Low | Question or cosmetic issue | 2 working days | Next planned update |
Also state support hours (for example Sunday to Thursday, 09:00 to 18:00), channels, exclusions such as third-party hardware, and how product defects are passed to Zeyto. Price it as a retainer of hours, an annual contract, or time and materials; whichever you choose, put the response targets and the exclusions in writing.
Writing documentation people use
- One purpose per document: a blueprint decides, a configuration workbook records, a runbook says how to operate, a quick reference card helps daily.
- Write for the reader's task: 'Cancel an invoice', not 'Document lifecycle'.
- Use short sentences, the client's own screen names and real examples with figures.
- Number steps and put the expected result after each action.
- Show version number, date, author and who reviewed it. Keep one live copy in a shared folder.
- Test every procedure by having someone who did not write it follow it.
Practise in the demo
- Write a one-page SLA for a 12-user client with four severities and support hours.
- Write the steps for 'Restore the latest backup' as a runbook, with the expected result after each step.
- Open https://demo.zeyto.app/demo-app/ and sign in with the demo login. This is a public demo with sample data, so nothing you do there affects a real business.
Public demo company, sign in as admin / demoAdmin123. Data refreshes nightly.
- Support has three levels: client first line, partner second line, Zeyto third line.
- An SLA sets response and fix targets by severity, hours and exclusions.
- Good documentation has one purpose, task titles, numbered steps and version control.
Check yourself
4 questions on this lesson. Not timed, not the exam, and you can try again. Score 60% or more, and read the lesson, to complete it.