Клиент пишет письмо о поврежденном заказе, на следующий день звонит, затем открывает чат, так как никто не знает, что произошло, и ему приходится повторять одну и ту же историю, пока ваша служба поддержки ищет информацию в почте, заметках и разных инструментах. Именно эту проблему решает управление обращениями в Dynamics 365. Представьте обращение как папку с ярлыком в оживленном офисном здании, куда попадает все, что касается проблемы клиента, от первого вопроса до финального ответа. С вами Мирко Питерс из М365FM, и в этом кратком обзоре вы узнаете, как связаны между собой обращения, маршрутизация, сроки ответов, статьи поддержки и закрытие заявок. Что такое обращение в 20 словах? Итак, что же такое обращение? Обращение – это запись об одной проблеме клиента, требующей ответа или решения, будь то поврежденный товар, вопросы по счету, проблемы с входом или запрос на помощь с услугой. Важно отметить, у одного клиента может быть несколько обращений одновременно. Один и тот же клиент может спросить о счете в понедельник, сообщить о поломке устройства во вторник и попросить помощи с изменением адреса в пятницу.

Это разные проблемы, поэтому Dynamics 365 хранит их в отдельных записях, не сваливая все разговоры в одну запутанную переписку. Когда агент создает обращение, он связывает его напрямую с клиентом. Клиентом может быть контакт, то есть отдельное лицо, или учетная запись, то есть компания, в которой этот человек работает. Так, если Джейми из Northwind Traders сообщает о проблеме, обращение может указывать и на Джейми, и на компанию, чтобы любой, кто откроет запись, сразу увидел, кому нужна помощь и к какой организации относится вопрос. Обращение также требует простого описания проблемы, обычно с заголовком вроде «Принтер не работает после обновления по» или «С клиента дважды списали оплату за годовой план, что позволяет быстро просматривать список обращений без открытия каждой записи». Под заголовком агент добавляет детали. Что случилось? Когда это началось? Что клиент уже пробовал делать? С каким продуктом это связано? И является ли это вопросом, запросом или неисправностью? Эти детали превращают размытые сообщения в задачу, которую кто-то может взять на себя и решить? Давайте разберем это подробнее. Обращение может содержать тему, продукт, приоритет и тип обращения. Тема объединяет проблему в категорию, например, оплату или техподдержку, продукт определяет, что использует клиент, приоритет говорит команде, насколько быстро нужно отреагировать, а тип обращения дает еще один способ сортировки задач в процессе поддержки.

Ни одно из этих полей не решает проблему клиента само по себе, но они помогают команде поддержке ясно видеть фронт работ, особенно когда поступают сотни обращений от разных клиентов. Команде, работающей с серьезным сбоем, не следует тратить время на поиск среди общих вопросов. Обращение – это не просто форма, которую заполнили и забыли. Оно становится рабочим журналом для всей истории общения. С обращением можно связать электронные письма, телефонные звонки, а агент может добавить заметки после чата, создать задачу или запись о встрече. Каждое действие привязывается к одной и той же проблеме клиента, поэтому следующему специалисту не нужно восстанавливать историю с нуля. Представьте, что агент начинает работу утром, а после обеда передает обращение профильному специалисту. Без записи обращения специалист может получить лишь короткое сообщение «Эй, посмотришь это?». Этого недостаточно. С записью обращения он видит суть проблемы – данные клиента, детали звонка и то, что первый агент уже проверил. Это обеспечивает гораздо более качественную передачу задачи.

Dynamics 365 поддерживает понятный статус обращения по мере прохождения процесса поддержки. Оно остается активным, пока команда ведет расследование, а когда проблема решена или дан ответ, специалисты закрывают его. Если запрос больше не требует работы, например, поступил по ошибке или клиент отозвал его, команда может отменить обращение. Активно, закрыто и отменено. Эти три состояния дают команде единое представление о статусе каждой проблемы, поэтому никому не нужно гадать, требуется ли еще внимание к обращению. А миниджарам не приходится рассматривать завершенную работу как новую проблему. Одна запись дает вам контроль, а полная история клиента предоставляет агенту контекст. История клиента, стоящая за обращением. Обращение говорит вам, что нужно исправить. Запись о клиенте говорит вам, что привело к этому моменту. Когда агент открывает обращение в Dynamics 365 Customer Service, он может видеть дальше последнего сообщения. Он видит общую картину, ранние обращения, прошлые письма, продукты, привязанные к клиенту и историю его поддержки. Контекст меняет разговор.

