How we run the service
Service Level Agreement
DKT Digital, St Peter Port, Guernsey GY1 · [email protected]
DRAFT — pending legal review, not binding. This document has not been reviewed by a solicitor. It is published so you can read our terms before you talk to us, and so we can be held to what it says — but it is a working draft, not a vetted contract, and nothing here is legal advice. A binding version will be issued for signature only once it has been through legal review. If you are relying on any part of it, ask us and we will tell you where it stands.
How quickly we respond when something breaks, when you can reach us, what monitoring runs without anyone asking, and — stated rather than hidden — what happens if the one person running your automations is unavailable.
Last updated: 2026-08-01. Owner: Daniel Thomas, DKT Digital (Guernsey).
1. What this covers
This SLA describes how quickly DKT Digital responds when something goes wrong with the automations we run for you, when you can reach us, and — honestly — what happens if the person running your automations is unavailable. It is deliberately specific. A vague SLA is worth nothing when a system is down.
It applies to clients on a live monthly retainer (Starter, Growth, or Scale).
2. Support hours
Standard support window: Monday to Friday, 09:00–17:30 UK/Channel Islands time, excluding Guernsey and England & Wales public holidays.
Outside these hours, monitoring still runs automatically (see §5) and critical alerts still reach the owner, but a response is only guaranteed within the window. A P1 issue raised at 18:00 on a Friday has its response clock start at 09:00 the next working day.
3. Priority levels and response times
"Response" means a human has acknowledged the issue and started work — not that it is already fixed. Fix/resolution times depend on the cause and are given as targets, not guarantees.
| Priority | What it means | Examples | Response target | Resolution target |
|---|---|---|---|---|
| P1 — Critical | A live automation that touches money or customers is fully down or doing the wrong thing. | Invoices not being chased at all; onboarding emails not sending; a client-facing automation sending wrong data. | Within 4 working hours | Same or next working day where the fix is within our control |
| P2 — Major | An automation is degraded or partly failing, with a manual workaround available. | One of several automations failing; reports delayed; a non-critical alert channel down. | Within 1 working day | Within 3 working days |
| P3 — Minor | Cosmetic, low-impact, or a change request. | Wording tweak on a report; a new small automation; a question. | Within 3 working days | By agreement |
How to raise an issue: email [email protected] with the priority in the subject line (for example P1 — invoice chasing stopped). Anything genuinely P1 should also be flagged by the urgent channel agreed with you at onboarding (phone or WhatsApp), because email alone is not guaranteed to be seen out of hours.
4. Escalation path
Buyers treat a missing escalation path as a hidden single point of failure. Here is ours, stated plainly.
- First contact: Daniel Thomas (owner/operator) — email, then the agreed urgent channel.
- If no acknowledgement within the response target: re-send marked "ESCALATION" and use the urgent channel. Automated monitoring will usually have alerted the owner before you do (see §5).
- If the owner is unreachable (see §6): the read-only runbooks come into play, your automations keep running unattended, and your data stays exportable — so you are not left with nothing. A named continuity contact is not yet appointed; §6 is the full and honest account of what that means. This step will name that person once one exists, and not before. (Corrected 2026-08-01: this line previously read "the continuity contact and the read-only runbook come into play", which promised a person who does not exist — in the one section a client reads when something has already gone wrong.)
There is currently one person. §6 is the honest account of what that means and how it is mitigated. We do not pretend there is a 24/7 team.
5. Monitoring — issues are usually caught before you see them
We do not wait for you to report failures. The following run automatically:
- Health watchdog every 10 minutes: checks n8n is alive and processing, that the database volume is mounted, that backups are fresh, and (added 2026-07-20) that the database has not hit a disk-I/O fault. Alerts the owner's phone on any failure.
- Uptime monitor (external, independent of the box): a dead-man's-switch that fires if the automation engine goes silent, catching overnight failures the box itself can't report.
- Per-workflow error handler: one alert per failing automation per hour (deduplicated, so a storm doesn't bury the signal), sent to the owner immediately.
- Free-tier quota monitor (daily): warns before an email/verification quota is hit, so sends don't silently start failing.
This means most P1/P2 issues are detected and often fixed before a client notices. That is a real strength — but monitoring that has never been tested against a real outage is only a hypothesis, which is why we run a documented incident fire-drill (see our internal incident runbook).
6. Continuity — the honest part
**DKT Digital is currently a one-person business. Daniel Thomas is a single point of failure.** Hiding that would fail any serious buyer's diligence; stating it with a mitigation is the honest and stronger position.
What keeps running with no human present:
- Every live automation (they run on a schedule or on triggers, unattended).
- All monitoring and alerting listed in §5.
- Nightly backups, replicated off-site to encrypted cloud storage (Security Overview §5).
- The client portal and website.
So if the owner is unreachable for, say, a week, your automations keep working. What does not happen without a human is: changes, new automations, investigation of a novel failure, and responses to support requests.
What happens if the owner is unreachable for an extended period:
- Continuity contact (to be arranged — a named trusted technical contact): holds sealed access instructions and can, at minimum, stop or pause automations and notify clients. This is not yet in place and is on the critical path — see the note below.
- Read-only runbook (our internal incident runbook, our internal restore runbook): documents how the system is structured, how to restore from backup, and how to reach clients.
- Your data is portable at all times (see Offboarding): even in a worst case, you can take a complete export of your data in standard formats and move to another provider. You are never locked in.
Where this stands today, stated plainly: the continuity contact is not yet appointed. Until it is, the honest position is that your automations keep running unattended, your monitoring keeps running, and your data stays fully exportable at any time — but there is no second person who can make changes on your behalf. We would rather tell you that than let you discover it. This SLA should not be signed as promising a continuity contact until one exists.
7. Service credits (proposal — confirm with solicitor)
If we miss a P1 response target in a given month, a proposed remedy is a service credit of 10% of that month's fee per missed P1 response, capped at one month's fee. This aligns incentives without exposing a small business to uncapped liability. Final wording, caps, and exclusions (e.g. third-party outages outside our control — see §8) are for the solicitor.
8. What is outside this SLA
Response/resolution targets do not apply where the cause is outside our control, including:
- Outages at a third-party sub-processor (e.g. the client's own Xero, a payment provider, an email provider) — we will chase and work around, but cannot guarantee their timing. The full sub-processor list is in Security Overview.
- The client not providing access, credentials, or information needed to resolve an issue.
- Force majeure.
- Free-trial or discovery-audit engagements (no retainer = no SLA).
*Related: Security Overview · Offboarding · Scope & Inclusions · our internal incident runbook · our how-it-works notes.*