A morning when nobody knew what was happening
Your product stopped working at half past nine on a Tuesday. The cause was a failing database upgrade, fixed by eleven. For the firms using it, the experience was worse than the downtime. Fee earners saw errors and rang their IT help desk. The IT help desk emailed your support address and heard nothing for an hour, because your two engineers were fixing the problem and nobody was assigned to communicate. One firm's IT director rang your founder's mobile.
A week later, the same IT director asks for a written incident report for their risk register. You do not have one, and piecing together what happened takes a day.
Why incidents go badly for small legal tech teams
Law firms' IT teams run formal incident and supplier management processes. They are accountable to partners and sometimes to clients for the availability of systems fee earners depend on. They expect suppliers to behave the same way.
- Monitoring watches servers, not what users experience, so users notice first.
- Nobody is named to communicate during an incident; everyone is fixing.
- There is no status page, so firms rely on emails and phone calls.
- Updates are irregular and technical, not useful to an IT director briefing partners.
- No written report follows, so the firm's records have a gap.
What poor incident handling costs
Downtime is sometimes unavoidable, and firms understand that. Silence is harder to forgive. An IT director who had nothing to tell partners during an outage will remember your product as unreliable, and will say so during contract review and in conversations with peers. Firms whose supplier management processes require incident reports will record the gap. And every incident without a written review is a missed chance to stop it happening again.
The timing of legal work makes this sharper. An outage on a completion day, during a trial, or in the hours before a filing deadline lands on fee earners who have no slack at all. They need to know straight away whether to wait or switch to a fallback, and that decision depends on hearing something useful from you, not on reading error messages.
How we build incident handling firms respect
What we build combines the monitoring, communication and records that firms expect from a supplier.
- User-journey monitoring: automated checks that sign in, open a matter, upload a document and run a core feature, from outside your system, alerting before users call.
- An incident process with severity levels, a named incident lead who fixes and a named communicator who updates, even in a small team.
- A status page showing current state and history, with subscriptions for each firm's IT contacts.
- Firm-specific notifications for incidents that affect particular firms, such as a failing integration with their document management system.
- Update templates written for IT directors: what is affected, what users should do, when the next update will come.
- A post-incident report template covering timeline, cause, impact, fix and what changes to prevent recurrence, sent to affected firms after each significant incident.
| Stage | What firms receive |
|---|---|
| Problem detected | Status page update, notification to subscribed IT contacts |
| During the incident | Regular updates in plain language |
| Resolved | Confirmation and any action users should take |
| After significant incidents | Written post-incident report |
| Firm-specific issue | Direct notification to that firm's IT team |
We do not promise uptime figures on your behalf. What you commit to in contracts is your decision; what we build helps you meet it and show what happened when you did not.
The next incident
A third-party service your product depends on slows down on a Thursday morning. The user-journey checks notice uploads failing before any fee earner does. Your engineer takes the lead on the fix, and your customer success manager posts to the status page and sends the first update to subscribed IT contacts. Updates follow at the intervals promised in the first message. The IT directors pass them to their help desks. The following week, affected firms receive a post-incident report, and two file it in their supplier records without asking a single question.
Would an outage go badly today?
- Users usually notice problems before your monitoring does.
- You have no status page.
- Nobody is named to communicate during an incident.
- Firms have asked for incident reports you could not provide.
- Incidents are fixed but never written up.