How to Define Customer Support Boundaries for WebChat and WhatsApp

Why messaging teams need clear, documented service boundaries

A service boundary states what a support team can complete in a conversation, what it can help with under defined conditions, and what must be handled through another process. It is not simply a list of topics agents should refuse. A good boundary helps the customer understand what will happen next.

Without written boundaries, two operators may give different answers to the same request. Customers may also be asked for information the team does not need, or be sent elsewhere without enough context to act. Documenting the decision and the next step makes responses more consistent across WebChat and WhatsApp.

A boundary is an operational policy, not a feature of the messaging platform. A shared inbox can help teams organize conversations, operators, departments, routing, schedules, service levels, templates and tags; the organization still needs to define what each team is authorized and equipped to do.

• Define the permitted outcome, not just the topic. For example, a team may explain a policy but not approve an exception.
• Name the owner of requests that cannot be completed in the current conversation.
• Write down exceptions, urgency rules and the human escalation route so operators do not have to improvise.

Assess each request using four decision criteria

Use the same four questions for every request before deciding whether to complete it in the conversation. A request may be suitable for messaging in general but still need another route because of its risk, information requirements or the support options available.

Task suitability: Can the work be completed clearly through a back-and-forth exchange, or does it depend on a formal submission, document review, physical action or another process? Separate giving information from making a decision or carrying out an action.

Risk: What could go wrong if the response is mistaken, misunderstood or delayed? Consider financial, safety, privacy, legal or other material consequences relevant to your service. Set stricter boundaries where an error could cause significant harm, and do not ask operators to make decisions beyond their authority.

Information needs: What is the minimum information required to take the next step? If the task needs information that the current conversation is not an approved place to collect, or that cannot be reviewed reliably there, use the organization’s approved process instead. Do not collect extra sensitive details just to make the conversation feel complete.

Available routes: Is there a real, staffed route that can handle the request, and can the customer access it? Identify the responsible team, how to reach it, what information to prepare, and what to do if the preferred route is unavailable. A route that exists only on paper is not a useful next step.

• Ask: Is the task within this team’s authority and capability?
• Ask: Is the risk acceptable for this channel and process?
• Ask: Can we collect and use the necessary information appropriately?
• Ask: Can we name an accessible, available next step and a human owner?

Build a three-outcome service-boundary matrix

Create a short matrix agents can consult quickly. Keep it specific to your service: the examples below describe decision patterns, not universal rules. Confirm the responsible team, permitted actions and approved routes with the people who own the relevant policies.

Complete here: Use this outcome when the request is suitable for messaging, the operator has authority, the necessary information can be handled appropriately, and the risk is acceptable. State what was done and any remaining action or limitation.

Continue with safeguards: Use this outcome when the request can stay in the conversation but needs a defined condition—for example, a narrower answer, a check by an authorized colleague, or a limit on what information is shared. Explain the condition and what the customer can expect next. If the safeguard cannot be met, move to another process.

Use another process: Use this outcome when the task is outside the team’s authority, the information or action requires a different approved process, the risk is too high for the current conversation, or no reliable in-chat completion is possible. Give the customer a concrete route and, where appropriate, connect the request to a named team or human owner.

• For every common request type, record: outcome, reason, authorized action, information allowed, responsible owner and customer-facing next step.
• Mark urgent or potentially harmful situations separately and specify the organization’s human escalation route and response expectations. Do not leave operators to decide urgency without guidance.
• Review ambiguous cases with policy, privacy, security or specialist owners before adding a new rule.

Explain the boundary and make the next step useful

A refusal without a route creates a dead end. A useful boundary message acknowledges the request, briefly explains the limit, and gives a next step the customer can act on. Avoid internal shorthand, blame, vague directions such as “contact the relevant department,” and promises the team cannot keep.

When a customer needs to provide information, say what is needed and why, and explain how to provide it through the approved route. W3C guidance on WCAG Success Criterion 3.3.2 calls for labels or instructions that help users know what information to enter. When an input error is detected and a correction suggestion is known, WCAG Success Criterion 3.3.3 requires providing the suggestion unless doing so would jeopardize security or the content’s purpose.