Почему контекст важен? Представьте, что клиент сообщает о поломке устройства. Если агент видит только сегодняшние сообщения, он может начать с базовых вопросов. Какая это модель? Когда это началось? Вы пробовали перезагрузить устройство, но клиент уже дважды обращался в поддержку на этой неделе. Первый агент прислал инструкции по устранению неполадок, второй организовал замену детали. Третий агент, видя эту историю, не будет заставлять клиента начинать все сначала. Вместо этого он скажет, я вижу, что вы уже пробовали эти шаги и замена детали не помогла. Давайте попробуем другое решение. Это звучит совсем не так. Как? Можете объяснить проблему еще раз. Это часто называют клиентским обзором на 360 градусов. Название звучит солидно, но все просто. Это означает, что агент видит клиента с разных сторон, а не только через одно отдельное сообщение. Агент видит человека, компанию, предыдущие запросы в поддержку, прошлые диалоги и связанные с ними продукты. Для службы поддержки это заменяет догадки четкой отправной точкой.

Конечно, не каждый клиент получает одинаковый уровень поддержки. Клиент мог приобрести гарантию, его компания может оплачивать фиксированное количество часов поддержки, или у них может быть контракт на определенное число обращений, либо премиальная поддержка с более быстрым ответом. Dynamics 365 очлеживает все это с помощью прав на обслуживание Intitlementos. Право на обслуживание – это соглашение о поддержке клиента внутри системы. Думайте об этом как об условиях обслуживания, привязанных к их учетной записи. Прежде чем агент пообещает выезд инженера или начнет платную работу, он проверяет, какие условия поддержки применимы. Это позволяет избежать неприятных сюрпризов. Например, на неисправный продукт у клиента еще может действовать гарантия. Обращение может быть обработано в рамках этой гарантии. Другой клиент, возможно, уже использовал все свои часы поддержки. Агент видит это до того, как начнет работу вне рамок соглашения. Это также помогает команде поддержки относиться к клиентам справедливо. Агенту не нужно искать старые контракты или обращаться в другой отдел. Условия поддержки находятся вместе с информацией о клиенте прямо там, где их легко найти. А еще есть база знаний. Команды поддержки решают одни и те же проблемы снова и снова. Сброс пароля, инструкции по настройке, известная ошибка после обновления, вопрос по оплате со стандартным ответом. Статья базы знаний хранит такой ответ в одном месте.

Внутри рабочей области обслуживания агент может искать статьи во время работы над обращением. Статья может включать простое объяснение, шаги, скриншот или точный перечень проверок, которые команда должна выполнить. Вместо того, чтобы каждый агент писал свою версию по памяти, они используют общий ответ проверенной командой. Это обеспечивает единообразие поддержки. Это также помогает новым сотрудникам. Им не нужны годы опыта, чтобы успешно решать типичные проблемы, ведь проверенные команды и способы устранения всегда под рукой. Сводки по инцидентам в Капайлот помогают решить другую распространенную проблему, длинную историю обращений. Со временем в одном обращении может накопиться множество электронных писем, заметок и обновлений. На чтение всего этого уходит время, особенно после передачи дела другому сотруднику. Капайлот создает краткую сводку, объединяя название обращения, клиента, тему, продукт, приоритет, тип, описание и недавние действия. Это быстрый инструктаж перед началом работы агента. Агент по-прежнему изучает запись и полагается на свою интуицию, но быстрее вникает в ситуацию. Это очень выручает, когда клиент ждет, а обращение уже сменило несколько исполнителей. Как только агент понимает суть проблемы и потребности клиента, обращение нужно направить нужному специалисту. От приема до распределения в нужную очередь.

