Set AI Chatbot Service Levels Without Impossible Promises

TL;DR

• Build an AI chatbot service level agreement around actions the agency controls: acknowledgement, investigation, containment, communication, and escalation.
• Treat platform availability, assistant availability, correction, and final resolution as separate states. A working widget can still contain a broken booking action or an unsafe answer.
• Classify incidents by customer impact, unsupported-answer risk, broken actions, data or access concerns, and availability.
• Define when each clock starts, pauses, resumes, and ends. Client approval, missing source content, vendor investigation, and third-party restoration are dependencies—not hidden agency delays.
• Fill response and update targets from verified coverage and capacity records. They are agency commitments, not platform guarantees.

A client may hear “available around the clock” and assume every failure will be fixed around the clock. In practice, restoration is a chain: detect or receive, acknowledge, contain, investigate, correct, approve, restore, communicate, and close. Several links may belong to the client, a platform vendor, or a connected system. Client-facing wording can stay simple, but the operating schedule behind it must identify those boundaries or a reassuring promise becomes a dispute waiting to happen.

Key Takeaways

• Availability is not one condition. Test the platform, assistant, content, actions, and human follow-up separately.
• A fast acknowledgement is safer to promise than a fast final resolution because the latter may depend on approval or restoration elsewhere.
• Every dependency needs a named owner, backup, clock state, and evidence trail.
• Wider support hours require sustainable staffing, not stronger proposal language.
• Enhanced support is justified by monitored intake, backup coverage, escalation access, and operating evidence—not by relabeling standard support as “priority.”

Define the Service Promise as Six Separate Commitments

A useful SLA begins with precise nouns. “The chatbot is down” is too vague to classify, own, or close.

1. Platform availability means the underlying vendor service or relevant service area can be reached. It does not prove that a particular client configuration works.
2. Assistant availability means the visitor-facing assistant loads and can respond through the deployed surface.
3. Agency acknowledgement means the agency has recorded receipt, assigned an initial severity and owner, stated any immediate safety action, and named the next update point.
4. Containment reduces present visitor risk without necessarily fixing the cause. Examples include disabling a booking action, narrowing an answer, or directing visitors to a safe contact route.
5. Correction changes the defective configuration, source, rule, integration mapping, or deployment under the agency’s control.
6. Final resolution means the intended visitor path is restored or safely disabled, required approvals are recorded, evidence is retained, and remaining work has an owner.

Consider a visitor who opens the assistant, receives a sensible answer, and cannot complete a booking. The platform may be reachable. The assistant may be available. The booking workflow is still broken. An SLA that calls all three conditions “uptime” cannot describe what the agency can do next.

The governing rule is straightforward: make an unconditional promise only when the agency controls both the start and completion of the promised action. An agency can often control acknowledgement, investigation, a status update, and some forms of containment. It usually cannot unconditionally control client approval, a vendor investigation, or restoration of a third-party calendar.

InsertChat’s status guide separates its web application, API, website assistant widget, and AI processing into distinct service areas. It also says availability can vary by configuration, deployment path, and connected sources. The page was reviewed on July 20, 2026, and explicitly describes itself as a static service guide rather than a live incident feed. Use it to structure an investigation and verify current operational updates at publication—not as an agency uptime guarantee (InsertChat status).

The current Terms of Service should also be checked when the schedule is drafted and again before publication or signature. In the version reviewed on July 20, 2026, customers remain responsible for account access, source content, deployment choices, and legal compliance, while the service is described as provided “as-is” and “as-available” without a warranty of uninterrupted or error-free operation (InsertChat Terms of Service). This framework is an operating model; qualified review is still needed before it becomes contract language or defines remedies.

Build the Severity-and-Ownership Matrix

Severity should follow the consequence, not the loudness of the complaint. Evaluate five dimensions:

