Понеділок починається із запитання про останню версію
Уявімо компанію, яка виготовляє продукцію на замовлення. Клієнт надсилає креслення, менеджер розраховує вартість, технолог додає умови. Після дзвінка змінюються кількість і строк. Наступного дня клієнт погоджує пропозицію. Але яку саме: вкладення з п’ятниці чи виправлення, надіслане у відповідь на інший лист?
Відділ продажу вважає справу завершеною, а людина, яка планує роботу, лише збирає відсутню інформацію. Складність не в підготовці ще одного PDF. Потрібно визначити, яка версія є обов’язковою для компанії, хто її погодив і чи можна на її основі починати виконання.
Що зупиняє роботу?
Початкова ситуація
Запит без відповідального
Повідомлення потрапляє до спільної скриньки, але відповідальну людину й строк наступної дії не визначено. Відсутність відповіді стає помітною лише після дзвінка клієнта.
Розрахунок змінюється після надсилання
Таблиця одночасно виконує роль калькулятора й архіву. Коригування собівартості перезаписує дані, на основі яких раніше сформували пропозицію клієнтові.
Продаж завершено, але почати роботу ще неможливо
Погоджена ціна не означає повного набору домовленостей. Бракує креслення, підтвердження матеріалу або рішення щодо доставки; виконавцям доводиться відновлювати перебіг розмови.
Проєктуємо історію рішень, а не ще одну поштову скриньку
Основний елемент застосунку — комерційна справа: клієнт, потреба, документи, відповідальна людина та найближчий крок. Пропозиція має окремі версії, а надсилання закриває конкретну версію для редагування. Зміна створює наступну версію замість перезаписування історії.
Відокремлюємо погодження клієнта від готовності до виконання. Для другого потрібен визначений набір інформації. Завдяки цьому система не передає далі замовлення, ключові параметри якого ще обговорюються.
Так може виглядати новий процес
Зафіксуйте потребу та наступну дію
Запит потрапляє до черги з відповідальним, строком відповіді й переліком того, чого бракує. Під час наступного контакту працівник бачить контекст, а не лише назву файла.
Підготуйте розрахунок з умовами
Калькуляція містить позиції, припущення та строк чинності. Нетипова знижка або умова оплати може вимагати внутрішнього погодження до формування документа.
Збережіть конкретне погодження
Підтвердження вказує версію пропозиції та спосіб отримання рішення. Часткове погодження або прохання про зміну запускає відповідний крок, а не автоматичне закриття справи.
Передайте повний комплект на виконання
Виконавці отримують погоджений обсяг, вкладення, строк і примітки. Якщо ERP уже працює, визначаємо, які дані передавати через інтеграцію, замість створення другого реєстру замовлень.
Головний екран показує, що потребує реакції
Власникові компанії зазвичай не потрібна ще одна дошка з кольоровими статусами. Йому важливо знати, які справи зупинилися, чого в них бракує та хто може ухвалити рішення. Тому робочий екран упорядковуємо за наступною дією, а докладну історію залишаємо в конкретній справі.
- Менеджер із продажу бачить свої запити та строки відповіді.
- Людина, яка погоджує умови, отримує лише справи, що потребують її рішення.
- Виконавці бачать погоджений обсяг; доступ до маржі визначаємо окремо.
Винятки — частина процесу
Клієнт може повернутися до пропозиції зі строком, що сплив, змінити одержувача рахунка або замовити лише частину позицій. Команда також має вміти об’єднувати дубльовані запити без втрати повідомлень. Визначаємо, коли справу можна відновити, а коли потрібен новий розрахунок. Історія змін і вкладення з підтвердженням рішення допомагають розв’язати сумніви згодом.
Почнімо з одного фрагмента, який працює.
Вдалий перший етап охоплює один тип запиту, просту калькуляцію, версійність пропозиції та передавання одній відповідальній людині з боку виконання. Обираємо регулярний шлях із чіткими умовами погодження. Розгорнутий конфігуратор цін, клієнтський портал та інші інтеграції можна додати після перевірки цього процесу в щоденній роботі.
Як зрозуміємо, що стало краще?
Це план вимірювання, а не обіцянка результату. Початкові показники визначаємо до впровадження.
Час до першої змістовної відповіді
Порівнюємо час від реєстрації до відповіді по суті, відокремлюючи автоматичне підтвердження від відповіді менеджера та враховуючи робочі години.
Повнота передавання
Перевіряємо, скільки погоджених замовлень повертається через відсутню інформацію та які поля або документи найчастіше заважають почати роботу.
Справи без наступного кроку
Відстежуємо кількість відкритих питань без відповідального або строку. Саме зростання кількості надісланих пропозицій ще не доводить, що процес покращився.
Запитання, які варто поставити
Чи потрібно замінювати поточну CRM?
Не завжди. Спочатку з’ясовуємо, чого бракує: правильного налаштування CRM, зв’язку з калькулятором чи окремого модуля пропозицій. Додатковий застосунок має сенс, якщо закриває конкретну прогалину й не створює ще одного місця для ручного перенесення даних.
Чи може система сама надсилати пропозиції?
Може, якщо погодимо такі правила. На першому етапі часто краще автоматизувати підготовку документа, а надсилання залишити працівникові. Особливі ціни, зобов’язання щодо строків і нестандартні умови повинні мати зрозумілий маршрут погодження.
