Краткий ответ
Sales Cloud управляет развивающейся сделкой — рабочей единицей, которая живет недели или месяцы, измеряется вероятностью закрытия и считается успешной, когда она закрыта. Service Cloud управляет обращением, которое решается — рабочей единицей, которая живет часы или дни, измеряется временем отклика и решения и считается успешной, когда она закрывается быстро и без повторного открытия.
Именно это различие, а не список функций, определяет выбор. Если вы управляете воронкой продаж (Pipeline) — Sales Cloud. Если вы управляете очередью с SLA — Service Cloud. Если вы управляете клиентом, который и покупает, и жалуется — используйте обе системы на одном объекте Account.
Различия в операционных терминах
| Параметр | Sales Cloud | Service Cloud |
|---|---|---|
| Центральный объект | Opportunity | Case |
| Жизненный цикл | От недель до месяцев | От часов до дней |
| Ключевой показатель | Win rate, Forecast accuracy | First response, FCR, CSAT |
| Механизм распределения | Персональное владение на длительный срок | Динамическая маршрутизация по доступности |
| Источник нагрузки | Количество активных сделок | Непредсказуемые пики по каналам |
| Компонент знаний | Playbooks и ценообразование | Встроенная база знаний |
Самая важная строка — это механизм распределения. В продажах персональное владение является ценностью — клиент хочет иметь постоянного контактного менеджера. В обслуживании персональное владение является проблемой — оно создает индивидуальные очереди, которые застревают, когда представитель в отпуске.
Когда выбор очевиден
Только Sales Cloud подходит для организации, которая продает в непрерывном процессе и где послепродажная поддержка минимальна или осуществляется партнером — например, поставщик оборудования, продающий через дилеров и не имеющий собственного центра поддержки.
Только Service Cloud подходит для организации, все взаимодействие которой с клиентом сводится к обработке запросов — операционная сервисная компания, государственное учреждение или поставщик инфраструктуры с действующими контрактами.
Обе системы необходимы, когда есть продление, допродажи (Upsell) или удержание: как только сервисный представитель должен знать, что клиент находится в процессе продления, а представитель по продажам должен знать, что клиент открыл три серьезные проблемы в этом месяце — разделение становится препятствием.
Как объединить без дублирования данных
Именно на этом этапе интеграционные проекты терпят неудачу. Правило: Account и Contact — это один общий уровень. Нет отдельных "клиентов по продажам" и "клиентов по обслуживанию".
Отсюда вытекают три ключевых решения:
- Ответственность за записи клиентов — кто обновляет контактные данные, адрес и организационную структуру. Обычно это служба поддержки, поскольку она чаще общается с клиентом.
- Взаимная видимость — сервисный представитель видит открытые сделки только для чтения; представитель по продажам видит открытые проблемы и показатель удовлетворенности. Оба направления определяются моделью совместного доступа (Sharing Model), а не копированием полей.
- Кросс-функциональные триггеры — критическая проблема у клиента, находящегося в процессе продления, генерирует оповещение для менеджера по работе с клиентами. Этот механизм ценнее любого комбинированного дашборда.
Подробная информация о разрешениях и видимости представлена в Модель Sharing и видимости в Salesforce.
Лицензирование: что важно знать перед сравнением цен
Лицензия Service Cloud является надмножественной — она включает базовые возможности Sales Cloud, поэтому пользователь, которому нужны обе системы, не нуждается в двух лицензиях. Обратное неверно: лицензия Sales не включает управление обращениями (Case management), права (Entitlements) или базу знаний (Knowledge).
Практическое значение: правильный расчет стоимости начинается с сопоставления пользователей по тому, что они на самом деле делают, а не по отделу, к которому они принадлежат. Представитель, который дважды в год касается сделки, не является пользователем продаж.
Порядок внедрения, когда нужны обе системы
Параллельное внедрение кажется эффективным, но на самом деле удваивает риск: два процесса, которые изменяются одновременно, две группы пользователей на обучении, и невозможность отнести улучшение или сбой к конкретному источнику.
Рекомендуемый порядок — начать со стороны с более измеримой проблемой — обычно это обслуживание, поскольку время отклика и отток измеряются уже сегодня — и добавить вторую сторону после двух месяцев стабильной работы. Общий уровень (Account, Contact, разрешения) строится на первом этапе, даже если только одна сторона запускается, иначе второй этап потребует перестройки.
Заключение
Вопрос не в том, какой продукт лучше, а в том, какой рабочий блок управляется организацией: развивающаяся сделка или решаемое обращение. Большинство зрелых организаций управляют обоими, и тогда настоящее решение заключается не в том, что купить, а в том, как поддерживать единый уровень клиента под обоими.