Dynamics 365 Sales discovery
Как описать sales pipeline, lead qualification, opportunity stages, forecast и роли до внедрения Dynamics 365 Sales.
Tugelbay Konabayev, Marketing Specialist · 9 июня 2026 г.
Эти блоки отвечают на практические вопросы без скрытого текста и без неподтвержденных обещаний по срокам, стоимости или результату.
Dynamics 365 Sales - это CRM-приложение Microsoft для работы с клиентами, лидами, accounts, contacts, opportunities, активностями, pipeline и forecast. Для проекта важна не только настройка полей, а согласованный sales process: кто ведет клиента, когда лид становится сделкой и как руководитель смотрит прогноз.
CRM на Dynamics 365 имеет смысл рассматривать, когда продажи уже не помещаются в Excel, почту и личные заметки: есть несколько источников лидов, роли продаж, менеджерские обзоры, forecast, связь с Microsoft 365, Power BI, Power Platform, сайтом или 1С/ERP.
До внедрения нужно описать lead sources, lead qualification, account/contact ownership, opportunity stages, required fields, activities, forecast categories, reporting needs, quote/order handoff, integrations, роли пользователей, правила доступа, owner процесса и критерии первого запуска.
Lead qualification описывает, когда потенциальный интерес становится рабочей возможностью для продаж. Opportunity stages описывают путь сделки после квалификации: вход и выход из этапа, обязательные поля, owner, close date, next step, close reason и forecast category, если компания использует прогнозирование.
Pipeline и forecast не должен владеть только IT. Business owner задает процесс, sales manager отвечает за review cadence, sellers ведут актуальность сделок, CRM owner следит за правилами и data quality, а IT/admin owner настраивает доступы, environments and platform dependencies.
Dynamics 365 Sales может быть источником sales data для pipeline review and forecast mechanics. Power BI нужен, когда руководству требуется отдельная управленческая модель: общие метрики, несколько источников данных, refresh, доступы, детализация и agreed reporting logic.
Связь Sales с 1С или ERP становится scope-вопросом, когда CRM должна передавать или получать customers, products, quotes, orders, договоры, статусы оплаты, справочники или master data. Это не поле в форме, а отдельная integration boundary.
Для оценки отправьте sales process, список ролей, текущие инструменты, источники лидов, pipeline stages, forecast requirements, reports, интеграции, пример данных, миграционные ожидания, procurement context, ограничения доступа, критерии приемки и вопрос, какой first scope нужен бизнесу.
Dynamics 365 Sales имеет смысл, когда продажи должны работать в управляемом процессе: лиды, квалификация, accounts, contacts, opportunities, stages, активности, forecast и отчеты. До внедрения нужно описать логику продаж: кто создает лид, кто квалифицирует, когда появляется сделка, какие stages, кто обновляет close date, кто смотрит forecast и какие данные в отчетах.
Для B2B-компаний в Казахстане это критично: процесс продаж часто разбросан по Excel, Outlook, Teams, мессенджерам, сайту, 1С и личным заметкам. Если просто перенести все в новую CRM, она станет дорогой копией старого хаоса. Если описать процесс, роли и границы перед внедрением, оценка будет точнее и запуск реалистичнее.
Этот гайд не является коммерческим предложением, прайсом, рекомендацией партнера или обещанием роста. Его задача — помочь направляющим и IT собрать вводные перед открытием требований.
Обновлено: 9 июня 2026. Информация опирается на Microsoft Learn (см. источники). Любые решения по tenant, лицензированию, данным или интеграции проверяйте в контексте заказчика.
Этот гайд нужен, если компания узнает себя хотя бы в нескольких ситуациях:
Для директора продаж — процесс без деталей. Для владельца CRM — правила и логика полей. Для IT — доступ, окружения, интеграции. Для finance/procurement — ранний discovery от коммерческого предложения. Для BI — определения данных перед панелью.
Этот гайд касается только pre-implementation sales CRM discovery: воронка, квалификация, stages, роли, forecast, отчеты и quote/order границы.
Не заменяет Service route, CRM cost guide, выбор партнера или support backlog review.
Не архитектура интеграции с 1С: для API, синхронизации и поддержки — гайд интеграции. Не управленческие панели: для метрик и доступа — Power BI/Fabric.
Цель гайда узкая: помочь согласовать вводные перед внедрением.
Плохой проект начинается с вопроса «какие поля нужны». Хороший начинается раньше: что такое лид, кто владеет контактом, когда появляется сделка, какие stages, какие данные для forecast, где заканчивается CRM и начинается quote/order.
Microsoft Learn описывает Sales как инструмент для accounts, контактов, лидов, opportunities и forecast. Это важный контекст, но не убирает необходимость определить процесс самой компании. Платформа хранит и управляет workflows; она не может решить что считается квалифицированным лидом, кто проверяет forecast или какое поле доверено финансам.
Сначала определите язык процесса:
Если слова означают разное, конфигурация станет переговорами. Sellers просят меньше обязательных полей, менеджеры — больше контроля, IT — стабильные правила, BI — чистые данные, finance — границу с quote/order. Discovery помогает разрешить эти конфликты перед реализацией, не на UAT.
Разложите sales process на блоки перед оценкой. Таблица — рабочий лист для разговора между sales, CRM owner, IT и data owner.
| Блок | Что нужно описать | Почему это важно | Куда ведет дальше |
|---|---|---|---|
| Lead sources | Website forms, email, outbound, partner/channel, tender, webinar, events, referrals. | Без источника и owner лиды теряются или дублируются. | Lead capture, routing, forms, marketing handoff. |
| Lead qualification | Какие criteria делают лид sales-ready: company, need, contact, service area, urgency, budget context, decision owner. | Qualification separates noise from real opportunity work. | Lead-to-opportunity rules. |
| Account and contact | Кто владеет company record, contacts, duplicates, branch entities, regional accounts and contact changes. | Dirty account data breaks ownership, reporting and integration. | Data model and access review. |
| Opportunity stages | Stages, exit criteria, required fields, next step, close date, owner and reason for closing. | Stages without criteria are just labels. | Pipeline configuration. |
| Activities | Calls, meetings, emails, tasks, follow-ups, notes and what should be visible to the team. | Pipeline review needs evidence, not only manager memory. | Microsoft 365 and activity tracking scenarios. |
| Forecast | Forecast categories, close date discipline, hierarchy, quota context, review cadence and exceptions. | Forecast depends on trusted opportunity data and agreed review logic. | CRM forecast and Power BI handoff. |
| Quote/order handoff | Когда deal leaves CRM scope, what products/orders/docs matter, and which system owns commercial execution. | Quote/order boundary can become ERP integration scope. | 1С/ERP or finance process discovery. |
| Reporting | Which decisions depend on reports, who owns metrics, data refresh, filters, access and dashboard audience. | BI built on unstable CRM fields creates distrust. | Power BI/Fabric route. |
Смысл таблицы — избежать скрытого scope. Если quote/order не в первой фазе — скажите. Если Power BI позже — скажите. Если захват лидов критичен — опишите. Меньший четкий scope лучше, чем большой расплывчатый.
Критическая ошибка — смешивание делового владения с ролями безопасности. Менеджер продаж владеет review forecast. Роль Sales Manager в Dynamics контролирует разрешения. Они связаны только через дизайн; это не одно.
Эта матрица разделяет бизнес-решения от платформы/доступа.
| Role / owner | Business ownership | Platform or access consideration | Discovery question |
|---|---|---|---|
| Seller / account manager | Keeps opportunities, activities, next steps and close dates current. | Needs access to own records, related accounts, contacts, activities and views. | What must seller update before pipeline review? |
| Sales manager | Runs pipeline review, challenges stages, monitors forecast discipline and team workload. | May need team-level views, dashboards, reports and permission boundaries. | Which fields make a deal review-ready? |
| Sales operations / CRM owner | Owns process rules, stage definitions, data quality rules, change requests and adoption feedback. | Coordinates configuration rules with IT/admin and avoids uncontrolled field/process changes. | Who approves changes to stages and required fields? |
| IT/admin owner | Keeps tenant, environments, apps, access model and platform governance manageable. | Configures roles, permissions, environments, integrations and release process. | Which access rules and dependencies can block first scope? |
| Finance / procurement | Needs clear scope, purchasing context, requisites, approvals, contract route and quote/order boundary. | May need limited visibility into commercial stages, order handoff or reporting outputs. | What must be known before proposal or RFP? |
| Data / BI owner | Owns metric definitions, dashboard logic, source trust, refresh needs and reporting audience. | Needs stable CRM fields, access model and source alignment before Power BI model design. | Which CRM fields become reporting source of truth? |
Это предотвращает обычный конфликт: бизнес говорит «менеджер видит forecast», IT слышит «широкие разрешения», BI видит «поля непоследовательны», procurement спрашивает «почему scope изменился». Discovery разделяет владельца решения, владельца данных и владельца доступа.
Microsoft Learn описывает leads как захват и развитие потенциала, opportunity как сделку после готовности. Ключевой вопрос discovery — не «поддерживает ли Dynamics лиды» (поддерживает), а как ваша компания решает, когда один станет другим.
Начните с источников лидов:
Затем определите квалификацию. Слабое правило звучит как “менеджер посмотрит”. Более сильное правило описывает доказательство:
Этапы opportunity должны быть меньше и понятнее, чем ожидают люди. Этап полезен только если он меняет поведение. Если этап первый и этап второй требуют одни и те же действия, это, вероятно, не отдельные этапы. Если этап не определяет требуемую информацию, он не поможет forecast или отчетности.
Для каждого stage определите:
Названия stages понятны для team на русском: воронка, этапы, прогноз, роли, квалификация, сделка. Английские термины типа pipeline, forecast, lead, opportunity допустимы, если уже стандартны в team.
Forecast часто запрашивается рано. Менеджер хочет forecast, но CRM не имеет стабильных close dates, stage criteria, дисциплины владельца и четких категорий. Результат — официально выглядящий, но недоверяемый отчет.
Microsoft Learn объясняет forecasting через pipeline, категории, квоты и rollups. Компания должна решить что это означает:
Практическая готовность к forecast можно зафиксировать в таблице перед любой конфигурацией:
| Pipeline point | What seller updates | Forecast decision | Review owner |
|---|---|---|---|
| Qualified opportunity | Need, account/contact, owner, next step and expected close context. | Usually not management-ready until stage criteria are proven. | Seller and sales manager. |
| Active proposal or КП | Proposal status, customer feedback, blockers, close date and decision owner. | Can enter forecast review if category rules are agreed. | Sales manager with finance/procurement context if needed. |
| Tender or long approval | Procurement stage, document status, dependencies, close date changes and risk notes. | Needs explicit review cadence because close date can move. | Sales manager and procurement owner. |
| Quote/order handoff | Accepted commercial step, handoff owner, CRM status and external-system dependency. | May leave sales forecast and enter finance/ERP process. | Sales manager, finance and data owner. |
Forecast — управленческий rhythm, не экран CRM. Если sellers обновляют opportunities только перед встречей, forecast отражает встречу. Если close dates не оспариваются, pipeline не реален. Если lost reasons не собираются, team не учится. Если quote/order вне CRM, отчеты нужны в finance/ERP.
Не обещайте идеальный forecast. Инструмент структурирует данные; дисциплина, cadence и rules определяют полезность.
Dynamics 365 Sales может быть источником для sales reporting. Но не каждый sales report должен быть решен внутри приложения CRM, и не каждое поле CRM должно стать KPI. Перед запросом Power BI dashboard, определите какие решения поддерживает отчет.
Полезные вопросы discovery:
Если dashboard простой, первая фаза может остаться внутри представлений и панелей управления Dynamics 365 Sales. Если dashboard пересекает данные CRM, 1С/ERP, finance, website или support, его стоит выделить в отдельный discovery Power BI/Fabric. Так scope Sales CRM остается честным: CRM-внедрение не должно незаметно поглотить проект BI-платформы, если команда сознательно не включала его в объем.
Эту границу полезно не скрывать: discovery Sales CRM готовит поля и процесс, а discovery Power BI - модель метрик, источники, обновление данных, доступ и governance.
Discovery должно включать минимальный baseline. Без него проект имеет чистые экраны и грязные records. Baseline показывает, какие данные нужны для первой фазы.
Минимальный baseline account/contact:
Minimum opportunity baseline:
Minimum migration baseline:
Для Казахстана: БИН, КП, договоры, филиалы, partner records, tender data — входы бизнеса, не юридические выводы. Если поле влияет на finance или procurement, владелец должен одобрить перед конфигурацией.
Microsoft Learn документирует quote, order, invoice. Для гайда это важно как граница scope: opportunities могут подключиться к quote/order, но не автоматически часть первого scope.
В B2B Казахстана quote/order может зависеть от местных процессов, 1С, finance approval, контрактов, счетов, logistics. Первая фаза CRM может нуждаться только в opportunity status. Позже — quote, order, contract, payment. Разные scopes.
Перед внедрением, спросите:
Гайд избегает ценообразования, налогов, юридического совета и ERP архитектуры. Если quote/order centrale, выделите в отдельный discovery. Иначе оценка CRM покажет pipeline, но скроет финансовые и интеграционные риски.
Используйте этот чеклист перед запросом оценки Dynamics 365 Sales. Он не должен быть идеальным. Он должен быть конкретным для содержательного разговора.
1. Sales process
Опишите, как продает команда: inbound, outbound, партнерский канал, тендеры/RFP, account management, продления или смешанные B2B-услуги. Сначала опишите текущий процесс обычным языком, потом обсуждайте поля.
2. Текущие инструменты
Перечислите файлы Excel, email, Teams, messenger channels, существующие CRM, web-формы, 1С/ERP, Power BI, Power Automate, телефонию, порталы и ручные отчеты. Отметьте какие инструменты должны остаться.
3. Роли
Перечислите sellers, sales managers, sales operations, CRM owner, IT/admin, finance, procurement, marketing, BI/data owner и любых региональных пользователей. Разделите деловую роль от потребности в безопасности/доступе.
4. Источники лидов и квалификация
Покажите откуда приходят лиды, кто их назначает, как обрабатываются duplicates, какая информация требуется и когда лид становится opportunity.
5. Accounts и контакты
Объясните account ownership, changes контактов, branch/customer grouping, duplicate policy, inactive records и кто может редактировать критические customer fields.
6. Opportunity stages
Определите stage names, entry criteria, exit criteria, required fields, close date logic, owner, next action и close reasons.
7. Forecast
Опишите категории прогноза, ритм пересмотра, иерархию, контекст квот (если используются), правила устаревших сделок и кто утверждает изменения прогноза.
8. Activities
Зафиксируйте, какие звонки, встречи, письма, заметки и задачи должны быть видны в CRM и что пользователи не должны дублировать вручную.
9. Отчетность
Назовите отчеты, которые нужны leadership, какие решения они поддерживают, какие fields их питают и находится ли Power BI в первом scope или будущем scope.
10. Интеграции
Перечислите Microsoft 365, web-формы, Power Platform, Power BI, Azure, 1С, ERP, finance или другие системы. Для каждой отметьте “phase one”, “future” или “not needed”.
11. Миграция данных
Объясните откуда приходят данные - из Excel, старой CRM или другого источника. Включите concerns по качеству данных, duplicates, историческое activities, owner mapping и что можно архивировать.
12. Контекст Procurement
Укажите, что это: неформальный discovery, коммерческое предложение, тендер/RFP, партнерская поддержка или подготовка внутреннего бюджета. Контекст закупки определяет, насколько детальным должен быть пакет scope.
Дорогие ошибки — не технические, а лингвистические.
«CRM» для всего. Sales CRM, Service, Power BI, веб-формы, интеграция, backlog — разные потоки, не одна задача.
Копирование Excel в CRM. Столбцы выглядят знакомо, но качество не растет.
Все поля обязательны. Обязательные поля защищают качество; неяс ные поля враждебны.
Forecast без hygiene. Forecast зависит от stages, dates, владельцев и discipline, не волшебство.
Скрывать интеграции. Если CRM подключается к 1С, веб-формам или finance — скажите рано.
Путать процесс-владельцев и роли безопасности. Разные решения.
Adoption = обучение. Пользователи принимают CRM, когда процесс помогает; обучение не исправит стадии или дубли.
После этого выберите:
Не заставляйте все в первую фазу. Хорошая первая фаза: pipeline, opportunities, roles, forecast. Позже: Power BI, quote/order, формы, интеграции, rollout.
Дата проверки: 9 июня 2026.
Microsoft Learn источники:
Не интерпретирует лицензирование, налоги, procurement правила, статус партнера, доступность или специфичную архитектуру. Не обещает результаты, даты, цены или поддержку.
Да, если первый scope сознательно ограничен sales pipeline, opportunities, activities, basic reporting and role model. Но даже такой старт должен описать lead sources, ownership, required fields, forecast expectations and data quality rules, иначе pipeline быстро превратится в еще один Excel внутри CRM.
Sales CRM discovery обычно включает интервью с sales owner, CRM owner and IT/admin, карту lead-to-opportunity процесса, pipeline stages, роли, required fields, forecast review, reporting needs, integrations, data migration expectations, access model and first-scope criteria. Это подготовка к оценке, не коммерческое предложение.
Связь с Microsoft 365 нужно описывать через рабочие сценарии: какие письма и активности должны фиксироваться, где проходят встречи, как team общается по сделкам, кто видит customer context and what must remain inside CRM. Конкретная настройка зависит от tenant, roles and security model.
Можно начать с возможностей Dynamics 365 Sales, если команде нужен CRM-level forecast по opportunities, categories and hierarchy. Power BI становится отдельным маршрутом, когда нужен cross-system dashboard, финансовые метрики, сложные модели, несколько источников данных или board-level reporting.
Интеграция нужна, когда сделка должна перейти в quote, order, договор, счет, оплату, shipment, customer master data or product catalog outside CRM. Если sales team только ведет opportunities and activities, интеграцию можно вынести в следующую фазу после проверки процесса.
Можно, но сначала нужно определить, какие records действительно нужны, какие поля совпадают с будущей моделью, кто владеет account/contact data, как обрабатывать duplicates, closed opportunities, owners, activities and historical notes. Миграция без очистки часто переносит старые проблемы в новую CRM.
Если Dynamics 365 или другая CRM уже используется, но есть backlog, ошибки, спорные роли, отчеты, workflows or integrations, лучше начать с support/backlog review. Новый Sales scope будет точнее, если сначала понять, что в текущем контуре работает, что сломано и что не принято пользователями.
Нет. Guide помогает подготовить вводные для разговора: процесс продаж, роли, pipeline, forecast, данные, reports, integrations and first-scope boundary. Коммерческое предложение должно строиться после discovery, source review, уточнения лицензий, tenant context, procurement route and acceptance criteria.
Используйте guide как pre-implementation worksheet: опишите pipeline, roles, lead qualification, forecast, reporting and integration boundaries. После этого можно идти в sales CRM discovery, а не просить оценку по одной строке.
