WEBVTT

00:00:00.000 --> 00:00:03.800
Клиент пишет письмо о поврежденном заказе, на следующий день звонит, затем открывает чат,

00:00:03.900 --> 00:00:07.320
так как никто не знает, что произошло, и ему приходится повторять одну и ту же историю,

00:00:07.500 --> 00:00:11.080
пока ваша служба поддержки ищет информацию в почте, заметках и разных инструментах.

00:00:11.180 --> 00:00:16.500
Именно эту проблему решает управление обращениями в Dynamics 365. Представьте обращение как папку

00:00:16.500 --> 00:00:20.540
с ярлыком в оживленном офисном здании, куда попадает все, что касается проблемы клиента,

00:00:20.720 --> 00:00:25.760
от первого вопроса до финального ответа. С вами Мирко Питерс из М365FM, и в этом кратком

00:00:25.760 --> 00:00:30.060
обзоре вы узнаете, как связаны между собой обращения, маршрутизация, сроки ответов,

00:00:30.220 --> 00:00:34.080
статьи поддержки и закрытие заявок. Что такое обращение в 20 словах?

00:00:34.220 --> 00:00:38.660
Итак, что же такое обращение? Обращение – это запись об одной проблеме клиента,

00:00:38.860 --> 00:00:42.660
требующей ответа или решения, будь то поврежденный товар, вопросы по счету,

00:00:42.900 --> 00:00:47.380
проблемы с входом или запрос на помощь с услугой. Важно отметить, у одного клиента может быть

00:00:47.380 --> 00:00:51.240
несколько обращений одновременно. Один и тот же клиент может спросить о счете в понедельник,

00:00:51.400 --> 00:00:54.940
сообщить о поломке устройства во вторник и попросить помощи с изменением адреса в пятницу.

00:00:54.940 --> 00:00:59.220
Это разные проблемы, поэтому Dynamics 365 хранит их в отдельных записях,

00:00:59.300 --> 00:01:03.200
не сваливая все разговоры в одну запутанную переписку. Когда агент создает обращение,

00:01:03.400 --> 00:01:07.500
он связывает его напрямую с клиентом. Клиентом может быть контакт, то есть отдельное лицо,

00:01:07.700 --> 00:01:10.960
или учетная запись, то есть компания, в которой этот человек работает. Так,

00:01:11.120 --> 00:01:15.100
если Джейми из Northwind Traders сообщает о проблеме, обращение может указывать и на Джейми,

00:01:15.240 --> 00:01:19.220
и на компанию, чтобы любой, кто откроет запись, сразу увидел, кому нужна помощь и к какой

00:01:19.220 --> 00:01:23.580
организации относится вопрос. Обращение также требует простого описания проблемы,

00:01:23.580 --> 00:01:28.980
обычно с заголовком вроде «Принтер не работает после обновления по» или «С клиента дважды

00:01:28.980 --> 00:01:34.320
списали оплату за годовой план, что позволяет быстро просматривать список обращений без открытия

00:01:34.320 --> 00:01:39.560
каждой записи». Под заголовком агент добавляет детали. Что случилось? Когда это началось? Что

00:01:39.560 --> 00:01:44.280
клиент уже пробовал делать? С каким продуктом это связано? И является ли это вопросом, запросом или

00:01:44.280 --> 00:01:48.400
неисправностью? Эти детали превращают размытые сообщения в задачу, которую кто-то может взять на себя

00:01:48.400 --> 00:01:52.640
и решить? Давайте разберем это подробнее. Обращение может содержать тему, продукт,

00:01:52.780 --> 00:01:57.920
приоритет и тип обращения. Тема объединяет проблему в категорию, например, оплату или техподдержку,

00:01:58.080 --> 00:02:02.380
продукт определяет, что использует клиент, приоритет говорит команде, насколько быстро нужно

00:02:02.380 --> 00:02:06.960
отреагировать, а тип обращения дает еще один способ сортировки задач в процессе поддержки.

00:02:07.120 --> 00:02:11.840
Ни одно из этих полей не решает проблему клиента само по себе, но они помогают команде поддержке

00:02:11.840 --> 00:02:16.020
ясно видеть фронт работ, особенно когда поступают сотни обращений от разных клиентов.

