Як вести облік заявок без CRM: таблиця для малого бізнесу

Щоб вести облік заявок без CRM, створіть таблицю, де кожен рядок відповідає окремому запиту або угоді. Запишіть дату, джерело, коротку задачу, етап, відповідального, наступну дію та її дату. Домовтеся, хто оновлює записи і як команда перевіряє незавершені звернення.

На невеликому потоці така таблиця допомагає навести лад без складного впровадження. Вона потребує регулярного оновлення та обмеження доступу і не автоматично замінює історію контактів, нагадування й інші функції CRM.

Як почати облік заявок

Як почати облік за один робочий день

Спочатку випишіть усі місця, звідки надходять звернення: пошта, телефон, форма чи сторінка в соціальній мережі. Визначте, хто переносить запис у спільну таблицю і за яким правилом перевіряє повторні звернення. Одна людина може відповідати за кілька джерел, але кожне джерело повинно мати власника процесу.

Далі внесіть поточні відкриті запити, для яких ще потрібна дія. Не намагайтеся за один день реконструювати повну історію, якщо достовірних даних немає. Позначте дату початку обліку та випадки, де джерело або попередня домовленість невідомі.

Наприкінці дня перегляньте, чи є у кожного відкритого запису відповідальний. Якщо наступну дію ще не узгодили, запишіть, яку інформацію треба уточнити, замість вигаданої домовленості. Наступного тижня команда зможе оцінити, які поля справді допомагають роботі.

Визначте, що є окремим записом

Перш ніж створювати колонки, домовтеся про одиницю обліку. Повторне повідомлення про ту саму задачу зазвичай є продовженням наявного запису. Два окремі проєкти однієї компанії можуть бути двома угодами, якщо ви по-різному оцінюєте їхній обсяг та результат.

Запишіть правило й використовуйте його послідовно. Якщо клієнт написав у соціальній мережі, а потім зателефонував, перевірте, чи вже є відповідний запис. Інакше дві комунікації можуть штучно збільшити кількість заявок. Водночас не об’єднуйте різні замовлення лише тому, що вони від однієї людини.

Як організувати джерела звернень

Для кожного каналу визначте місце перевірки і людину, яка заносить запит. Якщо один клієнт спочатку заповнив форму, а потім написав у месенджері, звірте задачу і наявний запис. Джерелом можна вказати перший відомий контакт або інше погоджене правило, але не змінюйте його залежно від бажаного звіту.

Якщо джерело невідоме, так і позначте. Не припускайте, що кожен клієнт із пошукової реклами обов’язково прийшов лише через неї. UTM-мітки можуть допомагати розрізняти переходи, але збереження даних у таблиці чи CRM потребує окремого процесу.

Які поля потрібні для першої таблиці

Для невеликої команди можна почати з таких колонок:

1. Номер або умовний ідентифікатор: допомагає знайти запис без дублювання.
2. Дата звернення: коли отримали запит.
3. Джерело: звідки людина звернулася, якщо це відомо.
4. Коротка задача: що клієнт хоче вирішити, без надмірних деталей.
5. Етап: поточний стан за спільним визначенням команди.
6. Відповідальний: хто веде звернення.
7. Наступна дія і дата: конкретний погоджений крок.
8. Результат: оплата, відмова або інший визначений стан.

Додайте контактні дані лише за потреби та відповідно до правил вашої організації. Не зберігайте паролі, дані банківських карток чи конфіденційні документи в загальній таблиці. Доступ має відповідати ролям команди.

Приклад запису для майстерні

Уявімо, що меблева майстерня отримала запит щодо шафи. Вона створює запис 014: дата звернення, джерело «телефон», задача «шафа за розмірами клієнта», етап «уточнення потреби», відповідальний менеджер і наступна дія «отримати попередні розміри». Дата дії зазначається відповідно до домовленості з клієнтом.

Після уточнення розмірів команда змінює етап, записує погоджений склад роботи і, якщо надає кошторис, зазначає наступний крок. Оплату фіксує за своїм правилом обліку після підтвердження. Це умовний приклад, а не історія клієнта FBD.

