Завдання
Зрозуміти бажаний результат і умови запиту, не підміняючи невідомі відомості припущеннями.
Модельний сценарій · Кваліфікація заявок
Підготовка заявки до предметної розмови з менеджером
Модельний сценарій для вхідних запитів на послугу: асистент уточнює завдання, збирає відомі умови й передає менеджерові заявку з обґрунтованим наступним кроком.
Склад сценарію
Склад сценарію
Починаємо після того, як людина виявила інтерес до послуги. Завдання — підготувати корисні відомості для продовження розмови.
Рішення
Налаштувати короткі уточнення, правила фіксації відповідей і маршрути за змістом заявки.
Очікуваний ефект
На пілоті перевірити, чи дає підготовлена заявка менеджерові змогу вибрати наступний крок без зайвого повторення.
Архітектура рішення
Архітектура рішення
Діалог збирає факти, правила визначають маршрут, а менеджер ухвалює індивідуальні комерційні рішення.
Опис пропозиції
Погоджені напрями послуги, допустимі умови й запитання, що впливають на наступний крок.
Уточнення потреби
Бажаний результат, вихідна ситуація, відомі обмеження та параметри, які ще потрібно з’ясувати.
Передавання до відділу продажів
Резюме відповідей, пояснення вибраного маршруту й відкриті запитання для менеджера.
Від інтересу до наступного кроку
Невідомий бюджет або строк можна зберегти як запитання; людині не потрібно вигадувати відповідь заради завершення форми.
- 01
Початковий запит
Зафіксувати завдання, що цікавить людину, та вже названі нею умови.
- 02
Ключові уточнення
Поставити запитання, які справді допомагають вибрати напрям і продовження розмови.
- 03
Перевірка розуміння
Коротко відтворити суть запиту й дати можливість виправити або доповнити відповіді.
- 04
Вибір маршруту
Застосувати погоджені правила за змістом заявки й показати причину наступного кроку.
- 05
Передавання менеджерові
Передати підтверджені відомості й невирішені запитання доступним способом.
Етапи впровадження
Етапи впровадження
Правила уточнень обговорюємо з тими, хто приймає заявки та готує пропозицію.
01
Діагностика
Порівняти приклади вхідних запитів і визначити, яких відомостей менеджерові бракує для продовження.
02
Архітектура
Погодити зміст полів, обов’язкові й додаткові запитання, статуси та маршрути.
03
Пілот
Перевірити неповні відповіді, зміну умов, прохання про менеджера та запит поза вибраним напрямом.
Критерії перевірки
Критерії перевірки
Кваліфікація має пояснювати стан запиту, а не навішувати необґрунтовану оцінку на людину.
- 01
Точність відомостей
У заявці відображені повідомлені умови, а невідоме не перетворене на відмову чи негативну відповідь.
- 02
Обґрунтований маршрут
Наступний крок відповідає погодженому правилу та підтверджується змістом розмови.
- 03
Корисність для менеджера
Одержувач бачить потребу, критерії вибору й запитання, з яких слід продовжити обговорення.
Докладно про тему
Як кваліфікувати вхідний запит без втрати його змісту
Людина вже зацікавилася послугою
Уявімо компанію з кількома напрямами послуг. Вхідний запит може бути докладним, а може складатися з фрази «хочемо розв’язати таке завдання, підкажіть варіант». Менеджерові потрібно зрозуміти вихідну ситуацію, бажаний результат і те, які умови вже відомі. У модельному сценарії асистент допомагає підготувати цю основу для розмови, не замінюючи обговорення індивідуальної пропозиції.
Розглядається робота із запитами людей, які самі звернулися або погодилися продовжити діалог. Масові розсилки й самостійний пошук контактів до цього прикладу не входять. Кваліфікація тут означає уточнення змісту заявки та вибір наступного кроку. Це не обіцянка вгадати, хто купить послугу, і не оцінка цінності людини за неповною інформацією.
Спочатку визначають, що потрібно знати менеджерові
Список запитань складають на основі реальних завдань відділу продажів. Наприклад, який результат потрібен клієнтові, як процес улаштований зараз і які системи вже використовуються. Для кожного запитання корисно пояснити, як відповідь вплине на продовження: вибір фахівця, підготовку прикладу чи потребу в окремому обговоренні. Поле, яке збирають лише за звичкою й ніде не використовують, може виявитися зайвим.
Зміст відповіді також потребує домовленості. Бажаний строк початку та крайня дата результату — різні відомості. Орієнтир бюджету відрізняється від уже погодженого бюджету проєкту. Якщо людина поки не знає параметра, у заявці так і позначають. Відсутність відповіді не можна автоматично перетворювати на негативну ознаку: менеджерові важливо розуміти невизначеність, а не отримувати видимість заповненої анкети.
Діалог не має виглядати як повторювана форма
Асистент починає з уже отриманого контексту й ставить короткі уточнення за змістом розмови. Якщо людина одразу описала поточний процес і бажаний результат, повторно запитувати про це не потрібно. За неоднозначного формулювання краще пояснити, яку деталь потрібно уточнити. Наприклад, слово «інтеграція» може означати отримання відомостей, запис результату або обидва напрями обміну.
Людина має право запитати про послугу під час уточнень. Відповідь за затвердженими матеріалами допомагає їй зрозуміти, чи підходить подальше обговорення. Після цього можна повернутися до запитання, що залишилося, зберігши попередні відповіді. Пряме прохання про менеджера враховують як окремий маршрут. Збирання додаткових деталей не має ставати перешкодою для розмови з фахівцем.
Як відокремити потребу від запропонованого рішення
Клієнт може назвати конкретний інструмент, хоча описана проблема пов’язана із ширшим процесом. У заявці корисно зберегти й уподобання, і саму потребу. Наприклад, людина хоче помічника в месенджері, щоб працівникам було зручніше отримувати відомості з внутрішніх файлів. Інтерфейс тут є побажанням, а доступ до потрібної інформації — очікуваним результатом.
Асистент не підтверджує технічної сумісності чи складу робіт лише на підставі назви сервісу. Ці деталі потребують окремої перевірки. У резюме можна позначити використовувані інструменти й потрібну дію, а непідтверджене підключення залишити запитанням до менеджера. Такий підхід дає змогу обговорити альтернативи, не створюючи в клієнта враження, що конкретне рішення вже обіцяне.
Чому вибраний маршрут має бути обґрунтованим
Після уточнень заявку можна направити фахівцеві відповідного напряму або залишити для додаткового розгляду. Підставу маршруту задають заздалегідь і пов’язують із фактичними відповідями. Наприклад, у запиті явно потрібна робота з внутрішніми документами або обговорюється розміщення на власній інфраструктурі. Причина має бути зрозумілою працівникові, який приймає заявку та зможе перевірити її за розмовою.
У цьому модельному сценарії не використовується вигаданий відсоток імовірності купівлі. Якщо компанії потрібна система статусів, зміст кожного стану погоджують окремо. Позначка «потрібне уточнення» відрізняється від «не підходить вибраний напрям», а відсутність бюджету — від відмови обговорювати проєкт. Статус допомагає організувати роботу лише тоді, коли не приховує цих відмінностей.
Що робити, якщо відповіді змінилися
Під час розмови людина може згадати важливе обмеження або виправити початковий строк. Асистент має враховувати уточнення в поточному резюме й за потреби переглянути маршрут. Інакше менеджер отримає застарілий запит, хоча потрібна інформація вже з’явилася. Користувачеві корисно показати коротке підсумкове формулювання й дати можливість підтвердити або виправити його.
Повернення до заявки пізніше потребує правил роботи зі збереженим контекстом. Потрібно розуміти, які відомості стосуються попередньої розмови та які змінилися зараз. Можливість продовження залежить від вибраного інтерфейсу, ідентифікації та прав доступу. Не можна обіцяти впізнавання людини в усіх каналах або об’єднувати заявки лише через схожі відповіді.
Які відомості доходять до менеджера
Підсумковий запис має допомагати готуватися до предметної розмови. У ньому можна розділити потребу, поточну ситуацію, критерії вибору й відкриті запитання. Бажання клієнта зберігаються як бажання, а підтверджені обмеження — як обмеження. Асистент не додає непідтвердженої готовності укласти договір, повноважень співрозмовника чи згоди на запропоновані умови.
Передавання до CRM або іншого інструмента обговорюють з урахуванням доступних інтерфейсів і потрібних полів. Перевіряють створення чи оновлення запису, збереження відповідей і обробку повторного надсилання. Якщо операція не підтверджена системою, статус не має повідомляти про успішне передавання. Менеджерові та користувачеві потрібен зрозумілий наступний крок, а не формальне завершення діалогу.
Як оцінити пілот і підготувати завдання
Для перевірки вибирають заявки з різним рівнем визначеності: докладну, коротку, із суперечливими строками, без бюджету та із запитом поза вибраним напрямом. Окремо перевіряють виправлення відповідей і прохання одразу підключити людину. Менеджер порівнює підсумок із початковою розмовою та позначає, які відомості допомогли, які були втрачені та які запитання поставлені без потреби.
Для обговорення впровадження з ASK ARMONIVO підготуйте знеособлені приклади заявок і поясніть, що потрібно знати перед першою предметною розмовою. Можна показати прийняту форму запису й наявні маршрути відділу продажів. Після уточнення сценаріїв, полів, правил і підключень визначають склад робіт і вартість. Результати пілота оцінюють за вашим процесом, не підміняючи їх заздалегідь обіцяною конверсією.
Питання та відповіді
Коротко про головне
01Це реальний кейс відділу продажів?+
Ні. Це модельний сценарій, що показує можливу підготовку заявки. Він не підтверджує результатів конкретної компанії чи зростання продажів.
02Чим він відрізняється від приймання звернення із сайту?+
Приймання фіксує запитання й контакт. Тут докладніше розглядаються потреба, критерії вибору, невизначені параметри та правила наступного кроку перед розмовою з менеджером.
03Чи зобов’язана людина назвати бюджет?+
Ні. Невідомий параметр можна зберегти як запитання для подальшого обговорення. Правила обов’язкових відомостей визначають за завданням, не змушуючи людину вигадувати відповідь.
04Чи оцінюватиме асистент імовірність купівлі?+
Такий прогноз до описаного сценарію не входить. Маршрути та стани заявки визначаються погодженими правилами за змістом розмови.
05Чи можна виправити раніше повідомлені умови?+
Так, таку можливість потрібно передбачити в діалозі. Підсумкове резюме й наступний крок мають враховувати підтверджене уточнення.
06Чи може клієнт одразу перейти до менеджера?+
У модельному сценарії прохання про фахівця обробляється окремо. Додаткові запитання не повинні перешкоджати передбаченому передаванню.
07Чи обіцяє асистент конкретну інтеграцію або ціну?+
Він може передавати лише затверджені відомості. Індивідуальна вартість і технічна сумісність потребують окремого обговорення та перевірки.
08Що потрібно для розрахунку вартості такого впровадження?+
Приклади вхідних запитів, потрібні менеджерові відомості, правила маршрутизації та використовувані інструменти. Після їх уточнення визначають склад робіт і розраховують вартість.
Обговорити проєкт
Визначимо, що важливо знати перед розмовою
Покажіть приклади заявок і розкажіть, за якими відомостями менеджер вибирає наступний крок. Обговоримо сценарій уточнень і передавання.
Обговорити проєкт