Клиент начинает чат с простого вопроса о возможности изменить заказ. Такой вопрос можно безопасно обсудить анонимно. Через несколько минут он просит заменить адрес доставки. Теперь разговор затрагивает приватную работу с аккаунтом. Команде нужна надежная личность, но клиент не должен начинать все заново.
В этом и состоит смысл аутентификации в ходе разговора. Открытая форма входа еще ничего не доказывает. Успех означает, что правильный человек подтвержден внутри того же полезного разговора, приватная работа до этого закрыта, а у сбоя есть безопасный выход.
Проверьте границу до кнопки входа
Microsoft указывает общую доступность расширенной аутентификации Dynamics 365 Contact Center в сентябре 2026 года. Обновление добавляет OAuth 2.0 к существующей проверке на основе JWT, согласует способ аутентификации с Copilot Studio и позволяет анонимному клиенту синхронного чата подтвердить личность по запросу представителя или ИИ агента. Microsoft предупреждает, что сроки в плане выпуска могут измениться, поэтому сначала проверьте функцию в нужном клиенте (описание выпуска Microsoft).
- 1Начните безопасноРазрешите общий вопрос без подтверждения личности.
- 2Запросите проверку вовремяТребуйте вход только перед приватной работой с аккаунтом.
- 3Свяжите верную записьПодтвердите только нужную активную запись клиента.
- 4Сохраните разговорНе теряйте текст, владельца и объяснение клиента после входа.
- 5Восстановитесь без утечкиОставляйте приватные данные закрытыми при сбое или истечении.
Опишите границу полномочий. Представитель может рассказать о часах работы или общих правилах возврата, не зная посетителя. Просмотр заказа, смена адреса, обсуждение счета или истории аккаунта должны ждать подтвержденной личности и отдельного разрешения на действие. Аутентификация отвечает на вопрос кто это. Она не разрешает автоматически любую операцию.
Опишите два пути до настройки
Команды часто описывают только успех. Нужны два пути. В первом анонимный клиент входит и продолжает разговор. Во втором токен отсутствует, истек, неверен, пришел слишком поздно или связан не с той активной записью. Именно второй путь не дает заменить контроль импровизированным исключением.
| Ситуация | Ожидаемое состояние | Что разрешено команде | Нужное доказательство |
|---|---|---|---|
| Общий вопрос | Анонимный клиент | Дать публичную информацию | Чат начинается без аккаунта |
| Приватный запрос | Нужна проверка | Объяснить причину входа | Запрос появляется на заданной границе |
| Верная личность | Подтвержденный клиент | Работать в пределах разрешений | Связана правильная активная запись |
| Неверный или истекший токен | Анонимный клиент | Повторить вход или предложить безопасную помощь | Приватные поля закрыты |
| Неоднозначная запись | Не решено | Передать на контролируемую проверку | Запись не угадана и не объединена |
Документация Microsoft говорит, что Dynamics 365 различает анонимных и подтвержденных клиентов и может применять заданные контекстные переменные в правилах. Представитель видит Да или Нет в поле аутентификации сводки разговора. Для собственного портала описаны подписанные требования JWT, проверка открытым ключом и клиентская функция, которая должна вернуть токен за десять секунд. Неверный или истекший токен вызывает событие ошибки (настройки Microsoft).
Сохраните разговор при смене полномочий
После входа клиент не должен повторять исходную проблему. Проверьте сохранение текста, текущего владельца, истории очереди и причины обращения. Затем убедитесь, что привязаны нужный активный контакт или аккаунт. Технически верный токен с неправильной записью означает провал.
Непрерывность важна в веб чате и после передачи. Если разговор попадает в общий инбокс, следующий сотрудник должен видеть подтвержденное состояние и полезный контекст, но не многоразовый токен и не лишние данные личности. Если ИИ помощник предлагает вход, проверьте, что автоматизация останавливается при недоказанной личности, а человек принимает работу явно.
Проверьте сбой раньше успеха
Пройдите случаи истекшего, поврежденного и задержанного токена. В одном тесте отключите поставщика идентификации. Войдите клиентом с неактивной записью. Откройте две вкладки и убедитесь, что состояние одного клиента не переходит в другую сессию. Дайте токену истечь в длинном разговоре и посмотрите, какая работа станет недоступной.
Сбой не оправдывает слабый обход. Представитель может объяснить следующий шаг, сохранить публичную часть разговора, предложить повторный вход или перейти к заранее утвержденной ручной процедуре. Нельзя угадывать клиента по имени, телефону или описанию недавнего заказа.
Разделите личность доступ и маршрутизацию
Контекстные переменные могут направить подтвержденного клиента, но проверяйте решения отдельно. Верна ли связь с записью. Разрешено ли человеку видеть или менять данные. Нужна ли другая очередь. Один успешный сигнал не должен незаметно одобрять все три решения.
Проверьте ролевой доступ сотрудников, которые работают с подтвержденными чатами. Убедитесь, что средства безопасности не допускают токены и лишние поля личности в тексты, выгрузки и обычные представления сотрудников. Также тестируйте анонимный путь, чтобы простой публичный вопрос не упирался в обязательный вход.
Определите доказательства для запуска
Запись о запуске должна содержать проверенные клиент и канал, поставщика идентификации, тестовые аккаунты, срок токена, ожидаемую запись, разрешенные приватные действия, результат маршрутизации, результат сбоя и ответственного владельца. Не сохраняйте рабочие секреты или полные токены. Один тест должен выполнить человек, который не настраивал функцию.
Задайте правило остановки. Не запускайте решение, если можно связать неверную запись, увидеть приватные данные после сбоя, потерять текст, оставить работу без владельца или восстановиться только через случайное исключение.
DripTell не заменяет поставщика идентификации и права Dynamics. Он полезен дальше, когда подтвержденному разговору нужны явный владелец, ограниченная видимость и безопасная передача. Команда внедрения может помочь определить эти доказательства до расширения автоматизации.
Часто задаваемые вопросы
Заменяет ли аутентификация авторизацию
Нет. Она подтверждает личность. Приложение и правила сервиса по прежнему определяют доступные записи и действия.
Нужно ли требовать вход в каждом чате
Нет. Безопасные публичные вопросы могут оставаться анонимными. Просите войти, когда работа касается приватного аккаунта или защищенного действия.
Какой тест сбоя самый важный
Используйте правдоподобную личность, которая связана с неверной или неактивной записью. Система не должна угадывать, объединять или раскрывать данные.
Что делать при неудачной проверке
Оставьте приватную информацию закрытой, сохраните безопасную часть разговора, объясните повторный или ручной путь и назначьте ответственного.
Помочь применить это руководство?Спросить команду DripTell
От чтения к действию
Нужна помощь с применением этого подхода в вашей компании?
Оставьте контакты. Мы учтём материал, который вы читаете, и начнём с полезного ответа для вашей команды.
DripTell Editorial
Практические материалы, проверенные командой продукта и клиентских процессов DripTell.
Узнайте, как DripTell проверяет сведения о продукте, использует первичные источники и исправляет ошибки.
Редакционная политика и источники
