What happens after go-live: support, SLA and the boring parts that matter
The sales conversation ends at go-live. The relationship starts there. Whether the system is still trusted in year two depends on unglamorous things: response times, who owns an escalation, how updates are scheduled, and whether anyone answers on Friday evening.
Read an SLA for three numbers. Reaction time - how long until a human confirms they have your case. Resolution or workaround target, broken down by severity, because a stopped production line and a misaligned report are not the same emergency. And availability, with the maintenance windows excluded from it stated honestly.
Then look at the escalation path. Between "the software has a bug" and "your network blocks the port" there is a zone where a vendor and an IT provider can pass a ticket back and forth for a week. This is the practical argument for buying through a distributor: our first line takes the call, reproduces the problem, and escalates to the vendor's engineers with the diagnostics already attached. You do not arbitrate between suppliers.
Updates are a business process
Agree a release calendar rather than accepting updates whenever they arrive. Major versions go to a test environment first, integrations are re-validated, and nothing ships during quarter close or peak season. Ask the vendor for the roadmap and for the deprecation policy - a feature you depend on being retired with three weeks' notice is a genuine operational risk.
Finally, keep a named system owner on your side and a quarterly review on the calendar: what broke, what the team still does manually, which requests are worth putting to the vendor. Software that is reviewed keeps returning value; software that is merely installed decays.
With Digict LTD, support, updates and the SLA sit in the same contract as the licence - one counterparty for the whole lifecycle, and a team that already knows how your instance is configured because we configured it.
Read the SLA as an operations document
Two numbers get confused constantly: response time and resolution time. A one-hour response guarantee means somebody acknowledges the ticket, not that the problem is fixed. Look for severity definitions, who assigns severity, coverage hours in your timezone, and what a credit is worth when the target is missed. A credit that returns two percent of a monthly fee is not compensation for a day of stopped sales - it is a signal about priorities.
Agree the escalation matrix while everything is calm. Names, phone numbers and the hour at which each level is engaged. Discovering the escalation path during an outage costs the first two hours of it.
Updates without surprises
Releases are where stable systems break. The vendor tests their product; only you can test your configuration.
- 01Release notes, read by someone. A named person reviews what is changing and flags anything that touches your integrations or custom fields.
- 02A staging environment. Critical scenarios rehearsed before the update reaches production, particularly for on-premise systems.
- 03A maintenance window and a rollback. Announced to users, outside peak hours, with a documented way back if the release misbehaves.
Keeping adoption from decaying
Usage erodes quietly. New joiners learn the workarounds of whoever trained them, features added in the last two releases stay unused, and within a year the system is running at half its value. Onboard new hires deliberately, review unused capabilities quarterly, and keep one internal owner whose job includes the system rather than merely tolerating it.
Turn feedback into roadmap. Collect requests in one list, prioritise them once a quarter with the vendor, and tell your team what happened to their suggestions. Nothing sustains adoption like a request that shipped.