00:02:16.020 --> 00:02:21.260
Команде, работающей с серьезным сбоем, не следует тратить время на поиск среди общих вопросов.

00:02:21.380 --> 00:02:26.520
Обращение – это не просто форма, которую заполнили и забыли. Оно становится рабочим журналом

00:02:26.520 --> 00:02:31.200
для всей истории общения. С обращением можно связать электронные письма, телефонные звонки,

00:02:31.400 --> 00:02:35.600
а агент может добавить заметки после чата, создать задачу или запись о встрече.

00:02:35.700 --> 00:02:40.340
Каждое действие привязывается к одной и той же проблеме клиента, поэтому следующему специалисту

00:02:40.340 --> 00:02:44.520
не нужно восстанавливать историю с нуля. Представьте, что агент начинает работу утром,

00:02:44.520 --> 00:02:49.160
а после обеда передает обращение профильному специалисту. Без записи обращения специалист

00:02:49.160 --> 00:02:54.420
может получить лишь короткое сообщение «Эй, посмотришь это?». Этого недостаточно. С записью

00:02:54.420 --> 00:02:59.420
обращения он видит суть проблемы – данные клиента, детали звонка и то, что первый агент уже

00:02:59.420 --> 00:03:02.660
проверил. Это обеспечивает гораздо более качественную передачу задачи.

00:03:02.800 --> 00:03:07.380
Dynamics 365 поддерживает понятный статус обращения по мере прохождения процесса поддержки.

00:03:07.540 --> 00:03:11.980
Оно остается активным, пока команда ведет расследование, а когда проблема решена или дан ответ,

00:03:11.980 --> 00:03:16.820
специалисты закрывают его. Если запрос больше не требует работы, например, поступил по ошибке

00:03:16.820 --> 00:03:21.780
или клиент отозвал его, команда может отменить обращение. Активно, закрыто и отменено.

00:03:22.160 --> 00:03:26.820
Эти три состояния дают команде единое представление о статусе каждой проблемы,

00:03:27.120 --> 00:03:32.660
поэтому никому не нужно гадать, требуется ли еще внимание к обращению. А миниджарам не приходится

00:03:32.660 --> 00:03:37.300
рассматривать завершенную работу как новую проблему. Одна запись дает вам контроль,

00:03:37.300 --> 00:03:42.860
а полная история клиента предоставляет агенту контекст. История клиента, стоящая за обращением.

00:03:43.060 --> 00:03:47.500
Обращение говорит вам, что нужно исправить. Запись о клиенте говорит вам, что привело к этому

00:03:47.500 --> 00:03:52.460
моменту. Когда агент открывает обращение в Dynamics 365 Customer Service, он может видеть дальше

00:03:52.460 --> 00:03:57.220
последнего сообщения. Он видит общую картину, ранние обращения, прошлые письма, продукты,

00:03:57.400 --> 00:04:01.120
привязанные к клиенту и историю его поддержки. Контекст меняет разговор.

00:04:01.260 --> 00:04:05.280
Почему контекст важен? Представьте, что клиент сообщает о поломке устройства.

00:04:05.280 --> 00:04:09.240
Если агент видит только сегодняшние сообщения, он может начать с базовых вопросов.

00:04:09.300 --> 00:04:12.900
Какая это модель? Когда это началось? Вы пробовали перезагрузить устройство,

00:04:13.020 --> 00:04:16.840
но клиент уже дважды обращался в поддержку на этой неделе. Первый агент прислал инструкции

00:04:16.840 --> 00:04:20.780
по устранению неполадок, второй организовал замену детали. Третий агент, видя эту историю,

00:04:20.960 --> 00:04:24.400
не будет заставлять клиента начинать все сначала. Вместо этого он скажет, я вижу,

00:04:24.620 --> 00:04:28.680
что вы уже пробовали эти шаги и замена детали не помогла. Давайте попробуем другое решение.

00:04:28.860 --> 00:04:32.860
Это звучит совсем не так. Как? Можете объяснить проблему еще раз. Это часто называют

00:04:32.860 --> 00:04:37.780
клиентским обзором на 360 градусов. Название звучит солидно, но все просто. Это означает,

