Support is what decides whether the client keeps trusting the system

You open it from the form on this page or through your contracted channel (support email or mobile), and it reaches us with the description, the impact and the evidence. We classify by impact rather than by arrival order, then diagnose and give either a fix or a temporary workaround that keeps work going, then close it once you confirm work is back — and review the cause to prevent recurrence. You can follow its state with the reference number you receive on opening.

We publish no single number for everyone, because the target is set in the service agreement according to the classification and the coverage hours you choose. What we publish here is the method: the impact classification (critical, high, medium, change request), the ticket path, and the channel hours as configured in the system. Every target figure lives in your agreement, and the monthly performance report shows actual times against target — not a marketing page.

No. Support covers the agreed behaviour: a system defect, a usage question, or configuration inside the approved scope. New development, additional reports and changes to processes or permissions are change requests, estimated with their own scope and time — so support hours are not consumed by projects at the expense of system stability.

Yes, subject to an assessment first — because supporting a system we do not know starts with undocumented configuration and unknown risk. So we begin with a short review: configuration and customisations, backup and restore, the modules in use and the connected systems. Then we say plainly: we can support it, we can after fixing specific points, or we advise staying with your current vendor. We will not contract support for a system whose stability we cannot stand behind.

After go-live there is an intensive support period included in the delivery scope (its length is set in the contract), aimed at stabilising daily work. After that, support becomes a separate annual agreement with a defined scope and coverage hours. We say this early during analysis so it is not a surprise at the end of the project — which is why the hypercare period is written plainly in the proposal rather than in a footnote.

New development, additional reports and changes to processes or permissions (estimated as change requests), network, hardware, power and printer failures, correcting manually entered data errors, third-party systems we have no access to, and training new staff (a separate training scope). Writing these boundaries is not a reservation: it is what stops support hours being consumed by projects at the expense of your system’s stability.

We do not guarantee that nothing recurs, but we act to prevent it: every ticket closes with a cause review — if it was configuration we corrected it, if it was a missing alert we added it, and if it was a training question we updated the guide or recommended a short session. And we watch the indicator that matters most: the share of tickets returning for the same cause, which reveals whether we are treating symptoms or the root.