Начните с 3–5 intents: статус заказа, изменение адреса до отгрузки, возврат по стандартной политике, billing question, password reset. Не пытайтесь сразу покрыть весь support taxonomy.
Для каждого intent задайте required data, policy, allowed actions, success condition, escalation triggers и prohibited actions. Это превращает chatbot в управляемый workflow.
FAQ, policy, product docs, troubleshooting, service status. Knowledge должна иметь owner, version и effective date. Агент не должен применять старую refund policy после обновления.
Knowledge объясняет продукт; policy определяет разрешённое решение. Например, статья может описывать возврат, но конкретный refund amount и eligibility задаёт policy layer.
Order, subscription, plan, account status, previous tickets — только по необходимости. Data minimization снижает privacy risk.
До account-specific action агент должен убедиться, что request связан с правильным пользователем. Не раскрывайте детали заказа на основании одного имени.
Статус заказа, resend confirmation, create support ticket. High-risk actions — large refunds, cancellation, identity changes, financial commitments — требуют approval или human handoff.
Maximum refund, maximum number of retries, allowed order states, permitted account fields. Guardrails должны быть deterministic там, где правило чёткое.
Эскалируйте при repeated failure, angry customer, policy exception, vulnerable customer, ambiguous identity, high financial impact или complaint about safety/legal matters.
Human agent получает summary, verified facts, actions already tried, policy applied, sentiment/urgency и recommended next step. Клиент не должен повторять историю с нуля.
Высокий containment может скрывать клиентов, которые сдались. Смотрите resolution, reopen, escalation quality, CSAT и complaint rate.
Обычные, edge cases, conflicting policies, missing data, malicious prompt, angry customer, high-value refund, inaccessible system. Оценка должна проверять и ответ, и action trace.
До production прогоните synthetic и historical conversations. Особенно полезны multi-turn cases, где customer меняет детали или пытается обойти policy.
Email, attached document или message клиента — untrusted input. Они не должны менять internal policy, permissions или instructions агента.
Давайте только systems и actions, нужные конкретным intents. Customer service agent для доставки не должен иметь доступ к finance admin или HR data.
Intent, policy version, source data, tool call, action, escalation и final outcome. Это необходимо для audit, quality improvement и dispute review.
Где action reversible, сохраняйте previous state. Для необратимых действий используйте подтверждение и higher approval threshold.
Policy change должен автоматически trigger review relevant eval cases. Production failures часто возникают не из-за model, а из-за stale knowledge.
Даже при высокой eval score еженедельно проверяйте реальные sessions: random sample + high-risk sample + escalations. Production data выявляет новые edge cases.
Повторяющаяся ошибка должна привести к change policy, knowledge, tool schema, prompt или eval. Не лечите каждую session ручным copy edit.
Cost per resolved contact, agent-hours saved, first-contact resolution, average handling time, CSAT, reopen rate, retention impact. Automation useful только при сохранении customer outcome.
Upsell во время support допустим только после разрешения проблемы и при релевантности. Не используйте agent для aggressive cross-sell в sensitive interaction.
Voice и chat имеют разные latency, interruption и confirmation patterns. Policy и escalation могут быть общими, но conversation design — channel-specific.
E-commerce support получает тысячи вопросов о доставке и возвратах. Agent начинает с order status и стандартной return eligibility. Он видит заказ, применяет актуальную policy, создаёт return label только в разрешённых случаях и эскалирует exceptions. После pilot first-contact resolution растёт, а human agents освобождаются для сложных claims; large refunds остаются approval-gated.
У escalation должны быть явные reasons: policy exception, low confidence, repeated misunderstanding, high-value action, customer request for human. Передача должна происходить один раз с полным контекстом, а не возвращать клиента между bot и человеком.
Создайте tiered authority: agent может автоматически одобрять стандартный refund до лимита и только при verified eligibility; выше лимита — approval. Compensation за service failure должна соответствовать заранее заданной policy, а не импровизации модели.
В voice важны latency, interruption, confirmation и verbal disclosure. Перед необратимым действием agent повторяет ключевые параметры и получает подтверждение. Не переносите chat workflow в voice без адаптации.
Customer feedback и escalation reasons превращайте в knowledge/product backlog. Если один и тот же вопрос повторяется, возможно, нужно улучшить product UX или policy, а не обучать агента отвечать быстрее.
Policy остаётся единой, но language quality и local legal wording нужно проверять отдельно. Evals должны включать реальные языки deployment, а не только английский benchmark.
Начните с небольшой доли low-risk intents, сравнивайте resolution, CSAT, reopen и escalation с контрольной группой. Затем добавляйте intents по одному. Это позволяет локализовать regression.
Экономия = сокращение human handling time и cost per resolved contact. Но вычитайте model/tool cost, quality monitoring и escalation overhead. Дополнительно учитывайте retention impact и complaints.