00:04:37.980 --> 00:04:41.500
что агент видит клиента с разных сторон, а не только через одно отдельное сообщение.

00:04:41.720 --> 00:04:46.640
Агент видит человека, компанию, предыдущие запросы в поддержку, прошлые диалоги и связанные

00:04:46.640 --> 00:04:50.660
с ними продукты. Для службы поддержки это заменяет догадки четкой отправной точкой.

00:04:50.800 --> 00:04:55.280
Конечно, не каждый клиент получает одинаковый уровень поддержки. Клиент мог приобрести гарантию,

00:04:55.380 --> 00:04:58.260
его компания может оплачивать фиксированное количество часов поддержки,

00:04:58.260 --> 00:05:02.300
или у них может быть контракт на определенное число обращений, либо премиальная поддержка с более

00:05:02.300 --> 00:05:06.840
быстрым ответом. Dynamics 365 очлеживает все это с помощью прав на обслуживание Intitlementos.

00:05:06.980 --> 00:05:11.220
Право на обслуживание – это соглашение о поддержке клиента внутри системы. Думайте об этом как

00:05:11.220 --> 00:05:14.980
об условиях обслуживания, привязанных к их учетной записи. Прежде чем агент пообещает выезд

00:05:14.980 --> 00:05:19.380
инженера или начнет платную работу, он проверяет, какие условия поддержки применимы. Это позволяет

00:05:19.380 --> 00:05:23.280
избежать неприятных сюрпризов. Например, на неисправный продукт у клиента еще может действовать

00:05:23.280 --> 00:05:26.880
гарантия. Обращение может быть обработано в рамках этой гарантии. Другой клиент, возможно,

00:05:26.880 --> 00:05:30.720
уже использовал все свои часы поддержки. Агент видит это до того, как начнет работу вне рамок

00:05:30.720 --> 00:05:34.740
соглашения. Это также помогает команде поддержки относиться к клиентам справедливо. Агенту не нужно

00:05:34.740 --> 00:05:38.560
искать старые контракты или обращаться в другой отдел. Условия поддержки находятся вместе с

00:05:38.560 --> 00:05:42.860
информацией о клиенте прямо там, где их легко найти. А еще есть база знаний. Команды поддержки

00:05:42.860 --> 00:05:47.460
решают одни и те же проблемы снова и снова. Сброс пароля, инструкции по настройке, известная ошибка

00:05:47.460 --> 00:05:52.360
после обновления, вопрос по оплате со стандартным ответом. Статья базы знаний хранит такой ответ в одном месте.

00:05:52.580 --> 00:05:56.320
Внутри рабочей области обслуживания агент может искать статьи во время работы над обращением.

00:05:56.320 --> 00:06:00.580
Статья может включать простое объяснение, шаги, скриншот или точный перечень проверок,

00:06:00.700 --> 00:06:04.700
которые команда должна выполнить. Вместо того, чтобы каждый агент писал свою версию по памяти,

00:06:04.940 --> 00:06:08.900
они используют общий ответ проверенной командой. Это обеспечивает единообразие поддержки.

00:06:09.060 --> 00:06:12.760
Это также помогает новым сотрудникам. Им не нужны годы опыта, чтобы успешно решать

00:06:12.760 --> 00:06:16.200
типичные проблемы, ведь проверенные команды и способы устранения всегда под рукой.

00:06:16.340 --> 00:06:19.000
Сводки по инцидентам в Капайлот помогают решить другую распространенную проблему,

00:06:19.180 --> 00:06:22.500
длинную историю обращений. Со временем в одном обращении может накопиться множество электронных писем,

00:06:22.500 --> 00:06:26.020
заметок и обновлений. На чтение всего этого уходит время, особенно после передачи дела другому

00:06:26.020 --> 00:06:30.060
сотруднику. Капайлот создает краткую сводку, объединяя название обращения, клиента,

00:06:30.280 --> 00:06:34.800
тему, продукт, приоритет, тип, описание и недавние действия. Это быстрый инструктаж перед

00:06:34.800 --> 00:06:38.860
началом работы агента. Агент по-прежнему изучает запись и полагается на свою интуицию,

00:06:39.060 --> 00:06:43.660
но быстрее вникает в ситуацию. Это очень выручает, когда клиент ждет, а обращение уже сменило