• Customer impact: Is one visitor inconvenienced, or is a core journey broadly unusable?
• Unsupported-answer risk: Could the assistant present unapproved pricing, policy, eligibility, safety, financial, legal, or other consequential guidance?
• Broken action: Is a booking, payment, order lookup, lead route, ticket, or handoff failing?
• Data or access concern: Is there unexpected access, exposure, permission behavior, or data movement? Record it as a suspected concern until qualified investigation establishes what happened.
• Availability: Is the platform unreachable, one assistant unavailable, one channel affected, or only one workflow failing?

Use decision rules rather than universal labels. A stale price shown to every visitor may deserve higher urgency than a total outage on an unused test page. A suspected access concern should trigger immediate containment and qualified security escalation without being publicly described as a breach before evidence supports that finding.

Build one editable matrix for every managed account:

InsertChat’s conversation inbox can retain transcripts, page context, source usage, metadata, feedback, handoff status, and resolution states. Those records can support classification and investigation (conversation evidence). Its assistant builder supports source rules, fallback behavior, escalation guidance, review, routing context, workspace roles, and assistant assignments, which can help enforce ownership and containment paths (assistant controls).

Tools do not decide the SLA target. Before inserting a number, examine the agency’s staffed hours, time zone, monitored channels, holiday coverage, primary and backup roster, on-call arrangement, concurrent-incident capacity, and previous incident records. If broader coverage would exceed sustainable capacity, narrow the commitment or treat it as separately scoped enhanced support. For the underlying workload decision, use agency support capacity planning.

Set Clock-Start, Pause, Resume, and Closure Rules

One “resolution clock” hides too much. Track the incident as a sequence of states: opened, acknowledged, containment active, agency investigation active, waiting for client approval, waiting for authoritative content, waiting for vendor, waiting for third party, restored, monitoring, and closed.

Choose one clock-start rule and state it plainly. It may begin when a report reaches an agreed monitored channel, when the agency documents its own detection, or at the earlier of those events. A message sent to an unmonitored personal inbox should not silently trigger a target unless that inbox is named as an intake channel.

The acknowledgement clock ends only when the record includes receipt, initial severity, assigned owner, next update, and any immediate safety action. “We saw your message” is not enough.

Pause rules must identify the exact work that is blocked:

• Missing client approval: Pause publication of corrected content. Continue feasible containment, investigation, and agreed updates.
• Absent authoritative source content: Pause the content correction because the agency should not invent business guidance. Keep the affected answer narrowed, refused, or disabled where feasible.
• Vendor investigation: Mark final restoration as vendor-dependent. The agency still owns the vendor escalation record, client communication, and feasible workarounds.
• Third-party integration failure: Mark restoration as third-party-dependent. The agency can acknowledge, preserve evidence, disable the broken action, or expose an approved fallback, but cannot promise when the external system will recover.

InsertChat integrations can route context into CRM, support, commerce, calendar, webhook, and other owned destinations (integration surfaces). Workflows can invoke those systems and pass contact details, source pages, transcripts, intent, and metadata to them (workflow surfaces). That capability is useful precisely because ownership crosses system boundaries; it does not make every destination an agency-controlled dependency.

Resume a paused correction clock only when the required approval, authoritative content, vendor response, or third-party restoration evidence arrives through the agreed channel. Do not erase the waiting period. Preserve it as a separate duration so later reviews can distinguish agency effort from dependency delay.

Close an incident only when the intended path is restored or safely disabled, tests and evidence are recorded, client confirmation is obtained where required, and unresolved follow-up has been transferred to the appropriate owner. A source correction may create later ongoing chatbot maintenance, but recurring review schedules do not belong inside the incident clock.

Communicate, Record, and Exclude What the Agency Does Not Control

Incident communication should separate observed fact from diagnosis. Use these structures and adapt the bracketed fields to the account’s approved language.

Acknowledgement

We received the report affecting [surface or journey] at [recorded time]. We have classified it as [severity] because [observed impact]. [Owner] is investigating. We have [taken or evaluated immediate safety action]. The next update is due under the agreed cadence.

Status update

The current observed state is [fact]. We have completed [actions and tests]. The incident is now [active investigation or waiting state], owned by [name or party]. Visitor impact remains [impact]. The next update will follow the agreed cadence or arrive sooner if the state changes.