Клиент может обратиться за помощью разными способами, по электронной почте, телефону, в чате, в соцсетях или через портал самообслуживания. Каналы меняются, но службе поддержки все равно нужно единое место для управления запросами. Dynamics 365 может создавать обращение на основе таких диалогов, если настроены правила создания записей. Представьте письмо, поступающее на общий адрес поддержки. Вместо того, чтобы ждать в ящике, пока его заметят, правило автоматически превращает это письмо в обращение. Сообщение становится отправной точкой для работы в службе поддержки. Это сокращает объем ручного копирования данных. Тот же принцип применим и к другим подключенным каналам. Команда сама определяет, какие сообщения создают новые обращения, а какие относятся к уже существующему. Ответ на открытый вопрос остается в рамках того же обсуждения, а для нового вопроса создается отдельное обращение. Затем обращению нужно место, где оно будет ждать своего исполнителя. Этим местом часто становится очередь. Очередь — это общий список задач для команды. Это не входящее одного агента, и оно не закреплено за тем, кто первым увидел запрос. Напротив, это место, где вся команда видит задачи, ожидающие внимания. Представьте компанию с отделом биллинга, технической поддержкой и отделом возвратов. У каждой команды своя очередь. Вопросы по оплате идут в биллинг, неисправности, в техподдержку, запросы на возврат, к тем, кто знает процедуру возврата. Звучит просто, потому что так оно и есть. Четкая сортировка избавляет сотрудников от необходимости перекидывать задачи наугад. В этой сортировке помогают правила маршрутизации.

Правило маршрутизации проверяет детали обращения и направляет его в нужную очередь или конкретному человеку. Обращение по конкретному продукту попадает в продуктовую команду. Обращение из определенного региона направляется в локальную поддержку. Серьезная проблема попадает в очередь срочных задач. Общий вопрос ожидает обработки в стандартной команде. Некоторые организации распределяют задачи на основе навыков сотрудников. Например, клиенту, который пишет на французском, нужен агент, говорящий по-французски. Для технической проблемы требуется специалист, обученный работе с конкретным продуктом. Маршрутизация направляет обращение к тому, кто может его решить, вместо того, чтобы обрабатывать все запросы одинаково. Автоматизация помогает, но окончательные решения принимают люди. Руководитель группы может увидеть сложное обращение и назначить его напрямую старшему агенту. Возможно, кто-то из сотрудников уже знаком с клиентом.

Может быть, проблема затрагивает несколько продуктов и требует опыта, который нельзя формализовать правилами. Ручное распределение оставляет команде простор для принятия решений человеком. Ответственный за обращение может меняться в процессе работы. Агенту может потребоваться больше информации, и он вернет обращение в очередь. Команда может обнаружить, что проблема относится к другому отделу, или срочный запрос может потребовать эскалации, если обычная команда не может его решить. Dynamics 365 обеспечивает движение работы, не допуская, чтобы она застряла у одного сотрудника. Иногда одна проблема создает множество обращений. Представьте сбой в программном обеспечении, который затрагивает десятки клиентов. Каждый клиент обращается в поддержку отдельно, поэтому для каждого сообщения нужно создать свое обращение. Но все эти сообщения связаны с одной более масштабной проблемой. Родительское обращение очлеживает общую проблему, а дочерние обращения очлеживают отдельные запросы клиентов в рамках этой проблемы. Это дает службе поддержки два уровня обзора одновременно. Они работают над устранением основного сбоя через родительское обращение, а каждое дочернее обращение помогает информировать нужного клиента.

Когда решение найдено, им не нужно расследовать один и тот же сбой с нуля для каждого позвонившего. Дублирующиеся обращения создают похожую проблему в меньшем масштабе. Клиент может написать на почту и позвонить по одной и той же проблеме, или два агента могут открыть обращение, не заметив работы друг друга. Вместо того, чтобы распылять усилия, команда может объединить похожие обращения. Одно обращение становится основной записью, и работа ведется централизованная. Никто не должен решать одну и ту же проблему дважды. Направление обращения в нужную очередь нужному человеку – это начало работы, и клиент ожидает ответа в обещанные сроки. Выполнение обещаний с помощью SLA и направляемых процессов. Направить обращение нужному человеку – это лишь половина дела, ведь клиент также ожидает помощи в обещанное вами время. И здесь на помощь приходит соглашение об уровне обслуживания, или SLA. SLA привязывает к обращению таймер, поэтому команда точно знает, сколько времени у них есть на выполнение обещания, будь то первичный ответ или полное устранение проблемы. Но здесь важным фактором являются сроки.