00:06:43.660 --> 00:06:47.460
несколько исполнителей. Как только агент понимает суть проблемы и потребности клиента,

00:06:47.460 --> 00:06:52.340
обращение нужно направить нужному специалисту. От приема до распределения в нужную очередь.

00:06:52.480 --> 00:06:55.720
Клиент может обратиться за помощью разными способами, по электронной почте, телефону,

00:06:55.800 --> 00:07:00.200
в чате, в соцсетях или через портал самообслуживания. Каналы меняются, но службе поддержки все равно

00:07:00.200 --> 00:07:05.240
нужно единое место для управления запросами. Dynamics 365 может создавать обращение на основе

00:07:05.240 --> 00:07:10.100
таких диалогов, если настроены правила создания записей. Представьте письмо, поступающее на общий

00:07:10.100 --> 00:07:14.640
адрес поддержки. Вместо того, чтобы ждать в ящике, пока его заметят, правило автоматически превращает

00:07:14.640 --> 00:07:18.400
это письмо в обращение. Сообщение становится отправной точкой для работы в службе поддержки.

00:07:18.560 --> 00:07:22.640
Это сокращает объем ручного копирования данных. Тот же принцип применим и к другим подключенным

00:07:22.640 --> 00:07:26.500
каналам. Команда сама определяет, какие сообщения создают новые обращения, а какие относятся к

00:07:26.500 --> 00:07:30.080
уже существующему. Ответ на открытый вопрос остается в рамках того же обсуждения, а для нового

00:07:30.080 --> 00:07:33.420
вопроса создается отдельное обращение. Затем обращению нужно место, где оно будет ждать своего

00:07:33.420 --> 00:07:37.880
исполнителя. Этим местом часто становится очередь. Очередь — это общий список задач для команды. Это не

00:07:37.880 --> 00:07:42.440
входящее одного агента, и оно не закреплено за тем, кто первым увидел запрос. Напротив, это место,

00:07:42.440 --> 00:07:46.740
где вся команда видит задачи, ожидающие внимания. Представьте компанию с отделом биллинга,

00:07:46.920 --> 00:07:51.420
технической поддержкой и отделом возвратов. У каждой команды своя очередь. Вопросы по оплате

00:07:51.420 --> 00:07:56.000
идут в биллинг, неисправности, в техподдержку, запросы на возврат, к тем, кто знает процедуру

00:07:56.000 --> 00:08:00.100
возврата. Звучит просто, потому что так оно и есть. Четкая сортировка избавляет сотрудников от

00:08:00.100 --> 00:08:03.640
необходимости перекидывать задачи наугад. В этой сортировке помогают правила маршрутизации.

00:08:03.800 --> 00:08:07.320
Правило маршрутизации проверяет детали обращения и направляет его в нужную очередь или конкретному

00:08:07.320 --> 00:08:11.120
человеку. Обращение по конкретному продукту попадает в продуктовую команду. Обращение из

00:08:11.120 --> 00:08:14.680
определенного региона направляется в локальную поддержку. Серьезная проблема попадает в очередь

00:08:14.680 --> 00:08:18.280
срочных задач. Общий вопрос ожидает обработки в стандартной команде. Некоторые организации

00:08:18.280 --> 00:08:21.820
распределяют задачи на основе навыков сотрудников. Например, клиенту, который пишет на французском,

00:08:21.960 --> 00:08:24.800
нужен агент, говорящий по-французски. Для технической проблемы требуется специалист,

00:08:24.940 --> 00:08:27.720
обученный работе с конкретным продуктом. Маршрутизация направляет обращение к тому,

00:08:27.720 --> 00:08:31.400
кто может его решить, вместо того, чтобы обрабатывать все запросы одинаково. Автоматизация помогает,

00:08:31.540 --> 00:08:35.120
но окончательные решения принимают люди. Руководитель группы может увидеть сложное обращение и

00:08:35.120 --> 00:08:38.760
назначить его напрямую старшему агенту. Возможно, кто-то из сотрудников уже знаком с клиентом.

00:08:38.920 --> 00:08:42.020
Может быть, проблема затрагивает несколько продуктов и требует опыта, который нельзя формализовать

