Как учитывать заявки с сайта: таблица от первого обращения до результата
Начните с одной строки на самостоятельный запрос клиента. Сохраните дату первого обращения, отдельно отметьте, подходит ли задача вашему бизнесу, и назначьте ответственного со следующим действием. Тогда таблица покажет не только количество заявок, но и те обращения, которые застряли без ответа или решения. Ниже — схема для небольшой компании услуг, заполненный пример и порядок работы на каждый день.
Начните с вопроса: какое обращение требует нашего действия?
После запуска сайта заявки могут приходить в форму, почту, телефон и мессенджер. Пока все обращения помнит один человек, кажется, что отдельный учёт избыточен. Проблема становится заметной, когда клиенту уже обещали расчёт, а в переписке нельзя быстро найти, кто его готовит и к какому сроку.
Рабочий журнал должен отвечать на три вопроса: что клиенту нужно, что уже произошло и кто делает следующий шаг. Отчёт о количестве обращений получается из этих записей. Если таблица заполняется только перед совещанием по памяти, она не помогает сотруднику выполнить обещание и постепенно расходится с реальностью.
Для начала возьмите все входящие запросы на услуги, в том числе звонки и обращения через контакты на сайте. Тесты формы, спам, предложения поставщиков и отклики соискателей помечайте отдельно, чтобы они не попадали в число потенциальных заказов. Если принадлежность сообщения непонятна, оставьте его на проверке. Не удаляйте сомнительные обращения только ради красивого отчёта.
Сначала убедитесь, что запрос действительно доходит до сотрудника. Никакая таблица не восстановит сообщение, которое форма не доставила. Для проверки пройдите путь посетителя от заполнения до получения уведомления и ответа на контролируемый контакт. После этого можно налаживать ежедневную обработку.
Одна строка — один запрос, а не одно сообщение
Единица учёта в этой схеме — самостоятельная потребность, по которой компания может получить отдельный заказ. Присвойте ей постоянный номер, например J-001. Повторное письмо с уточнением сроков дополняет эту запись. Оно не создаёт ещё одну заявку.
Клиент отправил форму, а через час спросил в WhatsApp, дошло ли сообщение. Если это тот же человек и та же задача, перед вами одна заявка и два контакта по ней. Запишите второе обращение в краткую историю. Не объединяйте записи по одному совпавшему имени: сначала сопоставьте контакт, содержание и обстоятельства запроса.
Обратная ситуация: действующий клиент заказал сайт, а позже обратился за отдельной рекламной кампанией. Контакт общий, потребности и решения разные — создайте новую строку и укажите связь с прежним запросом. Если второй сотрудник той же компании уточняет исходный проект, это обычно продолжение первой заявки. Правило определяет задача, а не число email-адресов.
При возвращении к отложенному проекту сохраняйте исходный номер и дату поступления. Добавьте дату возобновления и новое действие. Когда обсуждается другой объём как самостоятельный заказ, создавайте связанную запись. Так старая возможность не превращается незаметно в новый лид, а новая работа не теряется внутри старой переписки.
Для случайных дублей выберите основную запись, перенесите в неё необходимые сведения, а вторую пометьте «дубль J-001» и исключите из подсчёта. Короткое объяснение объединения поможет коллеге понять, почему семь сообщений превратились в шесть самостоятельных запросов.
Соберите таблицу из полей, которые ведут к решению
Создайте общий рабочий журнал в привычной таблице. Строки ниже — словарь его колонок: каждую группу при необходимости разделите на отдельные поля. Используйте списки значений для качества и статуса, а даты храните как даты. Начните с необходимых сведений; добавляйте новое поле, когда понятно, какое действие или решение от него зависит.
| Поле | Что записывать | Правило |
|---|---|---|
| ID и первое обращение | J-001; дата и время поступления | Номер и исходную дату сохранять при повторном контакте. |
| Запрос и контакт | Краткая задача; ссылка на рабочую переписку | Самостоятельные проекты разделять; не копировать всю переписку. |
| Способ связи | Форма, звонок, email, WhatsApp | Как человек обратился в этот раз. |
| Источник и основание | Рекомендация — со слов клиента; либо не установлен | Откуда узнал о компании и чем это подтверждается. |
| Соответствие задаче бизнеса | Да / нет / не проверено; основание и дата | Оценивать по согласованным критериям. |
| Текущий статус | Новая / уточнение / в работе / отложена / закрыта | Для закрытой записи указывать исход и дату. |
| Ответственный | Один сотрудник, ведущий запрос | При передаче явно назначать нового владельца. |
| Следующий шаг и срок | Отправить расчёт; 16 сентября | Заполнять у каждой открытой заявки. |
| Итог и причина | Заказ подтверждён; либо закрыто без заказа с причиной | Не заменять неизвестную причину догадкой. |
| Последнее действие | Дата; что сделано; результат разговора | Сохранять краткую историю важных изменений. |
Контактные данные нужны тем, кто работает с клиентом. Для сводного обсуждения обычно достаточно номера заявки и краткого описания. Настройте доступ по рабочим обязанностям, избегайте общей публичной ссылки и лишних копий переписки. Такая организация доступа полезна, но сама по себе не заменяет правила обработки данных вашей компании.
Если в таблице становится неудобно хранить историю, заведите второй лист: ID заявки, дата, сотрудник, действие, результат. Основной лист показывает текущее положение, второй — как к нему пришли. Не стирайте исходную причину или подтверждённую дату при очередном обновлении статуса.
Разделите качество запроса и текущий статус
«Подходит ли нам задача?» и «На каком этапе разговор?» — разные вопросы. Подходящий клиент может выбрать другого исполнителя. Запрос без ответа пока может оставаться непроверенным. Если объединить эти ситуации в один статус «плохой лид», отчёт перестанет объяснять происходящее.
Согласуйте несколько проверяемых условий. Например, компания обслуживает коммерческие помещения в определённом регионе; запрос должен относиться к этой услуге и территории. Если бюджет или срок являются реальным ограничением, заранее опишите, что требуется подтвердить. Не придумывайте порог после отказа клиента. Результат проверки храните как «да», «нет» или «не проверено» с коротким основанием.
Для текущей работы достаточно понятных этапов. «Новая» — ещё не взяли в обработку. «Уточнение» — не хватает сведений. «В работе» — задача понятна, идёт расчёт или обсуждение. «Отложена» — есть основание вернуться позже и дата следующего контакта. «Закрыта» — записан результат: заказ подтверждён или работа завершена без заказа.
Отправленное предложение ещё не означает подтверждённый заказ. Выберите наблюдаемый критерий успеха: например, письменное согласование заказа по вашему процессу. Поступление оплаты при необходимости учитывайте отдельным фактом. Сотрудники должны одинаково понимать, какое подтверждение позволяет закрыть заявку успешно.
Это различие полезно и при последующей настройке рекламы. Google Ads описывает квалифицированный лид как обращение, дополнительно проверенное вне рекламной системы, а converted lead — как достижение выбранного этапа. Поэтому само название показателя не доказывает получение оплаты: важно знать, какое действие за ним стоит.
Если подходящий клиент отказался из-за срока, сохраните подтверждённое соответствие и отдельно запишите причину закрытия. Если позже выяснилось, что первоначальные сведения были ошибочными, исправьте оценку с датой и пояснением. История позволит отличить уточнение фактов от изменения коммерческого результата.
Заполненный пример: шесть заявок одной недели
Ниже вымышленный пример компании по обслуживанию коммерческих помещений. За 1–7 сентября 2026 года она получила семь входящих сообщений по шести самостоятельным запросам. Одно сообщение — повтор по J-001. Состояние записей зафиксировано на 15 сентября. Сотрудники и результаты условные; это пример ведения журнала, а не кейс клиента Salestudia.
| ID / поступила | Соответствие | Состояние и основание | Ответственный / следующий шаг |
|---|---|---|---|
| J-001 / 2 сентября | Да | В работе: расчёт отправлен. Повторное сообщение добавлено сюда. | Анна / обсудить расчёт 16 сентября |
| J-002 / 3 сентября | Да | Закрыта: заказ письменно подтверждён 10 сентября. Оплата отдельно. | Анна / обработка заявки завершена, заказ передан исполнителю |
| J-003 / 4 сентября | Нет | Закрыта без заказа 5 сентября: объект вне территории обслуживания. | Олег / дальнейшая обработка не требуется |
| J-004 / 5 сентября | Да | Закрыта без заказа 9 сентября: клиент сообщил о выборе другого исполнителя. | Олег / дальнейшая обработка не требуется |
| J-005 / 6 сентября | Не проверено | Уточнение: неизвестны тип и адрес объекта, ответа пока нет. | Анна / повторно уточнить сведения 16 сентября |
| J-006 / 7 сентября | Да | Отложена: клиент попросил вернуться к обсуждению в октябре. | Олег / связаться 1 октября |
В рабочем файле у каждой строки также будут описание задачи, контакт, источник и история. Здесь они сокращены, чтобы было видно главное: соответствие задаче бизнеса не исчезает после проигранного заказа, а отсутствие ответа не становится автоматически отказом.
Три заявки остаются открытыми: J-001, J-005 и J-006. У каждой есть сотрудник, действие и дата. J-006 не просрочена только потому, что заказ пока не получен: следующий контакт согласован на октябрь. Зато строка «ждём клиента» без срока возвращения требовала бы уточнения.
Закрытая J-002 перестаёт требовать действий в журнале привлечения, но сама работа по заказу продолжается у исполнителя. При передаче зафиксируйте, кто принял заказ. Иначе красивый статус в таблице скроет следующий разрыв: продажа состоялась, а выполнение никто не начал.
Считайте результат для одной группы поступивших заявок
Выберите заявки по дате первого обращения и сохраните дату, на которую оцениваете их состояние. В примере группа — шесть запросов, поступивших 1–7 сентября, а срез — 15 сентября. Возвращаясь к этой группе позже, вы увидите, как изменился её результат, не подмешивая новые обращения.
Проверка дала четыре подходящих запроса, один неподходящий и один пока непроверенный: 4 + 1 + 1 = 6. Успешно закрыт один заказ, два обращения закрыты без заказа, три остаются открытыми: 1 + 2 + 3 = 6. Это два разных разреза одной группы, поэтому складывать «четыре подходящих» и «три открытых» нельзя.
На дату среза заказ подтвердился у 1 из 6 заявок, то есть у 16,7%. Среди четырёх подтверждённо подходящих — у 1 из 4, или 25%. Оба числа описывают только текущее состояние: три обращения ещё открыты, а одно из них даже не прошло проверку. Не называйте эти доли окончательной конверсией недели.
Теперь представьте, что 11 сентября подтвердился ещё один заказ, впервые обсуждавшийся в августе. Он входит в число подтверждённых заказов за сентябрь, но не в результат группы заявок 1–7 сентября. Деление всех сентябрьских заказов на новые сентябрьские обращения смешает разные группы и может дать вводящее в заблуждение число.
Для регулярного обзора сохраняйте четыре значения: сколько самостоятельных заявок поступило, сколько проверено, сколько успешно закрыто и сколько ещё открыто. Рядом ставьте период поступления и дату среза. Разбивку по услугам и источникам добавляйте, когда по ней можно принимать решения; шести условных записей недостаточно для вывода об эффективности рекламного канала.
Не подменяйте источник заявки способом связи
WhatsApp, звонок и форма показывают, как человек связался с компанией. Рекомендация, поиск и реклама отвечают на другой вопрос — откуда он пришёл. Клиент может увидеть рекламу, изучить сайт и написать в мессенджер. Одного факта сообщения недостаточно, чтобы восстановить весь путь.
В поле источника сохраняйте значение и основание: «рекомендация — сообщил клиент», «кампания — метка, сохранённая вместе с запросом» или «не установлен». Рассказ клиента и техническая метка могут описывать разные касания. При расхождении оставьте оба наблюдения с пояснением, а не выбирайте удобное значение без проверки.
Не относите неизвестные обращения к Google Ads только потому, что в этот период работала реклама. Не меняйте первоначальный источник на WhatsApp после повторного контакта. Если сведения не сохраняются, это отдельная задача для настройки формы и измерения, а до её решения доля неизвестных должна оставаться видимой.
Журнал и аналитика сайта решают связанные задачи, но не обязаны показывать одинаковые числа. Начатая форма, нажатие на контакт и полученный самостоятельный запрос — разные действия. Для сопоставления сначала договоритесь, что именно считается событием и что попадает в журнал, затем проверяйте конкретные расхождения.
Введите короткий ежедневный порядок работы
Назначьте сотрудника, который проверяет входящие обращения и распределяет новые запросы. Если владельцев несколько, каждый должен видеть свои открытые строки и просроченные действия. Частоту проверки согласуйте с режимом работы и обещанными клиентам сроками ответа.
В начале рабочего дня просмотрите новые сообщения и открытые записи со сроком на сегодня или раньше. Сначала проверьте, не является ли сообщение продолжением существующего запроса. Затем назначьте владельца и конкретное действие: «уточнить адрес объекта», «отправить расчёт», «согласовать дату разговора».
После контакта запишите короткий результат сразу, пока детали известны. Если сотрудник обещал ответ завтра, в таблице должен появиться этот срок. Если запрос передан коллеге, новый ответственный должен принять его, а клиент — понимать, от кого ждать продолжения. Простая смена имени в ячейке не подтверждает передачу.
В конце дня проверьте строки без ответственного, без следующего шага и с прошедшим сроком. У просрочки нужна причина и новое решение. Не переносите дату автоматически каждый день: так журнал будет выглядеть аккуратно, но перестанет показывать задержки.
Отдельно договоритесь, когда прекращать попытки связи. Универсального количества звонков здесь нет: учитывайте характер запроса и договорённости. После завершения попыток можно закрыть запись с причиной «связаться не удалось», сохранив историю. Без подтверждающих сведений качество запроса при этом остаётся непроверенным.
Раз в неделю разбирайте причины, по которым работа остановилась
Недельный обзор начните с незавершённых действий и непроверенных запросов. Затем посмотрите закрытые обращения. Причина должна опираться на факт: клиент назвал ограничение, сотрудник проверил территорию или закончились согласованные попытки связи.
«Дорого» записывайте, когда клиент действительно сообщил о цене. Если он перестал отвечать после расчёта, причина пока неизвестна. «Выбрал другого» тоже не объясняет автоматически, чем конкурент оказался лучше. Отделяйте известный результат от предположения о мотиве.
Повторяющиеся причины подсказывают разные действия. Запросы из неподходящих регионов — повод проверить описание территории на сайте. Подходящие обращения с пропущенными сроками ответа — повод пересмотреть распределение работы. Много непроверенных строк — сигнал, что сведения не собираются или журнал не обновляется. Эти наблюдения сначала проверяйте по конкретным записям.
Завершайте обзор одним или двумя назначенными действиями с ответственными и сроками. Например: уточнить географию на странице услуги и проверить, исчезли ли соответствующие недоразумения в новых обращениях. Сохраняйте прежние группы для сравнения, отмечая изменения в процессе. Не переписывайте историю так, будто новые правила действовали всегда.
Когда таблицы достаточно, а когда нужен следующий инструмент
Таблицы достаточно, пока сотрудники поддерживают записи, находят нужный запрос и выполняют действия в срок. Первый результат внедрения — открытая заявка перестаёт оставаться без владельца и следующего шага. Сама по себе таблица не создаёт спрос и не гарантирует рост продаж.
Переход к CRM имеет смысл обсуждать, если регулярно теряется история, несколько сотрудников одновременно меняют одну запись, сложно разграничивать доступ или вручную поддерживать напоминания и передачи. Опишите эти сбои на примерах. Количество заявок само по себе не даёт универсальной границы, после которой требуется определённая система.
Перед переносом согласуйте единицу учёта, статусы, критерии соответствия, причины закрытия и ответственных. Проверьте их на нескольких реальных запросах. Если сотрудники не могут одинаково описать одну ситуацию, автоматизация закрепит расхождение; сначала исправьте правило.
Передача подтверждённого качества обращений в рекламную систему — отдельный следующий этап. Для него понадобится связать рабочие записи с измеряемыми событиями и проверить передачу. Русскоязычная статья на отдельном сайте Salestudia.de разбирает этот процесс для Google Ads.
Чтобы начать сейчас, перенесите активные обращения в журнал, объедините подтверждённые дубли и назначьте ближайшее действие каждой открытой заявке. Через рабочую неделю проверьте, какие поля помогли обработке, а какие остались пустыми. Если требуется связать сайт, аналитику и дальнейший учёт, обсудите с Salestudia исходный процесс и конкретные разрывы в данных.
Официальные и профильные ссылки
Эти материалы дают контекст для данных, правил и рекомендаций на странице.
- Google Ads — квалифицированные лиды и выбранные этапы конверсии Источник проверен: 15.09.2026
Удобнее написать напрямую?
Коротко укажите компанию, рынок и задачу — так разговор будет предметнее.