Якщо людина звернулася повторно щодо тієї самої шафи, команда оновлює запис 014. Якщо пізніше просить виготовити окремий стіл, правило компанії може передбачати нову угоду. Зберігайте логіку однаковою, щоб зведення не змішувало дії з кількістю запитів.

Як визначати етап і результат

Як узгодити етапи продажу

Для старту можна використати звернення, кваліфіковане звернення, пропозицію та оплату. У статті про воронку продажів розібрано умови переходу та приклад конверсії. Ваш процес може мати інші етапи: важливо, щоб кожен означав зрозумілу зміну стану.

Поруч визначте статуси «відкрито», «закрито з оплатою» і «закрито без оплати» або іншу систему, що відповідає вашому обліку. Якщо причина відмови невідома, так і запишіть. Не вважайте відкриту угоду відмовою лише тому, що клієнт ще не відповів.

Зміна етапу і наступна дія це різні поля. «Пропозицію надіслано» описує стан, а «уточнити рішення у погоджений день» описує дію. Не змушуйте команду пересувати записи між етапами без реальної підстави лише заради красивого звіту.

Як фіксувати різні результати

Домовтеся, що вважається завершеною оплатою, а що відмовою. Якщо клієнт ще очікує відповіді чи має передати дані, залишайте запис відкритим. За відомої причини відмови використовуйте конкретне формулювання, яке відповідає словам клієнта; за відсутності даних залишайте причину невідомою.

Для повторного замовлення визначте, чи створюється новий запис. Правило має відповідати тому, що ви рахуєте: клієнтів, звернення чи угоди. Одна людина може зробити кілька покупок, тому ці показники не можна автоматично підміняти один одним.

Зведення за тиждень допомагає побачити потік та прострочені дії. Для конверсії між етапами потрібно простежити одну групу звернень і дати їй достатньо часу на рішення. Докладніше про знаменники та приклад розрахунку читайте у воронці продажів.

Шаблон FBD і таблиця окремих угод

Шаблон воронки продажів FBD містить зведені показники за період: звернення, кваліфікацію, пропозиції, оплати, виторг і наступну дію. У ньому є умовний приклад, який потрібно відокремити або замінити власними даними.

Цей CSV не є базою контактів і не містить окремого рядка для кожної угоди. Для щоденної роботи створіть окрему таблицю записів за полями вище, а зведений шаблон використовуйте для підсумку. Щоб порахувати конверсію однієї групи, потрібен достатній час для проходження етапів, а не просто ділення всіх оплат місяця на нові заявки того самого місяця.

Як працювати із заявками командою

Для передачі заявки домовтеся про один момент зміни відповідального: наприклад, після підтвердження, що колега прийняв задачу. У записі залиште поточний етап, узгоджений наступний крок і дату. До підтвердження передачі попередній відповідальний знає, хто має перевірити, що клієнт отримав відповідь.

Як організувати щотижневий перегляд

Раз на узгоджений період перегляньте відкриті записи. Знайдіть ті, де немає відповідального, наступної дії або дати. Уточніть, чи дія погоджена з клієнтом, чи не минув строк і чи є інформація, потрібна для відповіді.

Костянтин Тріпайло звертає увагу на угоди без наступного кроку як на один із сигналів для управлінського перегляду. Цей підхід розглянуто в матеріалі «Міністерства з Продажів» про управління за даними. Це партнер FBD; його комерційні послуги є окремими від освітніх матеріалів ГО.

Не перетворюйте перегляд на оцінку людей лише за кількістю дзвінків. Важливо, чи клієнт отримав відповідь, чи зрозуміла задача і чи виконано домовленість. Записуйте одну перевірювану зміну, якщо помітили повторювану проблему.

Приклад щотижневого підсумку