00:08:42.020 --> 00:08:45.300
правилами. Ручное распределение оставляет команде простор для принятия решений человеком.

00:08:45.440 --> 00:08:49.300
Ответственный за обращение может меняться в процессе работы. Агенту может потребоваться больше информации,

00:08:49.300 --> 00:08:53.300
и он вернет обращение в очередь. Команда может обнаружить, что проблема относится к другому отделу,

00:08:53.400 --> 00:08:56.960
или срочный запрос может потребовать эскалации, если обычная команда не может его решить.

00:08:56.960 --> 00:09:01.620
Dynamics 365 обеспечивает движение работы, не допуская, чтобы она застряла у одного сотрудника.

00:09:01.800 --> 00:09:05.740
Иногда одна проблема создает множество обращений. Представьте сбой в программном обеспечении,

00:09:05.920 --> 00:09:09.000
который затрагивает десятки клиентов. Каждый клиент обращается в поддержку отдельно,

00:09:09.120 --> 00:09:12.700
поэтому для каждого сообщения нужно создать свое обращение. Но все эти сообщения связаны с одной

00:09:12.700 --> 00:09:15.600
более масштабной проблемой. Родительское обращение очлеживает общую проблему,

00:09:15.600 --> 00:09:19.080
а дочерние обращения очлеживают отдельные запросы клиентов в рамках этой проблемы. Это дает

00:09:19.080 --> 00:09:22.760
службе поддержки два уровня обзора одновременно. Они работают над устранением основного сбоя через

00:09:22.760 --> 00:09:26.040
родительское обращение, а каждое дочернее обращение помогает информировать нужного клиента.

00:09:26.220 --> 00:09:29.880
Когда решение найдено, им не нужно расследовать один и тот же сбой с нуля для каждого позвонившего.

00:09:30.260 --> 00:09:34.180
Дублирующиеся обращения создают похожую проблему в меньшем масштабе. Клиент может написать на почту

00:09:34.180 --> 00:09:37.120
и позвонить по одной и той же проблеме, или два агента могут открыть обращение,

00:09:37.260 --> 00:09:40.840
не заметив работы друг друга. Вместо того, чтобы распылять усилия, команда может объединить

00:09:40.840 --> 00:09:45.000
похожие обращения. Одно обращение становится основной записью, и работа ведется централизованная.

00:09:45.160 --> 00:09:49.280
Никто не должен решать одну и ту же проблему дважды. Направление обращения в нужную очередь

00:09:49.280 --> 00:09:53.420
нужному человеку – это начало работы, и клиент ожидает ответа в обещанные сроки.

00:09:53.600 --> 00:09:57.980
Выполнение обещаний с помощью SLA и направляемых процессов. Направить обращение нужному

00:09:57.980 --> 00:10:02.040
человеку – это лишь половина дела, ведь клиент также ожидает помощи в обещанное вами время.

00:10:02.180 --> 00:10:07.420
И здесь на помощь приходит соглашение об уровне обслуживания, или SLA. SLA привязывает к обращению

00:10:07.420 --> 00:10:11.320
таймер, поэтому команда точно знает, сколько времени у них есть на выполнение обещания,

00:10:11.560 --> 00:10:15.960
будь то первичный ответ или полное устранение проблемы. Но здесь важным фактором являются сроки.

00:10:15.960 --> 00:10:20.100
Это не всегда один и тот же дедлайн. Возьмем клиента, который ожидает подтверждения в течение

00:10:20.100 --> 00:10:24.060
одного часа, даже если технической команде нужно два рабочих дня, чтобы найти и протестировать

00:10:24.060 --> 00:10:28.820
исправление. Dynamics 365 отдельно очлеживает целевые показатели для первого ответа и для решения

00:10:28.820 --> 00:10:32.280
проблемы, чтобы команда могла действовать оперативно, не обещая мгновенного устранения

00:10:32.280 --> 00:10:36.980
любого вопроса. Представьте клиента, у которого перестал работать сервис. Он не ждет полного устранения

00:10:36.980 --> 00:10:41.520
неполадки за 10 минут, но ожидает подтверждения, что проблема принята в работу, хочет знать план действий

