Zendesk’s September announcement describes Industry Agents for common sector tasks and Custom Agents for workflows unique to a business. The company says administrators can define a job, its systems, actions and points of human approval. That is a more concrete design brief than ‘put a bot on support’. The question for a service team is whether the automated worker can act within a real policy, explain its decisions and hand over a case without forcing the customer to repeat everything.
Specialization changes the unit of design
A generic assistant can answer a question about an order. A service agent may also inspect its status, check a returns policy, calculate eligibility, issue a refund and record the result. Each step has a different consequence. The interface must expose the difference between information, recommendation and irreversible action. It should show which policy or record drove the decision and offer a human route when the customer disputes the outcome.
Zendesk names commerce integrations and industry workflows in its announcement, but an integration list does not guarantee good customer service. The decisive experience occurs at exceptions: mixed orders, partial refunds, damaged items and identity checks. A specialist agent succeeds when it knows both the ordinary path and when that path no longer applies. Designers should study exceptions before drawing the happy-path chat flow.
Policy is part of the product
A refund policy is usually written for employees. An agent turns it into an executable constraint, so ambiguity suddenly becomes visible. Which exceptions are automatic? Who approves a high-value case? What evidence must be logged? If those questions remain unowned, the agent may be precise about a bad rule or inconsistent about a good one. Product design must include the policy editor, review queue and audit history, not just the customer-facing conversation.
Customers also need a comprehensible explanation. ‘The system cannot do that’ is not a service answer. A better response identifies the relevant condition, the next available action and how to reach someone who can review an exceptional case. The explanation should avoid revealing sensitive internal scoring or fraud controls while giving enough context to avoid an opaque rejection.
Handoff quality is the quiet metric
A human escalation is not a failure if it prevents an incorrect action. Measure whether the human receives a concise account of what the customer asked, what the agent checked, what was already promised and where uncertainty remains. If the customer must restate the entire case, the apparent automation rate hides a poor service experience. Time saved by the first agent may simply move to the next person.
Construct test cases around ambiguous evidence and policy boundaries, not only routine successes. In a returns workflow, vary purchase date, item condition, order history and refund route. Verify that the agent asks only necessary questions, cites relevant records internally and records a reason for handoff. Track correction rates and customer effort alongside resolution. A high automated-resolution figure should never be read in isolation.
Keep vendor claims in their lane
Zendesk reports execution volume and some customer outcomes in its announcement. Those figures are vendor-reported examples, not a comparative trial of all service agents. They establish that organizations are using the product; they do not establish the quality of every decision or the distribution of outcomes across industries. A buyer should ask for a test in its own policy environment and a way to inspect misclassifications.
The important shift is architectural: service knowledge becomes structured enough for an agent to apply and a person to review. That opens the possibility of more consistent service, but only if the human organization maintains the knowledge. A stale policy, a missing integration or a silent approval bypass is a product failure regardless of how fluent the agent sounds.
A practical pilot
Pick one contained service request with clear outcomes and an existing human escalation route. Define the actions the agent may perform, the records it may read, and the conditions that require approval. Observe real customer language before writing the system’s prompts. Launch to a small audience and inspect every correction, not just the successful transcripts.
If the pilot works, the next task is maintenance: who updates rules when the business changes, and how do affected cases get re-evaluated? A specialist is useful because it stays close to a job. It becomes dangerous when a polished interface makes old assumptions look authoritative. Good service UX makes both competence and limits visible.
Questions to take into your next review
- Can the customer tell when the agent is informing versus acting?
- Can a reviewer reconstruct why a decision was made?
- Does a human handoff preserve context and avoid repeated questions?