If the customer cannot use the suggested route, do not simply repeat it. Ask what barrier they are encountering, then follow your documented assisted-support options. Support needs vary; possible routes in service design include phone, in-person help, or, where appropriate, webchat. Offer only options your organization actually provides.

• Acknowledge: “I understand you’re asking us to…”
• Explain: “I can’t complete that change in this conversation because…”
• Give a specific action: “Please submit the request through [approved route] and include [necessary information].”
• Set expectations only when confirmed: identify the team or next step, but do not invent a response time.
• Offer a human route: “If you can’t use that process, tell me what is preventing you and I’ll explain the support options available.”

Keep WebChat and WhatsApp policy consistent without assuming the channels are identical

Start with one policy for the service, then document any channel-specific limits that your team has confirmed. The boundary should not change merely because an operator is responding in WebChat rather than WhatsApp. However, the information that can be collected, the customer’s context and the practical ways to continue may differ, so test the instructions in each channel.

webchat.vip provides a shared inbox for WebChat and WhatsApp conversations. Each WebChat channel also has an installable, customizable and multilingual widget. These capabilities can help teams organize conversations and present guidance, but they do not define which requests your organization should accept or authorize.

Apply WCAG guidance to web content your organization controls, such as its WebChat widget. WCAG covers dynamic content and web on mobile; this does not mean your organization controls WhatsApp’s interface. Keep wording readable on mobile, use clear labels and instructions, and avoid relying on formatting or visual cues alone. Where a process must continue elsewhere, explain the route in the current conversation and avoid making customers repeat information unnecessarily when your procedures allow context to be carried forward.

• Use the same outcome categories and policy rationale across channels.
• Check that links, contact details, instructions and any supported language choices are correct in each channel.
• Do not promise that a customer can complete a task in a channel unless the team has confirmed that route is available and appropriate.
• Treat privacy, consent and security requirements as operating rules; collect only information needed for the defined next step.

Turn the policy into an operator checklist

A short checklist makes the framework usable during live conversations. Keep it close to the team’s guidance and make sure operators know where to ask for help when a case does not fit. A boundary policy should support judgment within clear limits, not encourage agents to guess.

For requests requiring input, specify what is necessary and how the customer should provide it. NIST’s Privacy Framework is a voluntary resource for identifying and managing privacy risk while protecting individuals’ privacy; use your organization’s privacy owners and applicable requirements to define the actual rules for your service.

For technical security controls, do not rely on message wording alone. OWASP’s Application Security Verification Standard provides a basis for testing web-application security controls. Have appropriate technical and security owners determine what controls apply to the systems and processes involved.

• Identify the customer’s intended outcome; do not infer more than the customer has said.
• Check the task against the three-outcome matrix and confirm the operator’s authority.
• Limit questions to information needed for the approved action; explain required inputs in plain language.
• If the case is out of scope or uncertain, state the limit and use the documented route to an authorized human or team.
• Record the reason and outcome using the team’s approved process, without adding unnecessary personal information.
• Confirm that the customer has a usable next step and understands what to do if that route is inaccessible.

Review boundary decisions and fix recurring dead ends

Boundaries need review as customer needs, policies and operating conditions change. Look for repeated requests that agents cannot complete, repeated transfers to the same team, customer comments showing confusion, and conversations that end without a clear resolution or next step. These patterns may indicate a missing route, unclear wording, an outdated rule or a task that should be reassessed—not simply a need to refuse more consistently.

Review examples with frontline operators and the owners of the relevant policy. Confirm that the written rule matches actual authority and available service routes. Test revised wording with users where possible, and check that it remains understandable and consistent from start to finish. GOV.UK service guidance recommends joining up service channels, making services simple to use and improving them throughout their lifetime.

• Track boundary outcomes, unresolved requests, repeated referrals and customer feedback using the operational data your team already collects.
• Sample conversations to check whether agents explain the reason, follow the approved route and avoid collecting unnecessary details.
• When updating a rule, tell affected operators, update templates or guidance, and check whether the new route is actually available.
• Escalate disputed policy, privacy or security questions to the responsible human owner rather than settling them ad hoc in a customer conversation.