00:10:41.520 --> 00:10:45.500
и получать актуальную информацию. Целевой показатель первого ответа очлеживает первичный контакт,

00:10:45.500 --> 00:10:48.640
а целевой показатель решения – весь путь до получения ответа или исправления ошибки.

00:10:48.800 --> 00:10:52.440
Для разных клиентов могут действовать разные обязательства. Компания с премиальной поддержкой

00:10:52.440 --> 00:10:55.700
получает более короткие целевые сроки ответа, чем клиент с базовым тарифом.

00:10:55.820 --> 00:11:00.320
Критический сбой в работе требует меньшего времени на реагирование, чем обычный вопрос «как сделать».

00:11:00.320 --> 00:11:03.620
Договоры о поддержке, приоритетность и тип обращения определяют применяемые временные

00:11:03.620 --> 00:11:08.040
регламенты. Это делает обязательства справедливыми и прозрачными. Без SLA сотрудник может начать

00:11:08.040 --> 00:11:11.740
с самого старого обращения в списке, в то время как срочная задача пропустит свой дедлайн.

00:11:11.740 --> 00:11:15.140
С SLA экран обращения отображает индикаторы времени, которые подсказывают сотруднику,

00:11:15.260 --> 00:11:19.080
какое обязательство требует внимания в первую очередь. Так вы увидите, как нарастает напряжение.

00:11:19.260 --> 00:11:23.080
Обращение, у которого еще много времени, требует работы, но задачу с истекающим сроком

00:11:23.080 --> 00:11:26.720
ответа нужно решать прямо сейчас. Команды также могут настроить оповещение или этапы

00:11:26.720 --> 00:11:29.960
эскалации при приближении или истечении срока, чтобы руководитель мог вмешаться,

00:11:30.140 --> 00:11:33.720
прежде чем клиент начнет разыскивать команду. Временные целевые показатели определяют

00:11:33.720 --> 00:11:38.280
срочность, а потоки бизнес-процессов – саму работу. Поток бизнес-процесса – это набор этапов,

00:11:38.280 --> 00:11:41.700
отображаемых внутри обращения. Он дает сотруднику четкий алгоритм действий,

00:11:41.860 --> 00:11:44.380
основанный на том, как организация должна обрабатывать обращение.

00:11:44.560 --> 00:11:47.120
Этапы могут включать путь от приема и расследования до разрешения,

00:11:47.360 --> 00:11:49.600
с соответствующими вопросами и проверками на каждом шаге.

00:11:49.760 --> 00:11:52.240
Воспринимайте это как контрольный список, встроенный в процесс.

00:11:52.480 --> 00:11:56.560
Новому сотруднику не нужно гадать, какие детали важны, прежде чем передать обращение специалисту.

00:11:56.680 --> 00:12:00.180
Процесс может запрашивать информацию о продукте, типе проблемы, влиянии и другие данные,

00:12:00.180 --> 00:12:03.600
необходимые следующей команде. Более опытный сотрудник может действовать быстрее,

00:12:03.800 --> 00:12:06.460
но общий путь все равно помогает команде двигаться в одном направлении.

00:12:06.460 --> 00:12:11.220
Вот сценарий. Поступает критически важный сбой в обслуживании. Обращение попадает в срочную

00:12:11.220 --> 00:12:15.580
очередь, и его SLA начинает отсчет времени. Сотрудник подтверждает данные клиента,

00:12:15.860 --> 00:12:19.520
фиксирует влияние и отправляет первый ответ до истечения целевого срока.

00:12:19.740 --> 00:12:23.980
Затем поток процесса переводит обращение на этап диагностики, где команда собирает детали

00:12:23.980 --> 00:12:27.780
ошибки и проверяет связанные отчеты. После этого обращение переходит в стадию решения,

00:12:27.980 --> 00:12:31.560
когда команда устанавливает причину и готовит обновление для клиента. Эта последовательность

00:12:31.560 --> 00:12:34.580
также дает руководителям более ясную картину происходящего. Они видят,

00:12:34.580 --> 00:12:38.500
где процесс замедляется на этапе приема, диагностики или финального ответа клиенту.

00:12:38.620 --> 00:12:42.680
Этот рабочий процесс не решает все проблемы команды, но не дает важным шагам затеряться в

