Привет! На связи Алексей Шевченко, команда Okdesk.
Типовой учёт заявок
Если составить усреднённый профиль B2B-сервиса и техподдержки в России (да и в СНГ тоже), то работа в ней будет организована примерно так:
Заявки приходится собирать из разных источников. Что-то приходит на общую почту, что-то регистрируют по телефону или в мессенджерах, а что-то вообще приходит на личные телефоны инженеров.
Учёт организован на коленке (в почте / электронных таблицах / мессенджерах). Основной инструмент для учёта, конечно, Excel, куда диспетчер вносит заявки и детали к ним. Чаще всего у инженеров доступа к этому файлу нет, как нет и защиты от утечки данных.
Бардак в рабочих процессах. У сотрудников нет понимания, что и где они должны сделать; руководство не понимает, кто, где и чем занимается.
Диспетчер (или диспетчеры) вынужден постоянно напоминать о сроках выполнения инженерам: сначала найди заявки, потом ответственных, каждому позвони или напиши — рутина и пустая трата времени.
Клиенты дёргают диспетчеров или, что ещё хуже, напрямую инженеров, пытаясь выяснить, что там с их заявкой.
Руководитель каждую неделю собирает отчёты в Excel, чтобы хоть как-то понять, что сейчас происходит в компании: всё ли делаем вовремя, кто из сотрудников недогружен/перегружен и т. д.
Такая организация рабочих процессов приводит к ряду проблем:
Заявки теряются. Инженер забыл переслать сообщение из мессенджера диспетчеру, диспетчер забыл внести заявку из почты в Excel и т. д.
Бардак. Сотрудники не знают, что и в каком порядке должны делать; руководитель не знает, что делают сотрудники.
Низкая эффективность. Например, чтобы добраться до истории обслуживания или согласовать время визита к клиенту, нужно дозвониться в Смольный, а значит за день вместо 10 заявок инженер решит 3—4.
Нет истории взаимодействия. Вообще ни с кем. Ни с клиентом, ни в рамках конкретной заявки, ни в рамках обслуживания оборудования или ПО или объекта.
Руководители как ёжики в тумане. Когда перед глазами нет данных в понятной форме (графики, таблицы там всякие), то бизнес-решения принимаются наугад: «Ну, вроде, Петров в этом месяце часто на глаза попадался, значит хорошо работал, ему премию дам». А то, что Петров кофе часто пил и болтал в курилке по три часа, вы не в курсе.
«Чёрный ящик» для клиентов. Заявку отправили, а что с ней происходит дальше — загадка. Клиент дёргает диспетчера или, ещё хуже, инженера, чтобы выяснить статус своего обращения и время устранения поломки.
Экономика ручного учёта: сколько вы теряете?
«Это всё понятно, — скажете вы. — Но где тут деньги-то? Мы работаем так уже много лет, пока не закрылись, зарплаты платим, что не так?»
И тут на помощь приходит простейшая математика.
Представим вымышленную компанию. Пусть в ней будет 15 инженеров, и ежедневно она получает 30 заявок.
Предположим, что в среднем инженер получает на руки 70 000 руб./мес., помня о налогах и взносах, получаем, что компания тратит на ЗП инженера ~100 000 руб. (1 200 000 руб./год).
В 2024 году при 40-часовой рабочей неделе получается ~165 раб. часа/мес.
Значит, один час инженера обходится компании ~610 рублей.
Возьмём позитивный сценарий и предположим, что планёрки в офисе у вас раз в неделю, на них собираются все инженеры.
К слову, в некоторых компаниях они до сих пор проходят раз в день — по утрам, единственное, что изменилось за последние пару лет — не всегда в офисе.
Планёрка, естественно, в рабочее время и длится час. Расходы на разъезды по объектам клиентов учитывать не будем.
Получается, что в месяц на планёрки уходит:
4 недели × 15 инженеров × 1 час = 60 рабочих часов.
Это, на секундочку, уже 36 000 рублей в месяц, которые можно и не тратить.
Считаем дальше. На очереди руководитель и необходимость вручную сводить отчёты по финансам и трудозатратам.
Для простоты расчёта возьмём часовую ставку руководителя, равную 1000 руб.
Учитывая отсутствие автоматизации, руководитель вынужден собирать отчёты руками. Пускай на это он тратит три часа в неделю, или 12 часов в месяц. В деньгах это ещё 12 000 рублей. Прибавляем их к «инженерным» потерям и получаем 48 000 рублей в месяц.
Расчёт упрощён донельзя, ведь мы не считаем работу диспетчеров, затраты на поиск информации по оборудованию или объекту обслуживания, оформление документов и отчётов для клиентов и прочие сопутствующие расходы.
И даже с таким упрощённым расчётом ежемесячные потери составляют почти 50 000 рублей.
Это 600 000 рублей в год.
И, поверьте, это далеко не все потери от ручного учёта.
Сюда же можно записать бесплатные работы.
Вот, например, приехал инженер на объект обслуживать вентиляцию, а его просят посмотреть ещё и какой-нибудь пожарный извещатель. Входит ли этот извещатель в договор обслуживания, инженер не знает, под рукой ведь нужной информации нет. В итоге инженер смотрит ещё и извещатель.
Кажется мелочь, а помножьте эту мелочь на 15 инженеров, и к прошлым годовым потерям можно смело накидывать ещё пару сотен тысяч бесплатных работ.
Операционка и рутина съедают мотивацию. Руководитель вместо решения стратегических задач ковыряется в отчётах, что приводит как к прямым (их разобрали выше), так и к косвенным потерям, ведь времени на развитие бизнеса остаётся совсем мало, и вместо условного роста компании на 30% в год получается лишь 10%, а остальные 20% превращаются в упущенную прибыль.
Так что реальные потери даже посчитать сложно.
Вывод: внедряйте автоматизацию
Оговоримся: если у вас 1–2 сотрудника и 3–5 заявок в день, вполне можно обходиться подручными средствами для их учёта. Да, будете терять некоторые заявки; да, быстро масштабировать бизнес без потери качества не получится.
Но!
Кое-как работать и управлять всем вручную на таких объёмах можно.
Однако если в вашей сервисной компании и внутренних отделах поддержки 5+ сотрудников и 10+ заявок в день (либо заявки эти комплексные и «длинные» — несколько исполнителей, срок решения 1–2–3 недели и т. д.), то стоит задуматься о внедрении help desk системы.
Кому подходит такое решение (спойлер: почти всем), читайте здесь.
Подписывайтесь на наш канал «ОК, сервис» в Telegram, где мы рассказываем о своей внутрянке, делимся экспертизой по развитию сервисного (и не только) бизнеса и смешно шутим.
Начать дискуссию