Это не всегда один и тот же дедлайн. Возьмем клиента, который ожидает подтверждения в течение одного часа, даже если технической команде нужно два рабочих дня, чтобы найти и протестировать исправление. Dynamics 365 отдельно очлеживает целевые показатели для первого ответа и для решения проблемы, чтобы команда могла действовать оперативно, не обещая мгновенного устранения любого вопроса. Представьте клиента, у которого перестал работать сервис. Он не ждет полного устранения неполадки за 10 минут, но ожидает подтверждения, что проблема принята в работу, хочет знать план действий и получать актуальную информацию. Целевой показатель первого ответа очлеживает первичный контакт, а целевой показатель решения – весь путь до получения ответа или исправления ошибки. Для разных клиентов могут действовать разные обязательства. Компания с премиальной поддержкой получает более короткие целевые сроки ответа, чем клиент с базовым тарифом.

Критический сбой в работе требует меньшего времени на реагирование, чем обычный вопрос «как сделать». Договоры о поддержке, приоритетность и тип обращения определяют применяемые временные регламенты. Это делает обязательства справедливыми и прозрачными. Без SLA сотрудник может начать с самого старого обращения в списке, в то время как срочная задача пропустит свой дедлайн. С SLA экран обращения отображает индикаторы времени, которые подсказывают сотруднику, какое обязательство требует внимания в первую очередь. Так вы увидите, как нарастает напряжение. Обращение, у которого еще много времени, требует работы, но задачу с истекающим сроком ответа нужно решать прямо сейчас. Команды также могут настроить оповещение или этапы эскалации при приближении или истечении срока, чтобы руководитель мог вмешаться, прежде чем клиент начнет разыскивать команду. Временные целевые показатели определяют срочность, а потоки бизнес-процессов – саму работу. Поток бизнес-процесса – это набор этапов, отображаемых внутри обращения. Он дает сотруднику четкий алгоритм действий, основанный на том, как организация должна обрабатывать обращение.

Этапы могут включать путь от приема и расследования до разрешения, с соответствующими вопросами и проверками на каждом шаге. Воспринимайте это как контрольный список, встроенный в процесс. Новому сотруднику не нужно гадать, какие детали важны, прежде чем передать обращение специалисту. Процесс может запрашивать информацию о продукте, типе проблемы, влиянии и другие данные, необходимые следующей команде. Более опытный сотрудник может действовать быстрее, но общий путь все равно помогает команде двигаться в одном направлении. Вот сценарий. Поступает критически важный сбой в обслуживании. Обращение попадает в срочную очередь, и его SLA начинает отсчет времени. Сотрудник подтверждает данные клиента, фиксирует влияние и отправляет первый ответ до истечения целевого срока. Затем поток процесса переводит обращение на этап диагностики, где команда собирает детали ошибки и проверяет связанные отчеты. После этого обращение переходит в стадию решения, когда команда устанавливает причину и готовит обновление для клиента. Эта последовательность также дает руководителям более ясную картину происходящего. Они видят, где процесс замедляется на этапе приема, диагностики или финального ответа клиенту.

Этот рабочий процесс не решает все проблемы команды, но не дает важным шагам затеряться в загруженный день. Dynamics 365 позволяет контролировать, какие изменения статуса доступны агентам в разные моменты. Это называется переходами по причине статуса, звучит технически сложно, но суть проста. Работа по обращению должна проходить через логичные этапы. Нельзя допустить, чтобы кто-то отметил обращение как решенное, пока не пройдена внутренняя проверка или закрыл его без указания причины. Доступные варианты выбора могут меняться по мере развития ситуации. Например, если обращение находится на стадии расследования, агент может приостановить его в ожидании данных от клиента. После ответа клиента агент может вернуть обращение в активную работу. Когда проблема устранена, обращение можно перевести в статус «Решено». Это позволяет вести более четкую историю обращений. Одного ответа недостаточно для завершения работы. Команде необходимо зафиксировать, как разрешилась проблема, а затем правильно закрыть обращение. Решение – накопление опыта и повышение качества обслуживания. Отправка ответа не приводит к автоматическому закрытию обращения. Команде нужно зафиксировать решение, то есть записать, что именно помогло или какой окончательный ответ получил клиент. Это может быть отправка замены устройства, возврат платежа или обновление настроек доступа пользователям. Эта заметка становится частью истории клиента и помогает следующему агенту быстрее вникнуть в суть, если клиент обратится снова спустя месяцы. Иногда первое решение не срабатывает. Возможно, клиент следовал инструкциям, но ошибка возникла снова. Может быть, присланная запчасть не устранила неисправность.