00:12:42.680 --> 00:12:47.240
загруженный день. Dynamics 365 позволяет контролировать, какие изменения статуса доступны

00:12:47.240 --> 00:12:51.720
агентам в разные моменты. Это называется переходами по причине статуса, звучит технически сложно,

00:12:51.960 --> 00:12:56.340
но суть проста. Работа по обращению должна проходить через логичные этапы. Нельзя допустить,

00:12:56.600 --> 00:13:01.300
чтобы кто-то отметил обращение как решенное, пока не пройдена внутренняя проверка или закрыл его

00:13:01.300 --> 00:13:05.360
без указания причины. Доступные варианты выбора могут меняться по мере развития ситуации.

00:13:05.520 --> 00:13:09.280
Например, если обращение находится на стадии расследования, агент может приостановить его в

00:13:09.280 --> 00:13:13.240
ожидании данных от клиента. После ответа клиента агент может вернуть обращение в активную работу.

00:13:13.420 --> 00:13:17.000
Когда проблема устранена, обращение можно перевести в статус «Решено». Это позволяет вести более

00:13:17.000 --> 00:13:20.680
четкую историю обращений. Одного ответа недостаточно для завершения работы. Команде необходимо

00:13:20.680 --> 00:13:24.620
зафиксировать, как разрешилась проблема, а затем правильно закрыть обращение. Решение – накопление

00:13:24.620 --> 00:13:28.380
опыта и повышение качества обслуживания. Отправка ответа не приводит к автоматическому

00:13:28.380 --> 00:13:32.840
закрытию обращения. Команде нужно зафиксировать решение, то есть записать, что именно помогло

00:13:32.840 --> 00:13:36.940
или какой окончательный ответ получил клиент. Это может быть отправка замены устройства,

00:13:37.220 --> 00:13:42.100
возврат платежа или обновление настроек доступа пользователям. Эта заметка становится частью

00:13:42.100 --> 00:13:47.000
истории клиента и помогает следующему агенту быстрее вникнуть в суть, если клиент обратится

00:13:47.000 --> 00:13:52.040
снова спустя месяцы. Иногда первое решение не срабатывает. Возможно, клиент следовал инструкциям,

00:13:52.200 --> 00:13:56.160
но ошибка возникла снова. Может быть, присланная запчасть не устранила неисправность.

00:13:56.160 --> 00:14:00.080
В такой ситуации команда может возобновить обращение или вернуть его в очередь,

00:14:00.280 --> 00:14:04.280
вместо создания новой записи без истории. Работа над обращением продолжается с того места,

00:14:04.480 --> 00:14:08.220
где она была прервана. Это особенно важно при смене ответственного. Новый агент видит,

00:14:08.380 --> 00:14:12.860
что уже пробовал его коллега, что подтвердил клиент и что еще требует проверки. Клиенту не нужно

00:14:12.860 --> 00:14:17.480
рассказывать все заново только из-за того, что работу принял другой сотрудник. Со временем все эти

00:14:17.480 --> 00:14:21.540
обращения показывают команде поддержки общую картину, выходящую за рамки одной проблемы.

00:14:21.780 --> 00:14:25.460
Руководители могут отслеживать время до решения, измеряя длительность пути обращения

00:14:25.460 --> 00:14:28.780
от открытия до закрытия. Они могут анализировать время на этапах, чтобы видеть,

00:14:28.940 --> 00:14:32.680
где именно скапливаются обращения. Они также следят за решением при первом контакте,

00:14:32.860 --> 00:14:36.240
как часто первый специалист может сам закрыть вопрос без перевода на другого.

00:14:36.380 --> 00:14:40.520
Нагрузка тоже имеет значение. Если одна очередь заполняется каждое утро понедельника,

00:14:40.700 --> 00:14:44.600
команда это увидит. Если технические обращения днями ожидают внутренние проверки,

00:14:44.800 --> 00:14:48.400
эта задержка видна в данных. Если команда быстро закрывает обращения,

00:14:48.620 --> 00:14:52.460
но клиенты их переоткрывают, стоит присмотреться к качеству этих исправлений.

00:14:52.460 --> 00:14:57.240
Сами по себе цифры не объясняют всего. Они подсказывают команде, какие вопросы стоит задать.

