Коли замовлення приходять із сайту, торгового майданчика та листування, менеджер витрачає час на пошук контексту. KeyCRM може стати спільним робочим місцем для цих звернень і замовлень. Але підключені канали ще не створюють узгодженого процесу: команді потрібні правила, що вважати новим клієнтом, хто відповідає за замовлення та коли змінюється його стан.
Розділіть клієнта, звернення та замовлення
Одна людина може написати в чаті, оформити замовлення й пізніше зателефонувати. Це не обов’язково три нові клієнти. Водночас повторна покупка тієї самої людини є новим замовленням. До перенесення бази погоджують правила пошуку дублів: як використовуються телефон, email та ідентифікатор джерела, і які випадки менеджер перевіряє вручну.
В офіційній довідці KeyCRM замовлення, покупці, компанії та товари розглядаються як пов’язані сутності. Для впровадження важливо перенести цей поділ у ваші робочі домовленості. Наприклад, одержувач посилки може відрізнятися від покупця — їхні контакти не варто автоматично змішувати.
Джерело має пояснювати походження замовлення
Для кожного каналу визначте спосіб створення замовлення, доступні поля та відповідального за перевірку. Джерело допомагає зрозуміти контекст продажу й знайти первинний запис. Якщо сайт передає власний номер замовлення, його потрібно зберігати у погодженому полі. Це полегшує пошук під час збою та перевірку, чи не надійшла та сама операція повторно.
-
Зіставте назви полів і формат контактів у кожному джерелі.
-
Визначте, звідки надходять артикули, ціни та залишки.
-
Погодьте, хто бачить невдало передані замовлення.
Статус повинен означати завершену дію
Стани «нове», «підтверджене» та «відправлене» корисні лише з чіткими умовами переходу. Підтвердження може вимагати зв’язку з клієнтом, а відправлення — оформленої посилки. Якщо менеджери використовують однакові назви по-різному, звіт не пояснить, що відбувається насправді. Окремо опишіть скасування, відмову від отримання та повернення.
Навчальний приклад: звернення з двох каналів
Покупець залишив замовлення на сайті та додатково написав у месенджері, щоб змінити адресу. Під час тестування потрібно перевірити, чи менеджер знаходить потрібне замовлення, чи зберігається попередній контекст і чи зміна не створює другу продажу. Після відправлення варто звірити адресу, склад замовлення та пов’язаний документ доставки.
У підготовці KeyCRM в ALL IT Agency такий сценарій перетворюємо на приймальний тест. Він перевіряє одразу кілька частин: джерело, картку клієнта, роботу менеджера й інтеграцію доставки. Це дає більше інформації, ніж демонстрація порожнього кабінету з налаштованими кольорами статусів.
Що погодити перед переходом команди
Запустіть обмежений пілот на погоджених замовленнях. Пройдіть стандартну покупку, повторне звернення й повернення. Призначте власника довідників та людину, яка змінює налаштування. Можливості каналів, автоматизації та прав перевіряйте для конкретного робочого простору: умови продукту й інтеграцій можуть змінюватися.
Джерела та подальше читання
