Support Policy

1. Purpose and scope

This policy defines what tick9 support covers, what it does not, and where responsibility sits between you (the client), tick9, and the software author or vendor.

This policy relates only to clients with a paid tick9 support contract. It applies once a system is live and handed over from project into support.

It does not replace your contract or statement of work. Where they conflict, the signed agreement takes precedence.

Three parties are involved in any supported system:

2. Support channels and hours

Tickets must be logged through the primary channel to be tracked against SLA. Requests by direct message, text, or call are not tracked and may be missed.

Out-of-hours tickets. If a ticket is received outside support hours, the response clock starts at 09:00 on the next business day. Response targets are measured during business hours only.

3. Priority levels and response targets

Response targets are the time to first meaningful response, not guaranteed resolution times. Resolution depends on cause and, for product bugs, on the vendor.

Priority reclassification. tick9 reserves the right to reclassify a ticket’s priority if the submitted level does not match the definition above. Where tick9 reclassifies a ticket, we will notify the client with a brief explanation. If the client disagrees, they should respond to the ticket within one business day and both parties will discuss to reach a reasonable outcome. tick9’s assessment is applied in the interim.

P1 requirement: the client must have a named contact available to work with tick9 on a P1 issue throughout the response. tick9 cannot be expected to resolve a critical issue without access to the client’s system, data, or decision-makers.

4. Logging a support ticket

To be tracked against SLA, every ticket must include the following:

• Priority level — select the level that best matches the definitions in Section 3.
• System affected — which platform or integration is involved.
• Description — what is happening, what you expected to happen, and when the issue first occurred.
• Steps to reproduce — a brief sequence of actions that causes the issue, where applicable.
• Error messages — copy or screenshot any error text shown.
• Contact — name and best contact details for the person most familiar with the issue.

Tickets that do not include sufficient detail will be triaged as P4 until tick9 can confirm the correct priority. tick9 may ask for further information before the response clock starts.

5. What is included

The following is in scope under a standard support agreement, across all supported platforms unless noted.

• Triage, diagnosis, and root-cause identification of reported issues.
• Configuration changes within the live, agreed scope (see thresholds below).
• Guidance on standard product use (“how do I…”) on a reasonable basis.
• Logging, managing, and chasing vendor support tickets on your behalf.
• Advice on known product issues and workarounds.
• Minor report and template adjustments (up to 30 minutes per task).
• User setup, permission changes, and routine administration where not delegated to the client.

Configuration change threshold — included vs chargeable:

The dividing line is maintaining what exists versus building something new. Any task estimated to exceed 30 minutes, or that involves new design, is a chargeable change request, quoted separately.

6. What is not included

The following is out of scope for support and handled as chargeable consultancy or project work.

• New modules, new features, or new integrations.
• New legal entities, new companies, or new warehouses.
• Data migration, bulk data loads, or bulk data corrections.
• Formal training (beyond incidental answers to how-to questions).
• Issues caused by client changes, third-party systems, or unsupported customisation.
• Product bugs — managed by tick9, fixed by the vendor (see Section 8).
• Recovery of data lost through user error, where vendor tooling cannot restore it.
• Changes to the scope, logic, or behaviour of any custom development.
• Adapting integrations to vendor API changes (see Section 7 — flagged as a known cost risk).

7. tick9 integrations and custom development

This section differs from standard product support. Where tick9 wrote the code, tick9 owns the fix. That makes the warranty and support boundaries critical.

Covers: custom integrations, tick9-built applications, and any .NET or Azure development delivered by tick9.

Vendor API changes — known cost risk. Custom integrations depend on vendor APIs. When a vendor changes their API, the integration can break through no fault of tick9.

8. Vendor escalation and platform incidents

Escalation process. For product bugs and platform faults:

tick9 cannot guarantee resolution times for vendor product bugs. The SLA targets in Section 3 apply to tick9’s response, not to vendor fix times.

Platform-wide incidents. A platform-wide incident is an unplanned event affecting a vendor’s service for multiple customers simultaneously — for example, a Qlik, Cyferd, iplicit or Cin7 outage that is not specific to the client’s account.

When tick9 identifies or is notified of a platform-wide incident:

• SLA response targets for affected tickets are suspended for the duration of the incident.
• tick9 will notify affected clients promptly and provide updates as information is available from the vendor.
• Normal SLA targets resume once the vendor confirms the incident is resolved.

tick9 has no ability to accelerate vendor resolution of platform incidents. The vendor’s own incident response process applies.

9. Client obligations

Clients on a support contract undertake to:

• Log all support requests through the primary channel (support@tick9.co.uk) with sufficient detail as described in Section 4.
• Report issues as soon as reasonably practicable after becoming aware of them.
• Provide tick9 with access to the system, data, and a knowledgeable contact as needed to diagnose and resolve issues.
• Make a named contact available to work alongside tick9 on any P1 issue.
• Ensure that all software, hardware, and third-party services within the client’s control and used alongside tick9-supported systems are properly maintained.
• Not attempt to repair, reconfigure, or alter tick9-built integrations or custom development without prior agreement.
• Co-operate fully with tick9 in the provision of support services.
• Ensure new staff training does not disrupt or compromise existing software platforms.

Where tick9 investigates an issue and finds it is caused by a client action, a third-party system, or circumstances outside tick9’s scope, tick9 reserves the right to charge for the investigation time at the prevailing day rate.

10. Responsibility summary

Platform-specific addenda (iplicit, Cin7 Core, Cyferd) will be produced separately and appended to this general policy for relevant clients.

To log a support ticket or ask about this policy, email support@tick9.co.uk or call 01482 736046.