00:14:57.360 --> 00:15:01.000
Почему растет число обращений по одному продукту? Почему определенные типы обращений

00:15:01.000 --> 00:15:04.980
занимают больше времени, чем ожидалось? Почему специалисты постоянно ищут один и тот же ответ,

00:15:05.140 --> 00:15:08.720
но не находят полезной статьи в базе знаний? Закономерности превращают ежедневную работу

00:15:08.720 --> 00:15:12.620
поддержки в практический опыт. Рост числа похожих обращений может указывать на дефект продукта.

00:15:12.780 --> 00:15:16.080
Это может означать, что недавнее обновление запутало клиентов. Это может показать,

00:15:16.240 --> 00:15:20.200
что руководство пользователя требует уточнения шагов. Вместо того, чтобы считать каждый запрос отдельным,

00:15:20.200 --> 00:15:24.140
команда может выявить общую причину и устранить ее. Это поможет сократить количество будущих

00:15:24.140 --> 00:15:28.500
обращений. Отзывы клиентов тоже важны для общей картины. Закрытое обращение может означать,

00:15:28.680 --> 00:15:33.040
что команда уложилась в сроки, но клиент может быть недоволен, если ему пришлось обращаться трижды.

00:15:33.220 --> 00:15:37.340
Анализ истории обращений и отзывов дает руководителям полное представление о качестве обслуживания.

00:15:37.540 --> 00:15:41.660
Некоторые клиенты предпочли бы вообще не создавать обращения. Здесь на помощь приходит портал

00:15:41.660 --> 00:15:47.540
самообслуживания. Через портал клиенты могут создавать запросы, проверять статус, добавлять информацию

00:15:47.540 --> 00:15:52.600
или читать статьи без звонка в поддержку. Для простых вопросов это экономит время каждому.

00:15:52.820 --> 00:15:57.120
Клиент может проверить статус доставки или пройти руководство по настройке в удобное время.

00:15:57.300 --> 00:16:01.320
В это время специалисты могут больше внимания уделить вопросам, требующим участия человека,

00:16:01.540 --> 00:16:06.260
разъяснений или решений. Dynamics 365 Customer Service также интегрируется с привычными инструментами

00:16:06.260 --> 00:16:10.500
Microsoft в процессе работы с обращениями. Специалист может работать с электронной почтой через Outlook.

00:16:10.680 --> 00:16:15.580
Команда может обсудить сложный вопрос в Teams. Документы и общая информация могут храниться в SharePoint.

00:16:15.580 --> 00:16:20.480
Power BI превращает данные в отчеты и панели мониторинга, а инструменты Power Platform помогают

00:16:20.480 --> 00:16:25.380
настраивать формы, оповещение и автоматизацию процессов. У каждого инструмента своя задача.

00:16:25.520 --> 00:16:30.140
Обращение остается тем местом, где проблема и ее история связаны воедино, даже если сотрудники

00:16:30.140 --> 00:16:34.240
используют другие инструменты для общения и работы. Управление обращениями – это не просто

00:16:34.240 --> 00:16:39.280
заполнение полей в системе. Это путь к решению проблем клиента, фиксации ответов и обучение команды

00:16:39.280 --> 00:16:44.220
на основе накопленного опыта. Заключение. Сохраняйте всю историю взаимодействия с клиентом в одном месте.

00:16:44.220 --> 00:16:49.720
Итак, вот главный вывод. Управление обращениями в Dynamics 365 объединяет проблему, работу,

00:16:49.920 --> 00:16:53.760
обещание и результат в одной записи. Больше никакого потерянного контекста или повторных

00:16:53.760 --> 00:16:57.940
исправлений. Взгляните на свой собственный процесс поддержки. О, куда же исчезает информация

00:16:57.940 --> 00:17:02.220
о клиентах? Именно здесь объединение всех данных меняет все. Подписывайтесь на любимый

00:17:02.220 --> 00:17:05.960
подкаст-платформе, чтобы получать больше полезных знаний от меня, Мирко Питерса,

00:17:06.120 --> 00:17:10.520
на m365.fm, где мы простым языком рассказываем о рабочих инструментах Microsoft.