Service Commitment

Service Level Agreement

The commitments AuthoritySpecialist SEO Solutions OÜ makes on responsiveness, availability and delivery — and how we hold ourselves accountable to them.

First-response targets

We commit to a first human response within these targets, by severity:

SeverityFirst response
Critical — service down / billing blocker4 business hours
High — major feature broken1 business day
Normal — standard request2 business days
Low — question / minor3 business days

Availability & delivery

  • Uptime target: 99.9% monthly availability of the client dashboard.
  • Delivery cadence: weekly progress visible in your Performance Hub.
  • Support hours: business days, with critical issues monitored continuously.
  • Compliance commitment: at least 95% of tickets meet their first-response target.

Accountability

We don't just promise these targets — we measure them. Your workspace shows live first-response compliance against this SLA, computed from your actual support history, so you can see we are meeting our commitments rather than take our word for it.

Escalation

If a target is missed, escalate to support@authorityspecialist.com with your workspace and ticket reference. Enterprise customers have a named contact and escalation path defined in their Order Form.

Evaluate the commitment in context

Read the SLA by scope, trigger, impact, evidence, and governing terms

Use the service level page as an operational reference, then compare it with the executed agreement, order form, and incorporated schedules that apply to the engagement. Before deciding that a commitment applies, identify the covered service, customer workspace, approved support channel, measurement period, business-hours rule, and stated exclusions. Check whether the language describes a service objective, a response target, a restoration expectation, or a contractual remedy, because those concepts can be governed differently and should not be treated as interchangeable.

Evaluate severity from the documented definition and the impact that can be shown at the time of the incident. Capture when the issue began, when it was submitted through the supported reporting channel, which users or functions were affected, whether a workaround existed, and what evidence supports the reported scope. Keep the ticket reference, relevant timestamps, status information, material replies, and actions already attempted together in a single incident record. A shared record gives both sides a consistent basis for determining classification and timing without relying on recollection or scattered messages.

Escalate when the documented path calls for additional ownership, review, or a decision about an apparently missed commitment. Reference the customer workspace and existing ticket, summarize the current impact, identify the commitment you believe is relevant, and note the response already received. Avoid creating duplicate incident reports unless the service team directs you to do so, since separate records can split the evidence and timeline. After the incident is resolved, reconcile the final severity, the applicable timing calculation, any exclusions that were applied, the corrective action communicated, and any remedy that the governing terms actually provide.

SLA questions

How to interpret and document a service-level commitment

What should I rely on if the public SLA page differs from my agreement?
Use the executed agreement, order form, and incorporated schedules that govern the specific engagement. The public service page can explain operating commitments, but it does not replace customer-specific terms, exclusions, or remedies.
How do I determine when the applicable response clock starts?
Follow the trigger stated in the relevant commitment, including the supported reporting channel, any business-hours rule, and any identifying information the report must contain. A message sent elsewhere or a report missing required context may not establish the same start point.
How should I choose the incident severity?
Compare the documented severity definition with the current functional and customer impact. Record affected users, blocked functions, available workarounds, scope, and supporting evidence instead of selecting a level from urgency or frustration alone.
What should I include when I escalate an incident?
Include the customer workspace and ticket references, a concise impact summary, relevant timestamps, error or status evidence, actions already attempted, replies received, and the commitment you believe applies. Leave out secrets and personal data that are not necessary to assess the issue.
If the first response target is met, does that mean the incident is resolved?
No. First response, investigation updates, restoration, resolution, and any contractual remedy are separate events unless the governing terms expressly combine them. Keep the incident timeline clear and record the next expected update or decision.