Уявімо, що команда отримала 20 нових звернень, а ще п’ять були відкритими з попереднього тижня. Це 25 поточних записів, але не 25 нових клієнтів. Якщо чотири записи очікують відповіді команди, перевірте їхні терміни і відповідальних. Окремо зазначте угоди, для яких клієнти ще ухвалюють рішення.

Не діліть усі оплати тижня на 20 нових звернень, якщо вони належать різним групам. Для конверсії простежте окрему групу до достатнього строку завершення. Операційне зведення і аналіз воронки відповідають на різні запитання.

Як передавати звернення колезі

Якщо клієнта веде інший працівник, передайте узгоджений мінімум: задачу, поточний етап, відомі умови й наступну дію. Після передачі оновіть відповідального, щоб двоє людей не вважали, що відповідає хтось інший. За потреби повідомте клієнту про зміну контакту.

Не копіюйте зайві особисті дані в кілька файлів. Перевіряйте, хто має доступ до робочої таблиці, і користуйтеся погодженим каналом для передачі інформації.

Як захистити робочу таблицю

Обмежте доступ тим, кому він потрібний для роботи, використовуйте окремі облікові записи та переглядайте права після зміни ролей. Зберігайте лише інформацію, потрібну для обробки звернення. Публічний шаблон має містити умовні приклади, а не записи реальних клієнтів.

Визначте, хто відповідає за копії файлу та актуальність даних. Якщо кілька людей одночасно редагують таблицю, домовтеся, де зберігається основна версія і як виправляти помилки. Юридичні вимоги до персональних даних залежать від конкретного процесу, тому перевіряйте їх у відповідних фахівців.

Коли таблиці може не вистачити

Коли розглянути CRM

Якщо команда втрачає історію контактів, не бачить прострочених задач або працює з багатьма паралельними каналами, перевірте, яких функцій бракує. Не купуйте систему лише тому, що список заявок став довгим. Спочатку опишіть процес, ролі, дані та спосіб оцінки пілоту.

Стаття про підготовку до CRM допоможе сформулювати вимоги. Перенесення таблиці не зробить етапи правильними автоматично: правила й відповідальність залишаються за командою.

Коли таблиці стає недостатньо

Проблемою може бути не сама кількість рядків, а те, що команда не бачить історію контакту, не встигає оновлювати записи або не може обмежити доступ до потрібних даних. Запишіть конкретну ситуацію: хто не отримав інформацію, яке рішення затрималося і яка функція могла б допомогти.

Потім порівняйте зміну процесу з впровадженням CRM. Для обох варіантів визначте час команди, відповідального та спосіб перевірки. Новий інструмент має підтримувати погоджені етапи, а не змушувати компанію штучно копіювати чужий процес.

Перевірка перед переходом до CRM

Опишіть два або три процеси, які таблиця не підтримує: наприклад, нагадування, історію контактів або розподіл доступів. Потім перевірте, які функції потрібні справді зараз і хто ними користуватиметься. Заплануйте тест на невеликій групі записів без зайвих персональних даних.

Перед перенесенням узгодьте назви колонок та етапів, усуньте дублікати й збережіть правило оновлення. Впровадження системи не виправить помилкові дані автоматично. Після тесту з’ясуйте, чи команда бачить наступні дії та може працювати без подвійного внесення інформації.

Читайте також

Якщо заявок достатньо, але покупок мало, перегляньте як дослідити причини відмов. Для узгодження показників команди використайте дерево KPI.

Поширені запитання

Чи достатньо таблиці для малого бізнесу?

Це залежить від обсягу, складності звернень і кількості людей у команді. Таблиця може бути стартом, якщо вона актуальна і забезпечує потрібний контроль та доступ.

Чи є CSV-шаблон FBD базою клієнтів?

Ні. Він призначений для зведених показників за період. Історію окремих звернень потрібно вести окремо.

Що робити, якщо заявка не завершилася цього місяця?

Залиште її відкритою із наступним кроком і перегляньте пізніше. Для аналізу конверсії використовуйте одну зіставну групу звернень та достатній час на рішення.