Как рассчитать расходы на поддержку бота после запуска
Пример расчёта (условные цифры): если из 200 начатых диалогов 50 заканчиваются подтверждённой заявкой, доля составляет 25%. Сначала проверьте, что все события посчитаны по одному правилу. На БЕСПЛАТНОЙ КОНСУЛЬТАЦИИ можно согласовать события и проверить расчёт на вашем потоке.
Результат, который нужен по теме «расходы на поддержку бота»
В расчёте учитывают разработку, но забывают хостинг, обновления и контроль ответов. Сначала уточните, какие события попали в числитель и знаменатель. Потом проверьте, не изменились ли источник аудитории и версия сценария.
Показатель полезен, когда можно восстановить каждую его строку. Сохраните время, источник, версию сценария и связь с рабочей записью. Тогда после изменения бота будет видно, вырос ли результат или изменился способ подсчёта.
Месячная стоимость включает хостинг, платные сервисы, обновление базы знаний, контроль качества и разбор ошибок. Сопоставляйте её с количеством корректно решённых задач, а не только с запусками диалога.
Расходы разделите на запуск и ежемесячное содержание. В последнем есть хостинг, платные интеграции, обновление ответов, контроль качества и разбор исключений. Стоимость на одно решённое обращение считайте по подтверждённым результатам.
Сведения берите из источника «Фактические счета и журнал работ». Сверьте события с карточкой результата и не переносите отсутствующее событие из другого канала по предположению.
Вопрос к вам: сколько диалогов вошло в отчёт и сколько строк вы сверили с исходной перепиской?
Лайфхак: храните рядом с графиком определение числителя и знаменателя. После обновления бота это сохранит смысл сравнения.
Какие данные и решения подготовить
Опишите момент возникновения каждого события и правило его повторения. Отдельно храните начало, полезный ответ, передачу человеку и подтверждённую заявку.
Для «скачки нагрузки или платные API» сопоставьте события с несколькими разговорами вручную. По ним будет видно, где ошибка данных, а где ограничение сценария.
Сравните отчёт с карточками результата и несколькими исходными диалогами. Особенно проверьте случаи, где бот назвал вопрос закрытым, а человек вернулся вскоре с той же проблемой.
Сохраните примеры спорных записей и ответственного за схему событий. Тогда следующая версия отчёта будет проверена тем же способом.
Перед тестом назначьте владельца исходных сведений и владельца текста бота. Когда правило меняется, оба проверяют одну и ту же цепочку: что введено, что сохранилось, кто получил задачу и каким сообщением она завершилась. Дата обновления без ответственного не защищает от старого ответа.
Два способа обработать запрос
Вручную. Разбор выборки показывает качество результата за пределами кнопок. Его сильная сторона - нюансы задачи, слабая - отсутствие масштаба без полного подсчёта.
Автоматический отчёт. Дашборд показывает масштаб без ручного чтения каждого чата. Плюс - скорость контроля; риск - ложный успех, если автоответ приравняли к решению.
Используйте отчёт как указатель для редактора сценария. Не переносите вывод по нескольким разговорам на весь поток без подсчёта доли.
Как запустить сценарий по шагам
Шаг 1. Собрать постоянные статьи расходов
Разделите показ шага, ответ и подтверждённый итог. Название метрики должно соответствовать наблюдаемому действию.
Шаг 2. Оценить переменные затраты
Сопоставьте журнал бота с CRM. Разница в часовом поясе или задержка обмена не должны создавать ложный отказ.
Шаг 3. Учесть труд редактора и поддержки
Разделите поток по типу задачи и версии сценария, затем проверьте строки с необычным переходом.
Шаг 4. Сравнить с базовым процессом
Проверьте результат на контрольной группе и опишите пределы вывода, прежде чем менять сценарий.
Сравните автоматический расчёт с ручным на примерах «скачки нагрузки или платные API». Расхождения оформите как задачи владельцу данных, а не как произвольную поправку к отчёту.
Таблица проверки результата для «расходы на поддержку бота»
Для этой задачи контролируйте показатель «месячная стоимость на решённый сценарий». Зафиксируйте его определение, период и источник до запуска. Дополните его временем до результата и числом случаев, которые пришлось исправлять вручную. Иначе отчёт может объявить успехом отправку сообщения, за которой не было нужного действия.
Пример расчёта (условные цифры): если в двух каналах по 50 заявок, но в одном было 500 переходов, а в другом 100, одинаковое число заявок не означает одинаковую конверсию. Это оценка для проверки процесса, а не обещание эффекта внедрения.
При малом количестве наблюдений показывайте и процент, и число исходных случаев. Это ограничит слишком уверенный вывод.
Вопрос к вам: сколько обращений вернулось с той же задачей после формально успешного ответа?
Лайфхак: храните три проверочных случая рядом с описанием сценария. После каждого изменения прогоняйте их заново и добавляйте новый случай, если обнаружили повторяющуюся ошибку.
Что ещё связано
Сценарий опирается на качество исходных данных и понятную передачу исключений. В A3bot можно собрать маршрут вокруг вашей рабочей системы. Стоимость обсуждаем после разбора задачи.
Заметка эксперта
У задачи «расходы на поддержку бота» есть проверяемое завершение. Бот полезен, когда он приближает к этому завершению и не скрывает задержку или ошибку. Начните с небольшого потока, подтвердите итог в основной системе и только затем расширяйте сценарий.
Напишите, какой процесс хотите автоматизировать: A3bot