Containment notice

We have temporarily [disabled, narrowed, or rerouted] [affected function] to reduce [specific risk]. This changes the visitor path to [safe alternative]. It is containment, not final correction. Restoration depends on [approval, content, vendor, or third party].

Closure notice

The affected path was [restored or safely disabled] and verified using [test or evidence]. The recorded cause or contributing condition is [supported finding]. [Required approval] is on file. Remaining follow-up has been assigned to [owner or process]. This incident is closed as [resolution state].

The incident record should contain timestamps, affected surface, sample conversation or visible error, observed impact, severity rationale, actions, approvals, vendor case reference, dependency changes, test results, client communications, and closure state. InsertChat’s inbox and handoff capabilities can preserve full conversation context and the prior assistant answer, helping a reviewer see what the visitor actually experienced (conversation records, handoff context).

State exclusions without using them to evade work. Common boundaries include:

• business guidance the client has not documented or approved;
• correction delays caused by missing client sources or approvals;
• requested capabilities or changes outside approved scope;
• outages or restoration work owned by platform vendors or third-party systems.

These exclusions limit responsibility for correction or final resolution. They do not erase agreed duties to acknowledge, communicate, preserve evidence, escalate, or contain harm where the agency can safely do so. An unapproved feature request should be recorded and passed to the account’s change-control process; it should not be disguised as an incident fix.

Apply Three Incidents, Then Choose Standard or Enhanced Support

The following hypothetical application shows how the matrix works. Use your real transcripts, monitoring records, approval history, staffing roster, vendor cases, and integration logs when setting the actual schedule.

Incident 1: A stale pricing answer

The inputs are a visitor transcript, the cited source, the current live pricing page, and the client’s named content approver. The risk is not total availability; it is an unsupported or outdated commercial answer. Severity depends on exposure, consequence, and whether the answer is still being shown.

The agency acknowledges the incident, preserves the transcript, and contains it by narrowing or disabling the affected answer if authorized. It requests approved replacement language from the client content owner and copies the backup. Publication waits for that approval, but communication and feasible containment continue. After approval, the agency updates the source or rule, retests the affected question and close variants, records the result, and closes when the corrected visitor path is verified. The outcome is a contained answer followed by client-approved correction—not a fabricated agency answer.

Incident 2: A booking integration fails

The inputs are the failed conversation, visible error, affected assistant, timeframe, integration logs, and destination-system status. Customer impact and the importance of booking determine severity. The widget loading normally does not reduce the incident to “no outage”; the action is broken.

The agency acknowledges, captures context, and disables the action or presents an approved manual booking route where feasible. The vendor-escalation owner opens a case with the relevant system and records its reference. Updates distinguish agency testing from third-party investigation. Closure requires successful end-to-end booking or an accepted safely disabled path. The outcome is immediate risk reduction with restoration explicitly conditional on the external system.

Incident 3: A high-stakes request waits after correct handoff

The inputs are the transcript, handoff event, routing destination, client staffing record, and escalation roster. The evidence shows that the assistant refused or escalated as designed and preserved context, but the named client owner did not respond.

The agency confirms the handoff behavior, alerts the client operational backup, records the waiting state, and continues the agreed communication cadence. It should not label the event an assistant failure without contrary evidence. Closure occurs when the client accepts the handoff or an approved alternative path is activated. The outcome separates correct assistant behavior from an unresolved client-owned human response.

Choose standard support only when normal staffed coverage, monitored intake, backup ownership, approval paths, and dependency rules can meet the proposed commitments. Choose enhanced support only when broader verified coverage, sustainable on-call capacity, monitored channels, backups, escalation records, and appropriate vendor or enterprise access are actually in place.

Enhanced support is not guaranteed uptime. It is greater agency readiness to acknowledge, contain, communicate, and escalate. If the evidence does not support it, narrow the promise, reserve enhanced support for separate commercial scoping, or require vendor or enterprise review.

The next action is concrete: complete one matrix with the agency’s real operating records, then approve, narrow, or escalate every commitment before it enters a proposal or service agreement.