A useful support automation plan assigns a clear owner to each decision: what information is approved, when a request needs customer-specific data, who can make an exception, and who handles requests that need a person. Use the worksheet below to separate those decisions before you configure or expand an automated path. The outcome is a responsibility map, not a promise that every request should be automated.
Classify requests by what they require
Start with the customer's intent, then ask what would be needed to answer correctly. Requests that sound similar can require different evidence or authority. For example, explaining a returns policy is not the same as deciding whether a specific late delivery qualifies for an exception.
Use these categories as a first pass:
| Request type | Illustrative question | What is needed | Initial decision |
|---|---|---|---|
| General information | 'What is your return period?' | An approved, current policy | Answer within the published policy |
| Customer-specific status | 'Where is my order?' | A way to look up the relevant record | Answer only if the required lookup is actually available |
| Decision or exception | 'Can you refund this late order?' | Case details and an authorized decision-maker | Route for human review unless authority is explicitly assigned |
| Missing or unclear information | 'Does this unusual case qualify?' | Information that may not be covered by the approved source | Explain the limit and give the next step |
This classification prevents a common planning mistake: assuming that having information about a policy means the Agent can check an individual case or make a decision about it. Keep information access, record lookup, and decision authority as separate questions.
Fill in the responsibility worksheet
For each request type, write down the evidence, the owner who approves it, the Agent's permitted role, and the next step if the request falls outside the boundary. The example below is fictional and is only a worksheet illustration, not a report of a customer setup or outcome.
| Request | Evidence needed | Owner who approves the boundary | Agent's role | Route when the boundary is reached |
|---|---|---|---|---|
| Explain standard returns | Current returns policy | Policy owner | Summarize the approved terms | Human review for exceptions |
| Check delivery status | Current order record | Data or integration owner | Provide status only if the lookup is configured and returns the relevant record | Direct the customer to the approved support route |
| Decide whether to refund a late delivery | Case facts plus refund authority | Support or policy decision-maker | Explain the general policy, not approve the exception | Send the case to an authorized person |
Name a specific role or person for each owner field. 'Support team' can be too broad if no one knows who approves policy changes or who investigates a failed lookup. If one person holds multiple responsibilities, record each responsibility separately so you can still tell whether the right kind of approval was given.
Separate approved information from customer-specific data
For general answers, list the exact source the business approves and who maintains it. Keep a record of its review trigger, such as a policy change or a discovered contradiction. These are suggested operating practices; choose triggers that match the way your business updates its information.
For customer-specific answers, document the source of the record, who is responsible for the connection, what the Agent may retrieve, and what should happen if the information is missing. Do not treat a website chat installation as a connection to business records. If your process relies on a database, state what the connector does and does not establish: The database connector supports PostgreSQL and MySQL with a validated read-only SELECT query. A synced knowledge dataset is not proof of a live database lookup for each visitor question.
A document also needs a readiness check before you rely on it. A source must finish processing before its content can be used in answers. Confirm processing is complete, then compare sample questions with the approved source. See the knowledge base overview. For a focused way to think through covered and uncovered questions, see what your Agent should say when knowledge has no answer.
Assign decision rights, not just workflow tasks
Decide who has authority to approve an exception before designing the conversation around it. For each decision, write down:
- Who sets the rule? Identify the owner who approves the policy or eligibility criteria.
- Who can approve an exception? Name the role with authority to decide unusual cases.
- What may the Agent state? Specify whether it can explain the standard rule, gather details, or do something else that your process explicitly permits.
- What is the handoff trigger? Describe the condition in plain language, such as a disputed charge or a request outside the written policy.
- What should the customer hear next? Provide a clear route without promising a response time the business has not committed to.
As practical advice, put these answers in a separate operating document your owners maintain. Revisit the boundary when a policy or approval process changes. Avoid vague instructions such as 'handle refund requests' if that could mean either explaining a policy or authorizing money to be returned.
Make handover an owned responsibility
For every route to a person, assign someone to monitor and continue the conversation. Also decide what the customer should be told while waiting and what information the human needs to make the next decision. A handover path is useful only if your team understands who receives the request and what they are expected to do.
Authorized Workspace members can take over a conversation and reply as a human. Waiting or human-takeover conversations do not receive an AI response from the widget. Human handover is a route for help, not a response-time guarantee. Plan coverage and customer wording around your own support capacity. See the human handover overview. This worksheet assigns the responsibility behind the support route.
Use a change record for ownership-sensitive edits
When a request changes an Agent's tone or personality, identify the exact field before deciding whether the change is pending or already active. Knowledge sources, the Agent name, booking links, notification recipients and model-context personality traits, response style or language are live settings and take effect immediately. Tone or personality wording inside the Agent's draft instructions waits for Publish, but changing model-context traits, response style or language does not. A request to change tone can affect either field, so only the exact changed field determines whether it is draft or live. Owners must check the saved field before assuming customers cannot see a change.
As an operating practice, record the field changed, the responsible approver, and whether the change is draft or live. Do not label a change 'draft' just because it concerns tone. Check the saved field, then follow the appropriate review or publishing step.
Review the map before widening scope
Treat the worksheet as a decision gate whenever you add a request category or change who can approve an outcome. Before expanding, ask whether each row has an approved information source, a named owner, a defined limit on the Agent's role, and a usable next step. If any answer is missing, keep that category out of scope until the responsible people decide how it should work.
For a practical review, bring together the policy owner, the person responsible for any data connection, and the person who manages human support. Ask each to confirm only the boundary they own. That keeps approval specific: the person who maintains a policy need not be the person who controls access to order records or decides refund exceptions.
Audit decisions and update owners
Choose a review interval that fits the pace of changes in your business. As advice, use a short log rather than relying on memory. For each issue you find, record the request category, what boundary failed or was unclear, who owns the correction, and the next action.
| Review question | What to write down | Owner to involve |
|---|---|---|
| Was the answer supported by approved material? | Source and any missing or conflicting information | Knowledge or policy owner |
| Did the request need a personal record? | Whether the intended lookup was available | Data or integration owner |
| Did someone need to decide an exception? | Decision needed and authorized role | Policy or support decision-maker |
| Did the customer reach the right person? | Route, owner, and any unclear customer instruction | Support lead |
| Did a setting or boundary change? | Exact field or rule, approver, and saved state | Change approver |
Close each review by deciding whether to keep the current boundary, clarify the approved source, verify a data requirement, change the route, or assign a missing decision owner. The useful result is an updated responsibility map that makes clear who can answer, who can decide, and who must help when automation reaches its limit.
Complete one responsibility row
For a fictional subscription company, the row can read: request, “cancel without owner access”; source owner, support operations; decision owner, account recovery team; Agent action, explain the verification route; forbidden action, claim cancellation; receiving owner, monitored support inbox; acceptance evidence, visitor and operator transcript.
This row prevents a well-written policy answer from becoming an unauthorized account decision. Implement it with the support deployment sequence and human handover guide. Use AI versus live chat to assign the remaining request types.