Dynamics 365 Customer Service discovery
Как описать жизненный цикл обращений, SLA, очереди, маршрутизацию, базу знаний и роли до внедрения Dynamics 365 Customer Service.
Tugelbay Konabayev, Marketing Specialist · 9 июня 2026 г.
Эти блоки отвечают на практические вопросы без скрытого текста и без неподтвержденных обещаний по срокам, стоимости или результату.
Dynamics 365 Customer Service - это CRM-приложение Microsoft для клиентского сервиса: обращения, cases, interactions, queues, routing, service levels, knowledge base, agent and supervisor work, service reporting and customer context. Для проекта важно сначала описать service process, а не только будущий экран CRM.
CRM для клиентского сервиса нужна, когда обращения приходят из почты, телефона, сайта, мессенджеров, филиалов или service desk, но команда не видит единый case status, owner, category, escalation, service-level risk, history and reporting.
Sales CRM отвечает за лиды, pipeline, opportunities, forecast and sales activities. Customer Service отвечает за обращения: case lifecycle, channels, queues, routing, service levels, knowledge base, escalation, agent workload, supervisor visibility and service quality metrics.
До внедрения нужно описать support channels, request categories, case statuses, priorities, queues, routing logic, agent and supervisor roles, service-level expectations, knowledge article ownership, customer/order data, reporting metrics, integrations and first-scope boundaries.
Case lifecycle описывает путь обращения: source, customer/account context, category, priority, owner, queue, status, interactions, escalation, service-level tracking, resolution, closure reason and possible reopen. Если lifecycle не согласован, CRM будет хранить записи, но не управлять сервисом.
SLA/service-level logic показывает, какие milestones нужно отслеживать в case lifecycle. Routing показывает, кто должен получить work item. Перед внедрением важно описать working hours, pause/resume rules, queues, skills, availability, workload, escalation owner and supervisor review.
Knowledge base нужна, чтобы agents работали с согласованными статьями, инструкциями и troubleshooting steps, а не искали ответы в чатах, старых файлах и личной памяти. До внедрения нужно определить article owner, approval, versions, publishing and archive rules.
Для оценки отправьте channels, request types, case lifecycle, roles, queues, routing, service-level expectations, knowledge base inputs, reports, current tools, customer/order data, integrations, migration expectations, procurement context and desired first scope.
Dynamics 365 Customer Service стоит рассматривать не когда просто хочется “CRM для поддержки”, а когда обращения должны стать управляемым процессом: каналы, cases, категории, приоритеты, очереди, маршрутизация, уровни сервиса, база знаний, взаимодействия, эскалация, отчеты. До внедрения нужно описать не интерфейс, а операции: как приходит обращение, кто его берет, как классифицируется, куда попадает, кто отвечает, как фиксируется решение и что нужно руководству.
Для B2B-компаний Казахстана эта подготовка критична: сервис часто раскидан по почте, телефону, мессенджерам, сайту, Excel, 1С/ERP, Microsoft 365, Teams и Power BI. Если просто перенести каналы и привычки в новую систему, Customer Service не решит проблему. Он станет еще одним хранилищем записей. Если описать до внедрения case lifecycle, роли, маршрутизацию, уровни сервиса и границы данных, оценка честнее, scope управляемей.
Этот гайд не является предложением, тарифом, юридическим совет или обещанием результатов. Его задача — помочь менеджеру сервиса, CRM owner, супервайзеру, IT, владельцу данных и procurement собрать вводные перед открытием требований.
Обновлено: 9 июня 2026 года. Гайд опирается на Microsoft Learn. Любые решения по tenant, лицензированию, каналам, интеграции или закупке нужно проверять в актуальном контексте.
Этот гайд нужен, если в компании звучат фразы:
Для директора сервиса это способ увидеть, где нужно управление. Для супервайзера — описать нагрузку, очереди, старение, эскалацию. Для CRM owner — зафиксировать поля, статусы, категории, владельца. Для IT — увидеть доступ, окружения, каналы, границы интеграции. Для finance/procurement — не запросить предложение на неполном scope.
Этот гайд покрывает только discovery до внедрения сервисной CRM. Он помогает описать, что должно быть согласовано до внедрения Dynamics 365 Customer Service: каналы, обращения, категории запросов, жизненный цикл обращения, очереди, маршрутизация, уровни сервиса, база знаний, роли агентов и супервайзеров, готовность данных, отчетность и границы первого scope.
Он не заменяет страницу Dynamics 365 Customer Service в Казахстане, где находится коммерческий сервисный маршрут. Он не заменяет проверку поддержки/списка доработок Dynamics 365, потому что здесь речь не о разборе уже накопленных ошибок/запросов изменений. Он не заменяет Sales discovery Dynamics 365, где владелец намерения - pipeline, прогноз и роли продаж.
Также это не гайд по стоимости CRM, не гайд по выбору партнера, не архитектура интеграции D365 + 1C и не оценка панели управления Power BI. Эти страницы могут быть ветвями следующего шага, но не должны поглощаться этой статьей.
Уникальная цель этого гайда узкая: что согласовать перед внедрением, чтобы Dynamics 365 Customer Service можно было оценить и определить скоп ответственно.
Плохой проект Customer Service часто начинается с просьбы “сделайте нам обращения, SLA и маршрутизацию”. Хороший discovery начинается с другого вопроса: что такое обращение в вашей компании, какие источники обращений есть, какие категории действительно нужны, кто владеет обращением, когда оно считается разрешенным, когда оно должно быть эскалировано, какие знания нужны агенту и что супервайзер проверяет каждый день.
Microsoft Learn описывает Customer Service как приложение для отслеживания проблем клиентов, записи взаимодействий, обмена знаниями, маршрутизации, управления каналами, сотрудничества в Teams, отслеживания SLA, определения прав и отчетности. Это важно, но это не определяет ваш процесс.
Перед конфигурацией согласуйте язык процесса:
Если термины означают разное для агентов, супервайзеров, IT и procurement, реализация станет спорами внутри системы. Открытие требований превращает споры в названные решения перед проектом.
Первым практическим артефактом является таблица жизненного цикла обращения. Она не должна быть технической. Она должна показать, что сервисная команда означает под словом “обращение”.
| Lifecycle point | Что нужно описать | Почему это важно | Discovery decision |
|---|---|---|---|
| Source | Email, phone, website form, messenger, portal, branch, service desk or internal request. | Source affects routing, visibility and data completeness. | Which channels are phase one? |
| Customer context | Account, contact, BIN/requisites if process needs it, contract/order/product context. | Agent needs context before responding or escalating. | What data belongs in CRM vs 1С/ERP? |
| Category and priority | Request types, category tree, priority rules, urgency and affected product/service. | Bad categories break routing and reporting. | Which categories are required at case creation? |
| Assignment | Owner, queue, team, skill, region, product, fallback and manual reassignment rule. | Unclear ownership creates invisible backlog. | What is routed automatically and what remains manual? |
| Work in progress | Statuses, interactions, waiting reason, escalation, expert collaboration and customer updates. | Supervisor needs to understand why the case is open. | Which statuses are meaningful? |
| Service-level tracking | Milestones, working hours, pause/resume logic, warning/failure conditions and owner review. | Service-level tracking depends on process rules, not only timers. | Which milestones are tracked in phase one? |
| Resolution and closure | Resolution reason, closure criteria, article used, customer confirmation, reopen rules. | Closure rules affect reporting and service learning. | Who can close or reopen a case? |
| Reporting handoff | Backlog, volume, category trends, aging, reopen, service-level status and workload metrics. | Reports require stable fields and metric ownership. | CRM views first, Power BI later, or both? |
Эта таблица предотвращает скрытый scope. Если web-формы - это фаза два, скажите это. Если интеграция телефонии/contact center выходит за scope, скажите это. Если данные заказа из 1С необходимы агентам, скажите это рано. Меньший ясный первый scope лучше, чем большой неопределенный запрос на реализацию.
Проекты Customer Service терпят неудачу, когда все предполагают, что кто-то другой владеет качеством процесса. Отделите деловое владение от владения платформой/доступом.
| Role / owner | Business ownership | Platform or access consideration | Discovery question |
|---|---|---|---|
| Agent / service representative | Works cases, records interactions, updates status, uses knowledge and escalates when needed. | Needs access to assigned cases, customer context, knowledge search and required channels. | What must agent update before a case review? |
| Supervisor / team lead | Reviews backlog, workload, aging, escalations, queues and service-level risk. | Needs team views, queue visibility, dashboards and escalation controls. | Which cases require supervisor attention? |
| Service manager | Owns service policy, request categories, quality rituals, staffing questions and improvement backlog. | Approves process changes that affect fields, statuses, queues or reports. | Who approves case lifecycle changes? |
| Service operations / CRM owner | Owns daily CRM rules, data quality, knowledge ownership, adoption feedback and change requests. | Coordinates configuration with IT/admin and avoids uncontrolled changes. | What is change request vs support issue? |
| IT/admin owner | Keeps tenant, environments, access, channels, integrations and release process manageable. | Configures roles, queues, routing dependencies, apps, environments and integration boundaries. | Which access or integration dependency can block phase one? |
| Data / BI owner | Owns metric definitions, dashboard logic, source trust, refresh needs and reporting audience. | Needs stable fields, categories, statuses and source alignment before Power BI model design. | Which case fields become reporting source of truth? |
| Finance / procurement | Needs scope, users, legal entity, requisites, contract route, approvals and RFP context. | May need visibility into service scope, integrations and acceptance criteria. | What must be known before proposal or RFP? |
Эта матрица также защищает от ошибок доступа. Супервайзер как деловая роль может нуждаться в видимости рабочей нагрузки очереди. Это не означает автоматически широкий доступ ко всем данным клиента. Деловое владение и проектирование разрешений должны быть согласованы, а не предполагаемы.
SLA/логика уровня сервиса и маршрутизация должны рассматриваться как вопросы готовности перед конфигурацией. Microsoft Learn описывает SLA через KPI, рабочие часы, правила паузы, предупреждения и отказы. Маршрутизация описывается через классификацию, назначение очередям и представителям на основе требований, навыков, доступности и нагрузки.
Безопасный вопрос discovery — не “какие цели обещать”. Правильный вопрос — “какой процесс измеримый, кто им владеет и какой контекст нужен для маршрутизации”.
| Readiness area | What to define | Who owns it | What to avoid |
|---|---|---|---|
| Working hours | Which service calendar applies to each queue, region, channel or support type. | Service manager with IT/admin. | Assuming all requests share one calendar. |
| Milestones | Which events should be tracked, such as first response, escalation review or resolution milestone. | Service operations and supervisor. | Publishing target values before policy review. |
| Pause/resume | Which statuses or waiting reasons pause tracking and who can change them. | Service manager and CRM owner. | Letting every pause become an escape hatch. |
| Queues | Record, messaging or voice queues; members; fallback; operating context and priority. | Supervisor and IT/admin. | Creating queues that mirror org chart but not workload. |
| Classification | Which category, product, region, customer type, urgency or related data drives routing. | Service operations and data owner. | Routing on fields users do not maintain. |
| Assignment | How workload, availability, skills, capacity or manual override should affect assignment. | Supervisor and IT/admin. | Automating before the team trusts categories. |
Не превращайте этот раздел в рекомендуемые целевые показатели сервиса. Гайд должен помочь команде подготовиться к конфигурации, не определяя обязательства перед клиентом. Фактические значения и политики принадлежат владельцам бизнеса, юридической/коммерческой и сервиса.
База знаний часто рассматривается как папка с ответами. В discovery Customer Service она должна быть управляемым жизненным циклом контента. Microsoft Learn описывает KnowledgeArticle, версионирование, переводы и состояния: Draft, Approved, Scheduled, Published, Expired, Archived, Discarded.
Перед внедрением, ответьте на эти вопросы:
Слабая база хранит документы. Полезная база снижает вариативность ответов и помогает новым агентам работать с утвержденными инструкциями. Но это работает только если есть владелец. Если никто не проверяет статьи, база накапливает устаревшие ответы.
Для команд Казахстана важен местный язык. Источник истины может быть русским, но контент для клиентов или внутренний контент потом может нуждаться в казахских или региональных вариантах. Это управляемый процесс контента, не автоматический перевод неутвержденных статей.
Отчетность начинается в полях CRM, не в диаграммах. Если категории нестабильны, статусы неясны и причины закрытия опциональны, панель не создаст доверие. Перед Power BI определите, какие решения поддерживает отчет.
Полезные вопросы reporting:
Если панель нужна только для открытых обращений, категорий и нагрузки, первая фаза может остаться в Customer Service views и dashboards. Если панель объединяет CRM, 1С/ERP, finance, website, telephony или sales, это Power BI/Fabric маршрут. Не проблема, но не должно быть скрыто в оценке Customer Service.
Data readiness baseline для phase one:
Customer Service часто нуждается в данных, которые находятся вне CRM. Агентам может понадобиться видеть статус контракта, статус заказа, статус платежа, гарантию, продукт, отправку, филиал, актив или главные данные клиента. В Казахстане это часто означает 1С/локальную ERP или другую операционную систему.
Перед тем как рассматривать интеграцию как часть первого scope, спросите:
Contact center и каналы похожи. Email, формы, голос, чат, мессенджер могут быть отдельными потоками. Discovery должен их классифицировать:
Это защищает первую реализацию от скрытого расширения. Запрос “обращения и SLA” может легко разрастись на голос, чат, портал, ERP, Power BI, Power Automate и RFP. Всё может быть действительным, но не должно появляться неожиданно.
Используйте этот чеклист перед запросом оценки Dynamics 365 Customer Service.
1. Каналы
Перечислите электронную почту, телефон, web-формы, мессенджеры, портал, service desk, филиальные запросы, внутренние запросы сервиса и любые contact-center-инструменты. Отметьте, какие каналы - это первая фаза.
2. Типы запросов
Определите категории и подкатегории. Избегайте создания десятков категорий перед тем как команда поймет потребности отчетности.
3. Жизненный цикл обращения
Опишите источник, создание, назначение, изменения статуса, причины ожидания, эскалацию, разрешение, закрытие и повторное открытие.
4. Роли
Перечислите агентов, супервайзеров, team leads, менеджера сервиса, операции сервиса, владельца CRM, IT/администратора, владельца sales/account, finance/procurement и владельца BI/data.
5. Очереди и маршрутизация
Определите очереди, членов, входы маршрутизации, правила fallback, правила ручного переназначения, логику region/product/category и владение эскалацией.
6. Логика уровня сервиса
Опишите какие вехи нужно отслеживать, какие рабочие часы применяются, что паузирует отслеживание, кто может переопределить, и кто рецензирует риски. Не превращайте это в обязательства перед клиентом внутри этого гайда.
7. База знаний
Перечислите типы статей, владельцев, поток одобрения, поток публикации, версионирование, правила архива и языки если нужны.
8. Данные
Опишите данные клиента, контакта, продукта, заказа, контракта, платежа, гарантии и филиала, необходимые агентам. Отметьте где сегодня живет каждый элемент данных.
9. Отчетность
Назовите отчеты и решения: backlog, volume, категория trends, старение, повторное открытие, рабочая нагрузка, эскалация, статус уровня сервиса и пробелы в знаниях.
10. Интеграции
Перечислите Microsoft 365, Teams, web-формы, mailbox, Power Platform, Power BI, Azure, 1С/локальную ERP, телефонию или contact center. Отметьте первая фаза vs будущий scope.
11. Миграция
Решите нужна ли старым письмам, строкам Excel, ticket-ам service desk или старым случаям CRM миграция, архив или исключение.
12. Контекст Procurement
Укажите, что это: неформальный discovery, подготовка внутреннего бюджета, коммерческое предложение, tender/RFP или проверка существующей системы.
Первая ошибка: каждый email — один тип case. Жалобы, technical issues, вопросы о платежах, запросы статуса заказа, внутренние запросы нуждаются в разных owner, category, queue, escalation.
Вторая ошибка: слишком много statuses. Statuses помогают agents и supervisors управлять работой. Если никто не знает, что означает статус, это noise в отчетах.
Третья ошибка: автоматизация routing перед доверием к категориям. Routing зависит от полей. Если agents выбирают категорию случайно, routing будет случайна.
Четвертая ошибка: видимость service levels перед готовностью процесса. Tracking milestones полезен только когда ясны рабочие часы, правила паузы, владельцы, исключения.
Пятая ошибка: база знаний без владельца. Статьи нужны review, updates, archive, feedback. Иначе agents вернутся к чатам и файлам.
Шестая ошибка: скрытое 1С/ERP зависимость. Если cases зависят от заказа, платежа, контракта, product data, интеграция или access должны быть названы перед оценкой.
Седьмая ошибка: просить Power BI исправить плохие CRM данные. BI выявляет patterns, но не делает categories, closure reasons, owners consistent после факта.
После этого гайда выберите следующий шаг:
Не сжимайте всё в одну фазу. Практичный первый scope — обращения, базовые категории, роли агента/супервайзера, очереди, готовность SLA, владение знаниями, начальные отчеты. Позднейшие фазы добавят каналы, Power BI, Power Platform, интеграцию 1С/ERP, портал, contact center, региональный rollout.
Продуктовая механика проверена в соответствии с источниками Microsoft на 9 июня 2026:
KnowledgeArticle, article versions, translations and article lifecycle states.Гайд не интерпретирует лицензирование, налоги, procurement правила, местные требования, статус Partner, доступность продукта, архитектуру клиента. Он не обещает коммерческие результаты, даты, цены, условия контракта, результаты сервиса или реализации.
Да, если первый scope осознанно ограничен case intake, categories, statuses, queues, basic service-level logic and supervisor views. Но даже такой старт должен описать channels, owners, escalation, closure rules, reporting needs and data quality, иначе cases быстро станут новой почтой внутри CRM.
Service CRM discovery обычно включает карту каналов обращений, request types, case lifecycle, agent and supervisor roles, queues, routing, service-level logic, knowledge base ownership, reporting needs, integrations, data migration expectations, access model and first-scope criteria.
Связь нужно описывать через рабочие сценарии: какие письма или формы создают cases, где agents обсуждают сложные обращения, как supervisors видят context, какие interactions фиксируются и какие данные должны оставаться внутри CRM. Конкретная настройка зависит от tenant, roles and access model.
Можно начать с views and dashboards inside Customer Service, если нужны базовые списки backlog, open cases, queues and categories. Power BI становится отдельным маршрутом, когда нужны cross-system metrics, finance/order context, сложные модели, refresh, access rules and executive reporting.
Интеграция нужна, когда agent должен видеть или передавать customer master data, contracts, orders, invoices, payment status, warranty, product data or service history outside CRM. Если первый scope только фиксирует обращения, интеграцию можно вынести в отдельный discovery.
Можно, но сначала нужно решить, какие historical records нужны, какие можно архивировать, как сопоставить customers, contacts, categories, owners, statuses, notes and attachments. Миграция без очистки переносит старые service problems в новую систему.
Если Customer Service, старая CRM или service desk уже используются, но backlog большой, statuses спорные, routing не работает, service-level logic непонятна или reports не вызывают доверия, лучше начать с support/backlog review before new implementation scope.
Нет. Guide помогает подготовить вводные для разговора: channels, case lifecycle, roles, queues, routing, service levels, knowledge, reports, data and integrations. Коммерческое предложение строится после discovery, source review, tenant context, procurement route and acceptance criteria.
Используйте guide как pre-implementation worksheet: опишите channels, cases, roles, queues, routing, service-level logic, knowledge base, reporting and integration boundaries. После этого можно идти в service CRM discovery без хаотичного scope.