В такой ситуации команда может возобновить обращение или вернуть его в очередь, вместо создания новой записи без истории. Работа над обращением продолжается с того места, где она была прервана. Это особенно важно при смене ответственного. Новый агент видит, что уже пробовал его коллега, что подтвердил клиент и что еще требует проверки. Клиенту не нужно рассказывать все заново только из-за того, что работу принял другой сотрудник. Со временем все эти обращения показывают команде поддержки общую картину, выходящую за рамки одной проблемы. Руководители могут отслеживать время до решения, измеряя длительность пути обращения от открытия до закрытия. Они могут анализировать время на этапах, чтобы видеть, где именно скапливаются обращения. Они также следят за решением при первом контакте, как часто первый специалист может сам закрыть вопрос без перевода на другого. Нагрузка тоже имеет значение. Если одна очередь заполняется каждое утро понедельника, команда это увидит. Если технические обращения днями ожидают внутренние проверки, эта задержка видна в данных. Если команда быстро закрывает обращения, но клиенты их переоткрывают, стоит присмотреться к качеству этих исправлений.

Сами по себе цифры не объясняют всего. Они подсказывают команде, какие вопросы стоит задать. Почему растет число обращений по одному продукту? Почему определенные типы обращений занимают больше времени, чем ожидалось? Почему специалисты постоянно ищут один и тот же ответ, но не находят полезной статьи в базе знаний? Закономерности превращают ежедневную работу поддержки в практический опыт. Рост числа похожих обращений может указывать на дефект продукта. Это может означать, что недавнее обновление запутало клиентов. Это может показать, что руководство пользователя требует уточнения шагов. Вместо того, чтобы считать каждый запрос отдельным, команда может выявить общую причину и устранить ее. Это поможет сократить количество будущих обращений. Отзывы клиентов тоже важны для общей картины. Закрытое обращение может означать, что команда уложилась в сроки, но клиент может быть недоволен, если ему пришлось обращаться трижды.

Анализ истории обращений и отзывов дает руководителям полное представление о качестве обслуживания. Некоторые клиенты предпочли бы вообще не создавать обращения. Здесь на помощь приходит портал самообслуживания. Через портал клиенты могут создавать запросы, проверять статус, добавлять информацию или читать статьи без звонка в поддержку. Для простых вопросов это экономит время каждому. Клиент может проверить статус доставки или пройти руководство по настройке в удобное время. В это время специалисты могут больше внимания уделить вопросам, требующим участия человека, разъяснений или решений. Dynamics 365 Customer Service также интегрируется с привычными инструментами Microsoft в процессе работы с обращениями. Специалист может работать с электронной почтой через Outlook. Команда может обсудить сложный вопрос в Teams. Документы и общая информация могут храниться в SharePoint. Power BI превращает данные в отчеты и панели мониторинга, а инструменты Power Platform помогают настраивать формы, оповещение и автоматизацию процессов. У каждого инструмента своя задача.

Обращение остается тем местом, где проблема и ее история связаны воедино, даже если сотрудники используют другие инструменты для общения и работы. Управление обращениями – это не просто заполнение полей в системе. Это путь к решению проблем клиента, фиксации ответов и обучение команды на основе накопленного опыта. Заключение. Сохраняйте всю историю взаимодействия с клиентом в одном месте. Итак, вот главный вывод. Управление обращениями в Dynamics 365 объединяет проблему, работу, обещание и результат в одной записи. Больше никакого потерянного контекста или повторных исправлений. Взгляните на свой собственный процесс поддержки. О, куда же исчезает информация о клиентах? Именно здесь объединение всех данных меняет все. Подписывайтесь на любимый подкаст-платформе, чтобы получать больше полезных знаний от меня, Мирко Питерса, на m365.fm, где мы простым языком рассказываем о рабочих инструментах Microsoft.