Наша автоматизация

В этом разделе рассказываем про себя — но не просто, кто мы такие. А про себя как своего собственного клиента. Сейчас поясним.

Конечно, мы не только помогаем автоматизировать бизнес другим компаниям, но и организовали все свои процессы. И продолжаем тестировать гипотезы и переорганизовывать еще лучше. Иначе бы ничего не получилось и с внешними задачами, для других.

Осенью 2021 года нам исполнилось десять лет, и в честь юбилея подготовили большой рассказ о том, как у нас всё устроено, чтобы мы работали быстрее и ничего не упускали.
На видео о процессах внутренней автоматизации рассказывает руководитель компании Андрей Ефимов. А ниже — цикл статей.

Подробные кейсы нашей автоматизации

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

Если что-то подобное вам захочется настроить у себя — напишите или позвоните нам. Подробнее поделимся опытом и, конечно, поможем :)

А в этом видео рассказываем, как 1С:Коннект помогает нам принимать более 15 000 заявок в год и все их вовремя обрабатывать.

Какая задача стояла перед нами Звонить клиенту через пару дней после отправки коммерческого предложения — неэффективно. Менеджер не знает, открыл ли клиент письмо или уже забыл о нем. Нам хотелось, чтобы менеджер понимал: клиент уже смотрит предложение, и с ним можно связаться прямо сейчас. Мы доработали 1С так, чтобы она сама подсказывала точный момент для связи. Как мы это устроили Мы работаем в связке CRM-блока и 1С:УНФ. Стандартный функционал 1С не умеет отслеживать открытие писем и автоматически двигать сделки по таким событиям, поэтому часть процессов мы доработали под себя. 1. Автоматический старт работы с лидом Когда менеджер переводит лид в статус «Обработан», система сама отправляет клиенту первое письмо через UniSender и сразу ставит задачу на следующее касание. Менеджеру не нужно помнить, кому и когда писать. 2. Видно, дошло ли письмо В карточке сделки отображаются статусы: «Отправлено», «Получено», «Открыто». Если письмо не дошло, менеджер видит это и может уточнить контакт — возможно, почта указана с ошибкой или письмо ушло в спам. 3. Уведомление об открытии КП Когда клиент открывает письмо с коммерческим предложением, менеджер получает уведомление, а сделка автоматически переходит на этап «КП открыто». В этот момент можно связаться с клиентом и сразу обсудить детали, пока он еще изучает предложение. Здесь есть один важный организационный момент: чтобы схема работала, у менеджера должна быть возможность отложить текущие дела и перезвонить после уведомления. Если сотрудник загружен другими задачами, мгновенная реакция не получится — это нужно учитывать при настройке процессов. 4. Автозадачи на следующих этапах На каждом этапе воронки система сама ставит задачу на следующее касание. На большинстве этапов также настроены автоматические рассылки — клиент получает дополнительные материалы, напоминания, полезные письма. Менеджеру не нужно держать это в голове. Кроме того, система фиксирует, сколько времени лид находится на каждом этапе. Это помогает увидеть, где сделки зависают и на каком шаге происходит наибольший отвал. Когда такие «узкие места» найдены, мы можем точечно подбирать и проверять разные активности на этих этапах, чтобы улучшить результат. Как это работает Внутри все устроено по принципу «условие+действие». В настройке сценария продаж задается воронка: этапы сделки и триггеры на каждом этапе. Условие — это событие в системе. Действие — реакция: поставить задачу, перевести сделку, отправить письмо по шаблону. Для каждого события мы подготовили свой шаблон с картинками и автозаполнением: система сама подставляет имя клиента и данные из карточки. Клиент затих в демо-базе. Когда мы выдаем демо-доступ, система отслеживает, работает ли пользователь в базе 1С: Фреш. Если активности нет какое-то время, клиенту автоматически уходит письмо с предложением помощи, где мы напоминаем о себе и предлагаем показать, как все работает. Тестовый период заканчивается. Система считает дни демо-доступа и незадолго до окончания отправляет письмо-напоминание о том, что пора выбрать тариф. Клиент принял решение. Если демо-доступ переходит в подписку, клиент получает приветственное письмо с контактами и полезными ссылками. Если нет, то вежливое прощальное письмо. Важно! Вся эти настройки не мешают менеджеру в ежедневной работе. Он видит свой список лидов и задач, а не настройки триггеров. Сценарий продаж настраивает администратор один раз, после чего процессы работают сами. Бесшовная связка с учетом Отдельно хочется отметить, что наш CRM-блок встроен напрямую в 1С. Менеджер в одном окне видит не только переписку и этапы воронки, но и счета, заказы, факт поступления оплаты, статусы отгрузок. Ему не нужно уточнять у бухгалтера, оплачен ли счет, — он видит это сам и может сразу провести закрывающие документы. Обычные облачные CRM такой связки с учетом не дают, поэтому менеджерам приходится работать в двух системах одновременно. Кроме того, мы настроили систему расшифровки звонков на базе искусственного интеллекта. Она фиксирует итоги звонка с клиентом и подводит итог разговора, что позволяет не упускать важных деталей и быстрее заполнять карточку. Что это дало компании Помимо того, что менеджеры стали звонить клиенту более своевременно, мы получили несколько рабочих преимуществ: Ничего не теряется. Все детали запроса фиксируются в карточке сделки: сколько лицензий нужно, когда планируется установка, какие были договоренности. Если менеджер заболел или ушел в отпуск, коллега открывает карточку и видит всю историю — клиент не остается без внимания. Работа с базой становится осмысленной. По справочнику клиентов можно строить выборки по отраслям, по купленным продуктам, по источникам. Это позволяет делать точечные рассылки и предложения, а не отправлять одно и то же письмо всей базе. Понятная аналитика. Руководитель отдела продаж видит конверсию по разным воронкам и эффективность каждого менеджера. Отдел маркетинга видит, из каких источников приходят лиды. Напоминания о существующих клиентах. После закрытия сделки система сама ставит задачу связаться с клиентом через 2–3 месяца, чтобы узнать, как идут дела, и при необходимости предложить сопутствующие услуги. Если вам нужна похожая доработка Штатный функционал 1С не покрывает такие сценарии — это всегда доработка под конкретные процессы. Если вам важно, чтобы менеджеры звонили вовремя, все данные о сделках собирались в одном месте, а отчеты по работе отдела были понятны, — напишите нам. Задумались об автоматизации? Посмотрим, как у вас сейчас устроена работа, и подскажем, что из этого можно настроить в 1С Оставить заявку

Смотреть

Как мы настроили 1С, чтобы менеджер не гадал, когда звонить клиенту

Рассказываем, как мы за пару недель сделали свой веб-клиент к Asana, чтобы наши клиенты продолжили работать в проектах как ни в чём не бывало. Что случилось В один прекрасный день у наших клиентов перестала открываться Asana. Просто белый экран. С почты приходит письмо «вам назначили задачу», нажимаешь на ссылку — белый экран. Для нас, как для компании, которая ведёт проекты вместе с клиентами в Asana — это удар прямо в нервный центр. Все задачи, обсуждения, согласования, файлы — там. И тут раз — и половины участников проектов нет. Чтобы было понятно, о ком речь, приведу пару типичных реплик от клиентов: «Сергей, я не понимаю — мне приходит письмо, я нажимаю, у меня ничего не открывается. Что мне делать?» «Я раньше каждое утро открывала ваши задачи, сейчас просто пишу вам в Telegram, потому что в Asana я не могу зайти». То есть проблема не «технически интересная», а вполне себе бизнесовая: работа клиентов с нами начинает буксовать. А средствами обхода блокировок воспользоваться? Очевидный первый вопрос. И ответ — нет, не вариант. По крайней мере, не как массовое решение, на которое мы можем опираться. Тут целый веер причин — и каждая сама по себе достаточная. Во-первых, теперь это ещё и юридическая история. С 1 сентября 2025 года в России действует закон, по которому реклама и популяризация средств обхода блокировок наказывается штрафами. Для юридических лиц — от 200 до 500 тысяч рублей, при повторном нарушении до миллиона. То есть мы, как юрлицо, обслуживающее клиентов, просто не можем прийти к клиенту и сказать: «поставьте такой-то сервис, и всё заработает». Это уже не вопрос вкуса, это вопрос ответственности. Само использование таких сервисов для законных целей (удалёнка, защита трафика и т. п.) остаётся легальным — но рекомендовать их клиентам как способ работать с нами мы не вправе. Это меняет всю логику. Раньше можно было хотя бы порассуждать «ну пусть клиент сам решит, что ему ставить». Теперь — нет. Во-вторых, даже если убрать юридическую часть, на практике это всё равно не работает. Наши клиенты в Asana — это не разработчики и не айтишники. Это: бухгалтер руководитель отдела продаж директор юрист собственник Теперь представьте, что нужно каждому из них объяснить, какой именно сервис ставить, как его включать, что делать, если он отвалился. И повторить это для каждого нового сотрудника клиента. И поддерживать. И отвечать в техподдержке на вопросы вида «у меня не работает интернет, наверное, это ваше что-то». Прибавьте к этому: такие сервисы то работают, то нет — стабильности никакой, а блокировок только за прошлый год прибавилось на сотни многие компании запрещают подобный софт регламентом безопасности системные администраторы клиентов разворачивать что-то корпоративное ради одного сервиса не будут да и сами клиенты, если честно, не очень-то хотят с этим разбираться — особенно сейчас, когда вокруг темы много шума В итоге решение «пусть каждый клиент сам как-нибудь обходит» работает только в теории. На практике значимая часть клиентов через неделю просто перестаёт заходить в Asana. А может, переехать на другой трекер? Вторая очевидная мысль. Битрикс24, Yandex Tracker, Kaiten, Weeek — выбор большой. Но тут вот что. Переезд — это не «нажать кнопку миграции». Это: перенести десятки активных проектов с уникальной структурой стадий и полей перенести историю переписки и вложений (или потерять её) переучить всех клиентов с уже сложившейся привычкой остановить работу на время переезда (а её и так сложно вести) И главный вопрос: а на сколько эта блокировка вообще? Может, отпустит через полгода. И тогда мы зря потратили несколько месяцев и сожгли много денег на переезд, который никому уже не нужен. То есть переезд — это полноценный проект на месяцы. А работа клиентов встаёт прямо сейчас. Поэтому мы пошли третьим путём. Что мы сделали Мы сделали свой собственный сайт, который выглядит как Asana, ведёт себя как Asana, и открывается из России без всяких ухищрений. Как клиент попадает внутрь Чтобы подключить клиента, мы отправляем ему одну персональную ссылку — на его рабочую почту или в мессенджер. Клиент по ней переходит, оказывается в своём личном кабинете, сохраняет постоянную ссылку в закладки браузера — и дальше каждый раз заходит по ней, как на любой другой сайт. Никаких паролей, регистраций, авторизаций через сторонние сервисы. Открыл закладку — ты в задачах. Рис. 1. Страница, на которую попадает клиент по приглашению: его имя, кто пригласил, в какой проект, какая роль выдана, и кнопка «Открыть мои задачи». Внизу — три простых принципа: без паролей, без VPN, те же задачи, что вели раньше. Это та же Asana — не клон, не аналог, не «как Asana» Главное, что хочется подчеркнуть: мы ничего не пересоздавали и не переносили. Клиент видит ту самую Asana, с которой работал годами: те же проекты, что были те же доски и колонки на канбане, с теми же названиями те же задачи со всей историей — старые комментарии, старые вложения, старые сроки, старые исполнители те же кастомные поля, теги, шаблоны те же права: кому что видно, кто может редактировать, а кто — только комментировать Всё, что годами настраивалось в Asana — никуда не делось. Клиент заходит и сразу узнаёт свой рабочий инструмент. Рис. 2. Общий вид рабочего кабинета клиента. Слева — навигация со всеми его проектами и колокольчик «Входящие» со счётчиком. По центру — приветствие, виджет «Мои задачи» с разделением на «Предстоит/Просрочено/Выполнено», блок «Назначенные мной» и список всех его проектов. Проекты и доски — там же, где были Все проекты, в которых работает клиент, видны в левой панели — ровно так же, как в Asana. Внутри каждого проекта — те же доски: канбан с привычными колонками, список, разбиение на секции. Если в исходной Asana проект разделён на секции «К выполнению / В работе / На согласовании / Готово» — здесь ровно эти же секции и в том же порядке. Карточки задач — те же, с теми же тегами и иконками. Перетаскивание между колонками работает. Рис. 3. Канбан проекта «Внедрение УНФ 1.6 — ООО „Свежесть“»: четыре колонки (Бэклог · В работе · На согласовании клиента · Готово), 12 задач с приоритетами, тегами, исполнителями и сроками. Просроченная задача подсвечена, выполненные задачи — серым с вычеркиванием. Карточка задачи — со всем, что в неё уже вложено Открываешь задачу — и видишь всё то же, что в Asana: название, описание, исполнителя, срок, теги, кастомные поля, наблюдателей, подзадачи, чек-листы, прикреплённые файлы и всю историю комментариев. Всё это можно не только смотреть, но и редактировать: переназначить исполнителя, поменять срок, перетащить в другую секцию, отметить как выполненное. Рис. 4. Открытая задача «Настроить роли пользователей в УНФ». Слева — описание с маркированным списком ролей, чек-лист из 5 подзадач (2 готовы), обсуждение из 4 комментариев между консультантом и клиентом. Справа — все свойства: исполнитель, срок, проект и секция, наблюдатели, теги. Обсуждения, упоминания, реакции, вложения Комментарии работают полноценно: можно отвечать, упоминать коллег через @, ставить реакции на сообщения, прикреплять файлы и картинки прямо в текст комментария. Когда коллега из нашей команды отвечает клиенту из Asana — комментарий мгновенно появляется в обсуждении на нашем сайте. Когда клиент пишет ответ у нас — он тут же появляется в Asana у сотрудника. Это одно и то же обсуждение, просто открытое в двух разных местах. Рис. 5. Полноценное обсуждение задачи между директором клиента и нашим программистом. Видно: @-упоминания нескольких людей, цитирование вопросов в ответах, лайки под комментариями, два вложения прямо внутри сообщений — картинка с выгрузкой из 1С и Excel-шаблон. «Входящее» — все важные события в одном месте В правом верхнем углу — колокольчик с уведомлениями. Туда падает всё, что требует внимания клиента: его упомянули в обсуждении; ему назначили новую задачу; в задаче, на которую он подписан, появился комментарий; задачу, которую он вёл, отметили выполненной. Уведомления приходят в реальном времени: открыта вкладка с сайтом — новое уведомление прилетает прямо сейчас, без обновления страницы. Рис. 6. Входящие клиента: три непрочитанных (упоминание, назначение исполнителем, новый комментарий с вложением — выделены синей рамкой и левой полосой), плюс четыре прочитанных события за вчера (задача отмечена выполненной, добавление в наблюдатели, новый комментарий, изменение срока задачи с пояснением). У каждого уведомления — иконка типа, актор, ссылка на задачу и проект. Поиск, мои задачи, фильтры — всё на месте Привычный поиск по задачам, проектам и людям — работает. Раздел «Мои задачи» — есть, в нём собрано всё, что назначено лично на клиента, по всем проектам сразу. Фильтры по тегам, исполнителям, срокам — работают. Рис. 7. «Мои задачи» главбуха клиента — всё, что лично на ней, по всем проектам. Группировка по проектам (4 задачи во «Внедрении УНФ 1.6», по одной в «Отчётах по марже» и «Поддержке»). По каждой строке — имя задачи, срок с относительной датой («через 2 дня»), проект и секция, в которой она лежит. Сверху — фильтры Активные/Просрочено/Выполнено/Все. И ещё раз главное: это всё те же самые данные Все, что клиент делает на нашем сайте, попадает прямиком в настоящую Asana. И наоборот: всё, что наши сотрудники делают в Asana — мгновенно появляется у клиента в нашем интерфейсе. Никаких параллельных миров, никаких ежесуточных синхронизаций, никаких рисков «у меня одно, у тебя другое». В двух словах: наш сайт сам ходит в Asana вместо клиента. Asana клиента не видит, видит только наш сервер. А наш сервер у Asana не заблокирован, ему хорошо. Технически там внутри много чего: прокси, авторизация через invite-ссылки, синхронизация через webhooks, права доступа, аудит, обработка вложений, real-time события. Но это уже тема для отдельной (технической) статьи. С точки зрения клиента — он просто открыл закладку и работает. Что получилось Соберу в один список: Клиенты вернулись в Asana буквально на следующий день после запуска. Без обходных путей, без установки чего-либо, без обучения. Проекты не пришлось переносить. Структура, история, вложения, упоминания, права — всё осталось ровно как было. Вся логика Asana сохранена: доски, задачи, комментарии, вложения, входящее, упоминания — то же самое, к чему привыкли. Наши сотрудники работают в Asana как работали — для них вообще ничего не изменилось. От «давайте подумаем, что делать» до «клиенты пользуются» прошло около двух недель. Сравните с месяцами на полноценный переезд, на которые в итоге мы бы решились зря. Под конец остаётся пара вопросов А оно вообще нужно? Может, само рассосётся? Может. Мы и сами очень на это надеемся. Но к моменту, когда «рассосётся», работа должна продолжаться. Поэтому мы и сделали такое решение — оно нас не запирает в новый стек, ничего не ломает в Asana, и в день, когда блокировку снимут, мы спокойно его выключим. А пока — оно работает. Зачем вы это пишете, если клиент вам и так в Asana заходит? Затем, что мы сильно подозреваем: мы такие не одни. Если у вас в компании похожая боль — заблокированный сервис, в котором завязана ежедневная работа клиентов или сотрудников, и при этом переезжать на другой инструмент дороже и больнее, чем кажется — напишите нам. Asana — не единственный сервис в этой истории. С Jira, Notion, Confluence, Trello, Monday, Slack — у многих ровно то же самое: годами накопленные данные, привычки, процессы — и вдруг закрытая дверь. Мы этот путь уже прошли и понимаем, какие места в нём болят, а какие решаются проще, чем кажется. Так что если ищете похожее решение — обращайтесь, поможем :)

Смотреть

Asana заблокировали в РФ. Как мы вернули клиентов в свои проекты — без обходных путей и переездов на другой трекер

Смотреть

Как мы интегрировали 1С и МИКО на 160 сотрудников — чаты (часть 2)

О нас Мы — компания «Простые решения» — партнер фирмы 1С. Сопровождаем клиентов, решаем проблемы, которые возникают у них в процессе работы с продуктами 1С. Наши клиенты — это небольшие компании (в том числе государственный сектор): предприниматели, розничные магазины, бухгалтерии — все, что автоматизировано на продуктах 1С. У нас более 3 500 клиентов, которые один или несколько раз в месяц обращаются к нам с какими-то вопросами. В день мы получаем примерно 200–300 заявок. 10 лет мы строили технологичную систему массового обслуживания, с помощью которой можно быстро решить проблемы клиентов и не забыть ни про одного из них. В этом кейсе расскажем, как мы росли и какие проблемы в сфере коммуникаций решали на каждом этапе. Первая часть посвящена телефонии, вторая — мессенджерам. Учетная система Под капотом наша учетная система — 1С:Управление нашей фирмой — продукт 1С, ориентированный на малый бизнес. В систему встроена 1С:CRM, которую мы значительно доработали за много лет эксплуатации. Мы сапожники с сапогами в плане автоматизации решения вопросов. 1С:УНФ <10 сотрудников, 80 клиентов Когда мы только начинали работать, мы принимали звонки на мобильный телефон. Впервые мы начали задумываться о телефонии, когда доросли до 10 сотрудников и 80 клиентов. Какое-то время мы работали на Asterisk, потом — на FreePBX. Мы использовали его как обычно: у нас был многоканальный телефон и сотрудники, которые принимали звонки и обрабатывали их. <20 сотрудников, 150 клиентов Специализация По мере того как мы росли, количество клиентов увеличивалось, и мы начали развивать специализацию. У нас появились сотрудники, которые решали конкретные, узкие задачи. Это усложнило нашу коммуникацию, потому что входящий звонок не всегда находил исполнителя в режиме реального времени. Менеджер, который поднимал трубку, часто не мог привлечь сотрудника, который решил бы проблему. Поэтому мы изменили схему: менеджеры стали регистрировать суть заявки, обещали клиенту связаться с ним, затем специалисты смотрели заявку и начинали с ней работать. Заявка Askozia МИКО Вскоре мы поняли, что совершаем много лишних действий, которые отнимают много времени: нужно идентифицировать клиента и задачу, понять, можно ли с ней работать, и так далее. Мы стали думать, как оптимизировать этот процесс, и в это время мы встретили специалистов МИКО, которые предложили попробовать их решение. Мы поставили Askozia МИКО — очень удобную и интуитивно понятную систему. Что мы получили? В первую очередь — экономию. В нашей АТС было множество провайдеров. В зависимости от того, на какой номер мы звонили, мы подставляли своего провайдера. У нас даже был GSM-шлюз и безлимитные звонки на городские номера в Ростелекоме в Смоленске. К сожалению, несколько лет назад Ростелеком забрал у нас эту опцию. Провайдеры Мы регистрировали входящие звонки, нам приходили обращения. Мы сделали так, чтобы менеджер сразу видел, есть ли у клиента договор, текущие тикеты, чтобы он понимал, по какому вопросу может звонить клиент. Регистрация звонка В нашей учетной системе появились журнал звонков (мы могли слушать их) и первый аналитический блок. Решение о найме нового клиентского менеджера на входящие звонки мы принимали исходя из того, что мы видели, что звонков очень много. Журнал звонков Аналитика <30 сотрудников, 400 клиентов Специфика нашего бизнеса заключается в регулярных договорах, и чем больше у нас сотрудников, тем больше клиентов. Специализация со временем развилась: появились отдельные техники, сервис-инженеры, люди, которые решали очень узкие задачи и, наоборот, комплексные. Виды обращений и рабочие группы Специализация нам очень помогала, но и усложняла процессы. Появилась потребность в том, чтобы менеджер, который принимает звонок, классифицировал задачу. Мы создали виды обращений — большой иерархический список. Виды обращений Как следствие, у нас появились рабочие группы и отделы. Рабочие группы Оказалось, что оптимального способа организовать иерархический поиск сотрудников нет. Поэтому мы доработали панель телефонии МИКО, чтобы можно было по названию отдела найти сотрудника, увидеть, кто с кем сейчас разговаривает, найти свободного специалиста, на которого можно перевести звонок. Это была проба пера, когда мы не просто использовали продукт, а начали подстраивать его под себя. Работа с пропущенными звонками Мы сделали первого интуитивно понятного робота: выявляли в журнале звонков пропущенные, по которым еще не перезвонили, ждали 20 минут и присылали менеджерам сообщение с просьбой перезвонить клиенту. Сообщение менеджеру с информацией о пропущенном звонке <50 сотрудников, 800 клиентов По мере того как мы росли, у нас возникла проблема: часто клиенты попадали на менеджера, который почти никогда не мог перевести их на нужного специалиста и был не очень компетентен в их вопросе. Нам нужно было повысить оперативность решения этих вопросов. Интеграция с ботом Telegram Мы начали обрастать инфраструктурой: сделали интересную интеграцию с Telegram-ботом. Первая задача, которую мы решили, — поиск дежурного. Поиск дежурного Вторая задача — поиск исполнителя. Если заявка больше определенного срока ждала, когда ее начнут решать, мы писали сотрудникам в Telegram с просьбой отреагировать на заявку (не все были на рабочем месте: кто-то был на выезде, поэтому мы сделали интерактивное решение). Поиск исполнителя и переписка Также у нас появились первые фрилансеры. Мы сделали для них отдельный бот, такую онлайн-витрину с очередью заявок. Специалисты могли разносить в нем работы, скачивать и отправлять файлы, переписываться с нами. Работа с удаленными сотрудниками Переход с Askozia на МИКО PBX В этот период Askozia перестала работать, специалисты из МИКО создали бесплатное решение МИКО PBX, и мы перешли на него. На этом этапе мы решили поставить специалистов на первую линию, чтобы звонящие клиенты сразу попадали на человека, который может решить их вопрос. Таких сотрудников было много, они постоянно менялись на линии. Мы хотели быстро добавлять их в очередь и удалять оттуда. Сначала мы взяли штатный набор кода номера, но это было очень неудобно. Поэтому мы пришли к специалистам из МИКО с задачей извне управлять нашей АТС. Мы хотели, чтобы она автоматически добавляла сотрудника в очередь и убирала оттуда. API: добавление телефонии на лету Первое API, которое нам сделали, — это добавление телефонии на лету. Добавление в телефонию на лету Теперь мы могли управлять этим процессом из нашей учетной системы. Сотрудники могли по одному клику добавляться в линию и начинать принимать звонки или удаляться из линии. Это сильно упростило оперативный процесс. Быстрое добавление в линию Специалисты начали принимать звонки, в том числе от тех клиентов, у которых перед нами был долг или не было договора. Мы стали перехватывать такие звонки и передавать менеджеру. Сейчас звонки снова принимают менеджеры, но это был интересный опыт. Перехват звонков должников <80 сотрудников, 1 100 клиентов У нас появилась первая линия, на которой были заняты 7–8 человек: специалисты по зарплате, по управленческим решениям, технические специалисты, бухгалтеры и так далее. Клиенты часто попадали на специалиста в другом вопросе, а не в том, который их интересовал. Это была одна проблема. Вторая заключалась в том, что людей было много и они принимали звонки, когда хотели. Специализированные линии и планирование дежурств Мы сделали множество первых линий, каждая из которых специализировалась на конкретном вопросе, и начали планировать дежурства на этих линиях. Выделенные линии поддержки Мы создали расписание и автоматически добавляли в него сотрудников, которые запланировали дежурства. Планирование дежурств Наша учетная система видела, что дежурство специалиста начнется в 13:00, добавляла его в очередь и через пять минут проверяла, на связи ли сотрудник и есть ли у него специальный статус (нам сделали такое API). Если сотрудник не готов, мы отправляем ему сообщение в Telegram. Мы всегда предупреждаем сотрудника о дежурстве и благодарим за него в конце. Также мы сделали автоматическое планирование дежурств, чтобы дежурства равномерно распределялись между специалистами. Автоматическое управление очередями 100 сотрудников, 1 500 клиентов Дежурства в нерабочее время: переадресация звонков с софтфона на мобильный Мы уже давно организовали дежурство в нерабочее время. Компании (в основном магазины, которые работают допоздна) могут позвонить в 22:00 или в выходные дни, потому что у них что-то сломалось и нужно быстро восстановить работу. Мы автоматически добавляем дежурных в очередь и убираем оттуда. Сначала мы использовали только мобильный телефон, сейчас — софтфон или мобильный. Если клиент звонит и попадает в очередь, а сотрудник не подключен к софтфону, звонок автоматически переадресовывается на мобильный — это очень удобно. Дежурство в нерабочее время Автоматическая отправка сообщений специалисту с данными о звонке Мы отправляем специалисту в Telegram и на почту сообщение с информацией о клиенте, чтобы он мог, если нужно, ему перезвонить. Письмо с информацией о звонке Параллельно мы создаем обращение в нашей системе, чтобы специалист не забыл разнести работы. Поощрение сотрудников за быстрое решение клиентских задач Есть еще одна фишка, которую мы смогли запустить благодаря телефонии. Клиенты жаловались, что им приходится долго ждать решения их проблем. Они хотели, чтобы вопросы решались сразу. И мы стали поощрять сотрудников за быстрое решение проблемы, без перезвона и других переключений. Так как вся эта информация есть в системе, мы выявляем такие звонки, понимаем, что вопрос был решен за 30 минут, клиенту не перезванивали, был крутой результат, — и даем специалисту бонус. Ребята называют их мишенями и бьются за них. Поощрение быстрого закрытия заявок Мы считаем, что внутренняя коммуникация очень важна. Мы пользовались разными мессенджерами: Skype (это было неудобно), Telegram (сотрудники попросили, чтобы он остался их личным мессенджером). Мы долго искали подходящее решение и выбрали Rocketchat — это очень удобная бесплатная программа с множеством опций, которая хранится на наших серверах. Программа Rocketchat для внутренней коммуникации 160 сотрудников, 3 000 клиентов Когда мы получили предложение купить кировскую компанию «МастерСофт», у нас было около 100 сотрудников. После покупки «МастерСофта» мы приросли примерно на 60 новых сотрудников, и их нужно было интегрировать в нашу информационную систему. Мы были уверены, что на этом этапе все сломается. Мы немного улучшили оборудование, и все прошло хорошо. Вторая задача, которую нам нужно было решить, — коммуникация с клиентами. Мы вместе решаем вопросы всех клиентов — и кировских, и смоленских. Но клиенты в Кирове относятся к «МастерСофту», а клиенты в Смоленске — к «Простым решениям». И когда сотрудник «Простых решений» звонил кировскому клиенту, у него определялся смоленский номер, и он очень удивлялся. Поэтому мы, в зависимости от того, с какой компанией у клиента заключен договор, динамически добавляем префиксы на звонки, используем разных провайдеров и меняем номера. Результаты автоматизации Благодаря автоматизации мы управляем большим количеством звонков, анализируем данные, реагируем на пропущенные звонки. Например, столько звонков (входящих, исходящих, пропущенных и неудачных) мы отрабатываем ежемесячно с помощью нашей автоматизированной системы в разрезе года. На скриншоте видна сезонность (периоды подготовки и сдачи отчетности у бухгалтеров) и динамика увеличения количества звонков (в сравнении июль 2023 / июль 2024). А вот так выглядит распределение звонков по части сотрудников за последние 30 дней: Мы рассказали вам о нашем пути к эффективной телефонии. Из второй части вы узнаете о нашем опыте интеграции 1С с мессенджерами. О нас Мы — компания «Простые решения» — партнер фирмы 1С. Сопровождаем клиентов, решаем проблемы, которые возникают у них в процессе работы с продуктами 1С. Наши клиенты — это небольшие компании (в том числе государственный сектор): предприниматели, розничные магазины, бухгалтерии — все, что автоматизировано на продуктах 1С. У нас более 3 500 клиентов, которые один или несколько раз в месяц обращаются к нам с какими-то вопросами. В день мы получаем примерно 200–300 заявок. 10 лет мы строили технологичную систему массового обслуживания, с помощью которой можно быстро решить проблемы клиентов и не забыть ни про одного из них. В этом кейсе расскажем, как мы росли и какие проблемы в сфере коммуникаций решали на каждом этапе. Первая часть посвящена телефонии, вторая — мессенджерам. Учетная система Под капотом наша учетная система — 1С:Управление нашей фирмой — продукт 1С, ориентированный на малый бизнес. В систему встроена 1С:CRM, которую мы значительно доработали за много лет эксплуатации. Мы сапожники с сапогами в плане автоматизации решения вопросов. 1С:УНФ <10 сотрудников, 80 клиентов Когда мы только начинали работать, мы принимали звонки на мобильный телефон. Впервые мы начали задумываться о телефонии, когда доросли до 10 сотрудников и 80 клиентов. Какое-то время мы работали на Asterisk, потом — на FreePBX. Мы использовали его как обычно: у нас был многоканальный телефон и сотрудники, которые принимали звонки и обрабатывали их. <20 сотрудников, 150 клиентов Специализация По мере того как мы росли, количество клиентов увеличивалось, и мы начали развивать специализацию. У нас появились сотрудники, которые решали конкретные, узкие задачи. Это усложнило нашу коммуникацию, потому что входящий звонок не всегда находил исполнителя в режиме реального времени. Менеджер, который поднимал трубку, часто не мог привлечь сотрудника, который решил бы проблему. Поэтому мы изменили схему: менеджеры стали регистрировать суть заявки, обещали клиенту связаться с ним, затем специалисты смотрели заявку и начинали с ней работать. Заявка Askozia МИКО Вскоре мы поняли, что совершаем много лишних действий, которые отнимают много времени: нужно идентифицировать клиента и задачу, понять, можно ли с ней работать, и так далее. Мы стали думать, как оптимизировать этот процесс, и в это время мы встретили специалистов МИКО, которые предложили попробовать их решение. Мы поставили Askozia МИКО — очень удобную и интуитивно понятную систему. Что мы получили? В первую очередь — экономию. В нашей АТС было множество провайдеров. В зависимости от того, на какой номер мы звонили, мы подставляли своего провайдера. У нас даже был GSM-шлюз и безлимитные звонки на городские номера в Ростелекоме в Смоленске. К сожалению, несколько лет назад Ростелеком забрал у нас эту опцию. Провайдеры Мы регистрировали входящие звонки, нам приходили обращения. Мы сделали так, чтобы менеджер сразу видел, есть ли у клиента договор, текущие тикеты, чтобы он понимал, по какому вопросу может звонить клиент. Регистрация звонка В нашей учетной системе появились журнал звонков (мы могли слушать их) и первый аналитический блок. Решение о найме нового клиентского менеджера на входящие звонки мы принимали исходя из того, что мы видели, что звонков очень много. Журнал звонков Аналитика <30 сотрудников, 400 клиентов Специфика нашего бизнеса заключается в регулярных договорах, и чем больше у нас сотрудников, тем больше клиентов. Специализация со временем развилась: появились отдельные техники, сервис-инженеры, люди, которые решали очень узкие задачи и, наоборот, комплексные. Виды обращений и рабочие группы Специализация нам очень помогала, но и усложняла процессы. Появилась потребность в том, чтобы менеджер, который принимает звонок, классифицировал задачу. Мы создали виды обращений — большой иерархический список. Виды обращений Как следствие, у нас появились рабочие группы и отделы. Рабочие группы Оказалось, что оптимального способа организовать иерархический поиск сотрудников нет. Поэтому мы доработали панель телефонии МИКО, чтобы можно было по названию отдела найти сотрудника, увидеть, кто с кем сейчас разговаривает, найти свободного специалиста, на которого можно перевести звонок. Это была проба пера, когда мы не просто использовали продукт, а начали подстраивать его под себя. Работа с пропущенными звонками Мы сделали первого интуитивно понятного робота: выявляли в журнале звонков пропущенные, по которым еще не перезвонили, ждали 20 минут и присылали менеджерам сообщение с просьбой перезвонить клиенту. Сообщение менеджеру с информацией о пропущенном звонке <50 сотрудников, 800 клиентов По мере того как мы росли, у нас возникла проблема: часто клиенты попадали на менеджера, который почти никогда не мог перевести их на нужного специалиста и был не очень компетентен в их вопросе. Нам нужно было повысить оперативность решения этих вопросов. Интеграция с ботом Telegram Мы начали обрастать инфраструктурой: сделали интересную интеграцию с Telegram-ботом. Первая задача, которую мы решили, — поиск дежурного. Поиск дежурного Вторая задача — поиск исполнителя. Если заявка больше определенного срока ждала, когда ее начнут решать, мы писали сотрудникам в Telegram с просьбой отреагировать на заявку (не все были на рабочем месте: кто-то был на выезде, поэтому мы сделали интерактивное решение). Поиск исполнителя и переписка Также у нас появились первые фрилансеры. Мы сделали для них отдельный бот, такую онлайн-витрину с очередью заявок. Специалисты могли разносить в нем работы, скачивать и отправлять файлы, переписываться с нами. Работа с удаленными сотрудниками Переход с Askozia на МИКО PBX В этот период Askozia перестала работать, специалисты из МИКО создали бесплатное решение МИКО PBX, и мы перешли на него. На этом этапе мы решили поставить специалистов на первую линию, чтобы звонящие клиенты сразу попадали на человека, который может решить их вопрос. Таких сотрудников было много, они постоянно менялись на линии. Мы хотели быстро добавлять их в очередь и удалять оттуда. Сначала мы взяли штатный набор кода номера, но это было очень неудобно. Поэтому мы пришли к специалистам из МИКО с задачей извне управлять нашей АТС. Мы хотели, чтобы она автоматически добавляла сотрудника в очередь и убирала оттуда. API: добавление телефонии на лету Первое API, которое нам сделали, — это добавление телефонии на лету. Добавление в телефонию на лету Теперь мы могли управлять этим процессом из нашей учетной системы. Сотрудники могли по одному клику добавляться в линию и начинать принимать звонки или удаляться из линии. Это сильно упростило оперативный процесс. Быстрое добавление в линию Специалисты начали принимать звонки, в том числе от тех клиентов, у которых перед нами был долг или не было договора. Мы стали перехватывать такие звонки и передавать менеджеру. Сейчас звонки снова принимают менеджеры, но это был интересный опыт. Перехват звонков должников <80 сотрудников, 1 100 клиентов У нас появилась первая линия, на которой были заняты 7–8 человек: специалисты по зарплате, по управленческим решениям, технические специалисты, бухгалтеры и так далее. Клиенты часто попадали на специалиста в другом вопросе, а не в том, который их интересовал. Это была одна проблема. Вторая заключалась в том, что людей было много и они принимали звонки, когда хотели. Специализированные линии и планирование дежурств Мы сделали множество первых линий, каждая из которых специализировалась на конкретном вопросе, и начали планировать дежурства на этих линиях. Выделенные линии поддержки Мы создали расписание и автоматически добавляли в него сотрудников, которые запланировали дежурства. Планирование дежурств Наша учетная система видела, что дежурство специалиста начнется в 13:00, добавляла его в очередь и через пять минут проверяла, на связи ли сотрудник и есть ли у него специальный статус (нам сделали такое API). Если сотрудник не готов, мы отправляем ему сообщение в Telegram. Мы всегда предупреждаем сотрудника о дежурстве и благодарим за него в конце. Также мы сделали автоматическое планирование дежурств, чтобы дежурства равномерно распределялись между специалистами. Автоматическое управление очередями 100 сотрудников, 1 500 клиентов Дежурства в нерабочее время: переадресация звонков с софтфона на мобильный Мы уже давно организовали дежурство в нерабочее время. Компании (в основном магазины, которые работают допоздна) могут позвонить в 22:00 или в выходные дни, потому что у них что-то сломалось и нужно быстро восстановить работу. Мы автоматически добавляем дежурных в очередь и убираем оттуда. Сначала мы использовали только мобильный телефон, сейчас — софтфон или мобильный. Если клиент звонит и попадает в очередь, а сотрудник не подключен к софтфону, звонок автоматически переадресовывается на мобильный — это очень удобно. Дежурство в нерабочее время Автоматическая отправка сообщений специалисту с данными о звонке Мы отправляем специалисту в Telegram и на почту сообщение с информацией о клиенте, чтобы он мог, если нужно, ему перезвонить. Письмо с информацией о звонке Параллельно мы создаем обращение в нашей системе, чтобы специалист не забыл разнести работы. Поощрение сотрудников за быстрое решение клиентских задач Есть еще одна фишка, которую мы смогли запустить благодаря телефонии. Клиенты жаловались, что им приходится долго ждать решения их проблем. Они хотели, чтобы вопросы решались сразу. И мы стали поощрять сотрудников за быстрое решение проблемы, без перезвона и других переключений. Так как вся эта информация есть в системе, мы выявляем такие звонки, понимаем, что вопрос был решен за 30 минут, клиенту не перезванивали, был крутой результат, — и даем специалисту бонус. Ребята называют их мишенями и бьются за них. Поощрение быстрого закрытия заявок Мы считаем, что внутренняя коммуникация очень важна. Мы пользовались разными мессенджерами: Skype (это было неудобно), Telegram (сотрудники попросили, чтобы он остался их личным мессенджером). Мы долго искали подходящее решение и выбрали Rocketchat — это очень удобная бесплатная программа с множеством опций, которая хранится на наших серверах. Программа Rocketchat для внутренней коммуникации 160 сотрудников, 3 000 клиентов Когда мы получили предложение купить кировскую компанию «МастерСофт», у нас было около 100 сотрудников. После покупки «МастерСофта» мы приросли примерно на 60 новых сотрудников, и их нужно было интегрировать в нашу информационную систему. Мы были уверены, что на этом этапе все сломается. Мы немного улучшили оборудование, и все прошло хорошо. Вторая задача, которую нам нужно было решить, — коммуникация с клиентами. Мы вместе решаем вопросы всех клиентов — и кировских, и смоленских. Но клиенты в Кирове относятся к «МастерСофту», а клиенты в Смоленске — к «Простым решениям». И когда сотрудник «Простых решений» звонил кировскому клиенту, у него определялся смоленский номер, и он очень удивлялся. Поэтому мы, в зависимости от того, с какой компанией у клиента заключен договор, динамически добавляем префиксы на звонки, используем разных провайдеров и меняем номера. Результаты автоматизации Благодаря автоматизации мы управляем большим количеством звонков, анализируем данные, реагируем на пропущенные звонки. Например, столько звонков (входящих, исходящих, пропущенных и неудачных) мы отрабатываем ежемесячно с помощью нашей автоматизированной системы в разрезе года. На скриншоте видна сезонность (периоды подготовки и сдачи отчетности у бухгалтеров) и динамика увеличения количества звонков (в сравнении июль 2023 / июль 2024). А вот так выглядит распределение звонков по части сотрудников за последние 30 дней: Мы рассказали вам о нашем пути к эффективной телефонии. Из второй части вы узнаете о нашем опыте интеграции 1С с мессенджерами.

Смотреть

Как мы интегрировали 1С и МИКО на 160 сотрудников — телефония (часть 1)

1С не всегда работает так, как хочется нам и нашим пользователям. Поэтому мы часто делаем доработки для программ 1С, в том числе их облачных версий. В этой статье расскажем, как мы справляемся с поддержкой большого количества разработок. Мы сделали более 500 разработок для 1С:ФРЕШ (это к частому вопросу о том, что облако нельзя дорабатывать), а для локальных версий — ещё больше. Иногда одна и та же доработка бывает полезна для многих пользователей. В таких случаях мы стараемся превратить её в продукт. Продукт — это доработка, за которую мы несём ответственность. Она должна: решать задачу пользователя быть удобной и понятной работать у многих пользователей быть правильно и аккуратно написана программистами работать после обновлений иметь понятные инструкции А мы должны поддерживать пользователей доработок — бесплатно или платно в зависимости от вопроса. Стоимость подобной готовой разработки обычно кратно ниже стоимости индивидуальной. Пользователи приобретают у нас расширение за фиксированную понятную цену, а потом по фиксированной цене приобретают поддержку: адаптацию к новым версиям 1С, развитие функционала. Такой подход выгоден и нам (разработчикам), и покупателям (пользователям). Все наши доработки вы можете изучить в каталоге расширений — их там уже больше 40. Сделать расширение-продукт — это ещё не вся работа. Самое сложное начинается на этапе поддержки: обновления 1С выходят несколько раз в месяц, и мы должны успеть вовремя адаптировать разработку для новых версий конфигураций. На такую поддержку наша команда (владельцы продуктов, консультанты, разработчики) тратит немало усилий. Мы для себя приняли несколько решений: мы должны правильно организовать учёт версий разработки: в какой версии какие изменения были сделаны, какой минимальный релиз конфигурации поддерживается мы должны тестировать наши разработки (проверять программную совместимость и функционал разработки) тесты должны выполняться автоматически, без участия тестировщика, чтобы мы могли быть уверены, что всегда проверяем то, что нужно проверить мы должны адаптировать и исправлять разработки до того, как выйдет обновление 1С (на предварительных релизах 1С) мы должны вовремя публиковать новые версии, чтобы пользователи могли их вовремя получить Поэтому мы организовали довольно сложный организационно-технический процесс, чтобы с этим справиться. Процесс адаптации расширений к новому релизу Мы расскажем об этом процессе на примере разработки для 1С:ФРЕШ, в котором есть магазин готовых расширений. Этап подготовки Для каждой разработки нужно настроить специальный конвейер, который будет работать каждый день и будет проверять, всё ли хорошо. Для этого нам нужно подготовить: специальную тестовую базу, на которой выполняются все манипуляции автоматический тест, который будет проверять функциональность расширения, кликая по всем нужным кнопкам и сверяя результаты с эталоном все вспомогательные механизмы, которые позволят проверять всё в автоматическом режиме Этап 1. Обновление тестовой базы У нас есть робот, который каждый день проверяет, не вышло ли обновление (тестовый релиз) конфигурации. Если оно вышло, он автоматически скачивает обновление и устанавливает его на тестовую базу. Этап 2. Установка последней версии расширения в тестовую базу Перед тем как запустить автоматический тест, мы должны быть уверены, что проверяем самую последнюю (актуальную) версию нашей разработки. Поэтому мы автоматически устанавливаем её из каталога и проверяем, не было ли ошибок на этом этапе. Часто на этом этапе возникает ошибка, конвейер прерывает свою работу и сигнализирует ответственному о проблеме. Обычно ошибка связана с тем, что для нового релиза нужна адаптация разработки (некоторая работа программиста). После адаптации разработки конвейер продолжает свою работу. Этап 3. Запуск автоматического тестирования После того как мы получили обновлённую тестовую базу и установили туда последнюю, адаптированную версию расширения, мы автоматически тестируем функциональность. Робот пробегает по всем нужным справочникам, документам, отчётам, нажимает кнопки и проверяет, совпадает ли результат с ожидаемым. На этом этапе также часто возникают ошибки. Об этом мы получаем автоматический сигнал. Ошибки могут возникать по двум причинам: разработчики доработали какую-то функциональность, и нам надо в этом разобраться и поправить программный код, чтобы всё работало как ожидалось мог сломаться автотест — тот сценарий, с помощью которого мы проверяем конкретные действия нашего расширения. То есть могла сломаться не сама разработка, а тест, который её проверяет. В этом случае мы адаптируем тест. После всех исправлений мы прогоняем конвейер ещё раз, чтобы убедиться, что ошибок нет. Успешный конвейер выглядит так: А вот так выглядит успешно пройденный автотест. Согласитесь, красиво! При выпуске нового релиза разработки (новой функциональности) мы также обязательно прогоняем все наши автотесты, чтобы убедиться, что ничего не сломается. Этап 4. Публикация обновления расширения После того как мы всё поправили для новой версии 1С, мы должны правильно опубликовать обновление: подготовить описание изменений, поправить его на нашем сайте отправить разработку на аудит во Фреш (обычно это занимает 2–3 дня). Мы устанавливаем новую версию так, чтобы она работала только в тех базах, в которых обновится типовой релиз. Ведь, если просто выложить новую версию, она обновится и в необновлённых базах пользователей. Это может привести к ошибкам. Все эти действия позволяют нам быть уверенными в том, что наши доработки действительно работают и будут продолжать радовать наших пользователей. Ещё не пробовали наши продукты? Посмотрите наш каталог — в нём много интересного. Если вы столкнулись с тем, что в вашей программе постоянно ломаются доработки, это стопорит рабочий процесс и вы теряете деньги, обращайтесь к нам. Мы обсудим, как можно внедрить подобный процесс для вашей 1С, чтобы вы были уверены в том, что 1С работает, а доработки не ломаются. 1С не всегда работает так, как хочется нам и нашим пользователям. Поэтому мы часто делаем доработки для программ 1С, в том числе их облачных версий. В этой статье расскажем, как мы справляемся с поддержкой большого количества разработок. Мы сделали более 500 разработок для 1С:ФРЕШ (это к частому вопросу о том, что облако нельзя дорабатывать), а для локальных версий — ещё больше. Иногда одна и та же доработка бывает полезна для многих пользователей. В таких случаях мы стараемся превратить её в продукт. Продукт — это доработка, за которую мы несём ответственность. Она должна: решать задачу пользователя быть удобной и понятной работать у многих пользователей быть правильно и аккуратно написана программистами работать после обновлений иметь понятные инструкции А мы должны поддерживать пользователей доработок — бесплатно или платно в зависимости от вопроса. Стоимость подобной готовой разработки обычно кратно ниже стоимости индивидуальной. Пользователи приобретают у нас расширение за фиксированную понятную цену, а потом по фиксированной цене приобретают поддержку: адаптацию к новым версиям 1С, развитие функционала. Такой подход выгоден и нам (разработчикам), и покупателям (пользователям). Все наши доработки вы можете изучить в каталоге расширений — их там уже больше 40. Сделать расширение-продукт — это ещё не вся работа. Самое сложное начинается на этапе поддержки: обновления 1С выходят несколько раз в месяц, и мы должны успеть вовремя адаптировать разработку для новых версий конфигураций. На такую поддержку наша команда (владельцы продуктов, консультанты, разработчики) тратит немало усилий. Мы для себя приняли несколько решений: мы должны правильно организовать учёт версий разработки: в какой версии какие изменения были сделаны, какой минимальный релиз конфигурации поддерживается мы должны тестировать наши разработки (проверять программную совместимость и функционал разработки) тесты должны выполняться автоматически, без участия тестировщика, чтобы мы могли быть уверены, что всегда проверяем то, что нужно проверить мы должны адаптировать и исправлять разработки до того, как выйдет обновление 1С (на предварительных релизах 1С) мы должны вовремя публиковать новые версии, чтобы пользователи могли их вовремя получить Поэтому мы организовали довольно сложный организационно-технический процесс, чтобы с этим справиться. Процесс адаптации расширений к новому релизу Мы расскажем об этом процессе на примере разработки для 1С:ФРЕШ, в котором есть магазин готовых расширений. Этап подготовки Для каждой разработки нужно настроить специальный конвейер, который будет работать каждый день и будет проверять, всё ли хорошо. Для этого нам нужно подготовить: специальную тестовую базу, на которой выполняются все манипуляции автоматический тест, который будет проверять функциональность расширения, кликая по всем нужным кнопкам и сверяя результаты с эталоном все вспомогательные механизмы, которые позволят проверять всё в автоматическом режиме Этап 1. Обновление тестовой базы У нас есть робот, который каждый день проверяет, не вышло ли обновление (тестовый релиз) конфигурации. Если оно вышло, он автоматически скачивает обновление и устанавливает его на тестовую базу. Этап 2. Установка последней версии расширения в тестовую базу Перед тем как запустить автоматический тест, мы должны быть уверены, что проверяем самую последнюю (актуальную) версию нашей разработки. Поэтому мы автоматически устанавливаем её из каталога и проверяем, не было ли ошибок на этом этапе. Часто на этом этапе возникает ошибка, конвейер прерывает свою работу и сигнализирует ответственному о проблеме. Обычно ошибка связана с тем, что для нового релиза нужна адаптация разработки (некоторая работа программиста). После адаптации разработки конвейер продолжает свою работу. Этап 3. Запуск автоматического тестирования После того как мы получили обновлённую тестовую базу и установили туда последнюю, адаптированную версию расширения, мы автоматически тестируем функциональность. Робот пробегает по всем нужным справочникам, документам, отчётам, нажимает кнопки и проверяет, совпадает ли результат с ожидаемым. На этом этапе также часто возникают ошибки. Об этом мы получаем автоматический сигнал. Ошибки могут возникать по двум причинам: разработчики доработали какую-то функциональность, и нам надо в этом разобраться и поправить программный код, чтобы всё работало как ожидалось мог сломаться автотест — тот сценарий, с помощью которого мы проверяем конкретные действия нашего расширения. То есть могла сломаться не сама разработка, а тест, который её проверяет. В этом случае мы адаптируем тест. После всех исправлений мы прогоняем конвейер ещё раз, чтобы убедиться, что ошибок нет. Успешный конвейер выглядит так: А вот так выглядит успешно пройденный автотест. Согласитесь, красиво! При выпуске нового релиза разработки (новой функциональности) мы также обязательно прогоняем все наши автотесты, чтобы убедиться, что ничего не сломается. Этап 4. Публикация обновления расширения После того как мы всё поправили для новой версии 1С, мы должны правильно опубликовать обновление: подготовить описание изменений, поправить его на нашем сайте отправить разработку на аудит во Фреш (обычно это занимает 2–3 дня). Мы устанавливаем новую версию так, чтобы она работала только в тех базах, в которых обновится типовой релиз. Ведь, если просто выложить новую версию, она обновится и в необновлённых базах пользователей. Это может привести к ошибкам. Все эти действия позволяют нам быть уверенными в том, что наши доработки действительно работают и будут продолжать радовать наших пользователей. Ещё не пробовали наши продукты? Посмотрите наш каталог — в нём много интересного. Если вы столкнулись с тем, что в вашей программе постоянно ломаются доработки, это стопорит рабочий процесс и вы теряете деньги, обращайтесь к нам. Мы обсудим, как можно внедрить подобный процесс для вашей 1С, чтобы вы были уверены в том, что 1С работает, а доработки не ломаются.

Смотреть

Что мы делаем, чтобы наши продукты (расширения) не ломались после обновлений 1С

Всего на полдня, но всё же — 150 человек не могли работать, потому что база 1С полностью зависала каждые 5 минут. Это история о том, что иногда случаются ошибки, которые невозможно предугадать, их даже найти бывает сложно, но при этом они парализуют систему. При чём тут телефония? Оказалось, что база виснет, потому что каждые 5 минут происходит аварийный перезапуск сервера 1С. Почему? Непонятно. Но заметили, что если отключить телефонию MIKO, то зависания прекращаются. Как раз 2 дня назад мы её обновляли: «Вот в чём причина!», — подумали мы и радостно откатили телефонию до предыдущей версии. Но зависания продолжились. В журнале регистраций никаких признаков проблемы не нашли. Проблемы нет, постоянный перезапуск есть. Мы даже в Google не могли ответ поискать — непонятно, как запрос сформулировать. Но телефония в этом как-то замешана, ведь если её отключаем, то перезапуск не происходит. Поэтому обратились к разработчикам MIKO. Вместе со специалистами телефонии собрали технологические журналы и обнаружили ошибку в самой платформе 1С. Из-за чего ошибка-то? Чтобы клиенты видели, с кем общаются в данный момент, на панели телефонии отображается фото сотрудника. Телефония цепляет это фото с нашей базы 1С. Технологические журналы показали, что ошибка в одной из таких фотографий, но с какой именно, и что с ней не так — непонятно. Мы сделали специальную обработку, которая переоткрывала все фотографии сотрудников, и методом перебора нашли фото, которое остановило работу 150 человек на полдня. Оказалось, за день до этого мы добавляли на сайт фото новых сотрудников, и одну фотографию случайно загрузили в формате TIFF очень большого размера. При открывании фото всё было нормально, ошибка возникала, когда платформа 1С преобразовывала фотографию в спецформат, чтобы передать её в телефонию. Эта ошибка была и есть в платформе 1С. Столкнуться с этой ошибкой было практически невозможно, но мы справились:) Теперь тщательнее следим за тем, какого формата фотографии добавляем. Всего на полдня, но всё же — 150 человек не могли работать, потому что база 1С полностью зависала каждые 5 минут. Это история о том, что иногда случаются ошибки, которые невозможно предугадать, их даже найти бывает сложно, но при этом они парализуют систему. При чём тут телефония? Оказалось, что база виснет, потому что каждые 5 минут происходит аварийный перезапуск сервера 1С. Почему? Непонятно. Но заметили, что если отключить телефонию MIKO, то зависания прекращаются. Как раз 2 дня назад мы её обновляли: «Вот в чём причина!», — подумали мы и радостно откатили телефонию до предыдущей версии. Но зависания продолжились. В журнале регистраций никаких признаков проблемы не нашли. Проблемы нет, постоянный перезапуск есть. Мы даже в Google не могли ответ поискать — непонятно, как запрос сформулировать. Но телефония в этом как-то замешана, ведь если её отключаем, то перезапуск не происходит. Поэтому обратились к разработчикам MIKO. Вместе со специалистами телефонии собрали технологические журналы и обнаружили ошибку в самой платформе 1С. Из-за чего ошибка-то? Чтобы клиенты видели, с кем общаются в данный момент, на панели телефонии отображается фото сотрудника. Телефония цепляет это фото с нашей базы 1С. Технологические журналы показали, что ошибка в одной из таких фотографий, но с какой именно, и что с ней не так — непонятно. Мы сделали специальную обработку, которая переоткрывала все фотографии сотрудников, и методом перебора нашли фото, которое остановило работу 150 человек на полдня. Оказалось, за день до этого мы добавляли на сайт фото новых сотрудников, и одну фотографию случайно загрузили в формате TIFF очень большого размера. При открывании фото всё было нормально, ошибка возникала, когда платформа 1С преобразовывала фотографию в спецформат, чтобы передать её в телефонию. Эта ошибка была и есть в платформе 1С. Столкнуться с этой ошибкой было практически невозможно, но мы справились:) Теперь тщательнее следим за тем, какого формата фотографии добавляем.

Смотреть

Как одна фотография 150 человек без работы оставила

В Простых решениях около 100 сотрудников. Зарплатный и кадровый учёт ведут наши консультанты по зарплате. То есть они работают и с клиентами, и с коллегами. Мы внедрили сервис 1С-Кабинет сотрудника именно для того, чтобы упростить решение кадровых вопросов внутри компании и облегчить работу консультантов по зарплате. 4 самые частые задачи, которые решали наши консультанты по зарплате Справки для сотрудников: от 4 до 10 штук в месяц. Обращались за ними кому как удобно: лично, по телефону, по почте, в мессенджерах. Работа с каждым сотрудником занимала 10–20 минут. С ростом числа сотрудников обработка таких обращений стала отнимать много рабочего времени. Вопросы по информации в расчётных листках, которые было сложно обсуждать здесь и сейчас. Поэтому приходилось тратить время и восстанавливать цепочку обсуждения. Согласование отпусков. Приходилось прилагать дополнительные усилия, чтобы, с одной стороны, сохранить для сотрудников их гибкость планирования, а с другой — избежать неравномерной загруженности отделов. Работа с удалёнными сотрудниками. С ними нужно было подписывать различные кадровые документы удалённо. Как изменилась работа после внедрения сервиса 1С-Кабинет сотрудника Вопросы по остаткам отпусков решаются самостоятельно сотрудником без участия расчётного отдела. Сотрудник в личном кабинете видит актуальный остаток отпуска на текущий день или на заданную дату. Теперь для этого не нужно ходить в расчётный отдел. Соответственно, сотрудники расчётного отдела больше не тратят на это своё время. Общение с сотрудниками происходит прямо в сервисе 1С-Кабинет сотрудника. Если возникает вопрос по расчётным листкам, то обсуждение ведётся в рамках специализированного канала — теперь не нужно искать, где и когда задали вопрос по зарплате, всё в одном месте. Вопросы с сотрудниками-удалёнщиками решаются без распечатки кадровых приказов, а с использованием сервиса КЭДО, который законодательно разрешён для подписания кадровых документов. Сотрудник бесплатно получает Усиленную неквалифицированную электронную подпись (УНЭП) в 1С:Кабинет сотрудника, которая потом хранится в этом же сервисе. И подписывает приказы прямо в сервисе кабинета. Освобождается время консультанта-расчётчика, так как раньше надо было распечатать и отправить по почте приказы на подпись. К тому же такой подход экономит деньги, ведь не нужно оплачивать почтовые отправления. Настроили согласование отпуска по отделам. Исключили возможность ухода в отпуск сотрудника без согласования с руководителем. Наталья — сотрудник, который собирается в отпуск. Юлия — её руководитель, которая увидит заявление Натальи и согласует его. Вячеслав — руководитель отдела, в столбике слева список сотрудников, которые согласовывают свой отпуск с ним. Сотрудник формирует заявление на отсутствие прямо из кабинета сотрудника, его согласовывает непосредственный руководитель, бухгалтер-расчётчик видит его в программе. Консультанту-расчётчику не надо быть постоянно в программе и следить за запросами. Если появилось какое-то новое заявление, то приходит оповещение на почту. Результаты внедрения 1С-Кабинет сотрудника Сотрудники не тратят своё время на походы в расчётный отдел. Всю информацию по отпускам и расчётным листкам сотрудник видит в приложении на смартфоне. Продуктивность расчётного отдела повысилась, так как они не отвлекаются на визиты сотрудников и поиск нужной информации. Все обсуждения по кадровым и зарплатным вопросам в одном месте. В Простых решениях около 100 сотрудников. Зарплатный и кадровый учёт ведут наши консультанты по зарплате. То есть они работают и с клиентами, и с коллегами. Мы внедрили сервис 1С-Кабинет сотрудника именно для того, чтобы упростить решение кадровых вопросов внутри компании и облегчить работу консультантов по зарплате. 4 самые частые задачи, которые решали наши консультанты по зарплате Справки для сотрудников: от 4 до 10 штук в месяц. Обращались за ними кому как удобно: лично, по телефону, по почте, в мессенджерах. Работа с каждым сотрудником занимала 10–20 минут. С ростом числа сотрудников обработка таких обращений стала отнимать много рабочего времени. Вопросы по информации в расчётных листках, которые было сложно обсуждать здесь и сейчас. Поэтому приходилось тратить время и восстанавливать цепочку обсуждения. Согласование отпусков. Приходилось прилагать дополнительные усилия, чтобы, с одной стороны, сохранить для сотрудников их гибкость планирования, а с другой — избежать неравномерной загруженности отделов. Работа с удалёнными сотрудниками. С ними нужно было подписывать различные кадровые документы удалённо. Как изменилась работа после внедрения сервиса 1С-Кабинет сотрудника Вопросы по остаткам отпусков решаются самостоятельно сотрудником без участия расчётного отдела. Сотрудник в личном кабинете видит актуальный остаток отпуска на текущий день или на заданную дату. Теперь для этого не нужно ходить в расчётный отдел. Соответственно, сотрудники расчётного отдела больше не тратят на это своё время. Общение с сотрудниками происходит прямо в сервисе 1С-Кабинет сотрудника. Если возникает вопрос по расчётным листкам, то обсуждение ведётся в рамках специализированного канала — теперь не нужно искать, где и когда задали вопрос по зарплате, всё в одном месте. Вопросы с сотрудниками-удалёнщиками решаются без распечатки кадровых приказов, а с использованием сервиса КЭДО, который законодательно разрешён для подписания кадровых документов. Сотрудник бесплатно получает Усиленную неквалифицированную электронную подпись (УНЭП) в 1С:Кабинет сотрудника, которая потом хранится в этом же сервисе. И подписывает приказы прямо в сервисе кабинета. Освобождается время консультанта-расчётчика, так как раньше надо было распечатать и отправить по почте приказы на подпись. К тому же такой подход экономит деньги, ведь не нужно оплачивать почтовые отправления. Настроили согласование отпуска по отделам. Исключили возможность ухода в отпуск сотрудника без согласования с руководителем. Наталья — сотрудник, который собирается в отпуск. Юлия — её руководитель, которая увидит заявление Натальи и согласует его. Вячеслав — руководитель отдела, в столбике слева список сотрудников, которые согласовывают свой отпуск с ним. Сотрудник формирует заявление на отсутствие прямо из кабинета сотрудника, его согласовывает непосредственный руководитель, бухгалтер-расчётчик видит его в программе. Консультанту-расчётчику не надо быть постоянно в программе и следить за запросами. Если появилось какое-то новое заявление, то приходит оповещение на почту. Результаты внедрения 1С-Кабинет сотрудника Сотрудники не тратят своё время на походы в расчётный отдел. Всю информацию по отпускам и расчётным листкам сотрудник видит в приложении на смартфоне. Продуктивность расчётного отдела повысилась, так как они не отвлекаются на визиты сотрудников и поиск нужной информации. Все обсуждения по кадровым и зарплатным вопросам в одном месте.

Смотреть

Как мы внедрили 1С-Кабинет сотрудника и решили 4 проблемы наших бухгалтеров

Начиная работать с ЭДО, может возникнуть необходимость перестроить процессы, которые были в организации при обмене бумажным документами. При переходе на ЭДО нужно определить, кто будет: настраивать ЭДО и решать технические вопросы связанные с ним принимать и подписывать входящие документы делать сверку взаиморасчетов отправлять документы покупателям организовывать хранение документов Если компания небольшая и небольшой оборот документов, эти функции может выполнять один сотрудник. Мы распределили задачи по ЭДО между несколькими сотрудниками. В этой статье рассказываем, как организовали работу с ЭДО в Простых решениях. Подключение ЭДО Чтобы подключить ЭДО, нужно знать много технических нюансов, поэтому данному процессу мы обучили наш отдел Сервис-инженеров. Они помогают клиентам с подключением, смотрят ошибки ЭДО. Также они настраивали подключение для нашей компании. Сейчас сервис-инженеры помогают нашим сотрудникам, ответственным за ЭДО, разбираться с ошибками и проблемами в приеме и отправке документов. Входящие документы Приемка Прием документов у нас осуществляется в ручном режиме — принимать документы может любой менеджер. Но данный процесс можно автоматизировать, настроив по расписанию загрузку документов в базу, чтобы не держать в голове постоянно задачу о необходимости принять документы. В этом случае ЭЦП и программы для работы с ними должны быть установлены на Сервере 1С. Подписание документов После получения документа он попадает на вкладку Утвердить. Данную функцию могут выполнять несколько человек или один: все зависит от объема документов и ваших процессов. Изначально у нас принимали документы все менеджеры без какой-либо схемы. Это приводило к тому, что многие документы могли быть долго неподписанными. Мы решили разделить входящие документы по определенным критериям и делегировали каждый блок отдельному человеку. Возникла сложность: на рабочем столе были видны все документы. Менеджеры могли подписать не свой документ или не заметить неподписанный документ. Мы сделали простую доработку, которая при записи электронного документа по заданному алгоритму представляла нужного ответственного менеджера. После этой доработки сотрудник может настроить фильтр и на вкладке Утвердить видеть только те документы, которые ему нужно подписать. Сверка взаиморасчетов Приемом документов и утверждением у нас занимаются менеджеры, а сверку взаиморасчетов с поставщиками уже делает бухгалтер. Исходящие документы Отправка документов Отправка документов у нас разбита по ответственным менеджерам. Если менеджер ведет сделку с покупателем, он и отправляет документы по ЭДО, а также контролирует, подписан ли документ со стороны клиента. Также у нас имеется массовая выписка реализаций. Обработка сама отправляет документы по ЭДО, а ответственный за клиента менеджер контролирует документооборот. Хранение документов Как правило, бумажные документы бухгалтеры хранят по папкам двумя способами: 1. Все поставщики в одной папке 2. Для каждого поставщика своя папка. Мы предлагаем небольшой лайфхак: когда вы уже перешли на ЭДО с контрагентом, в папку с бумажными документами добавьте информацию, с какого числа вы перешли на ЭДО. Это поможет при поиске быстро понять, что документов на бумажном носителе нет, и их стоит искать в хранилище системы ЭДО. Переход на ЭДО упрощает жизнь бухгалтера, но нужно знать, что у него появятся новые задачи. На первом этапе внедрения ЭДО необходимо определить их: Кто загружает документы? Кто отправляет? Кто разбирает ошибки? Кто отправляет приглашения на обмен ЭДО контрагентом? Кто контролирует, что все сообщения разобраны? После нужно назначить ответственного на каждую задачу, чтобы документы всегда были вовремя приняты, исправлены и отправлены. Начиная работать с ЭДО, может возникнуть необходимость перестроить процессы, которые были в организации при обмене бумажным документами. При переходе на ЭДО нужно определить, кто будет: настраивать ЭДО и решать технические вопросы связанные с ним принимать и подписывать входящие документы делать сверку взаиморасчетов отправлять документы покупателям организовывать хранение документов Если компания небольшая и небольшой оборот документов, эти функции может выполнять один сотрудник. Мы распределили задачи по ЭДО между несколькими сотрудниками. В этой статье рассказываем, как организовали работу с ЭДО в Простых решениях. Подключение ЭДО Чтобы подключить ЭДО, нужно знать много технических нюансов, поэтому данному процессу мы обучили наш отдел Сервис-инженеров. Они помогают клиентам с подключением, смотрят ошибки ЭДО. Также они настраивали подключение для нашей компании. Сейчас сервис-инженеры помогают нашим сотрудникам, ответственным за ЭДО, разбираться с ошибками и проблемами в приеме и отправке документов. Входящие документы Приемка Прием документов у нас осуществляется в ручном режиме — принимать документы может любой менеджер. Но данный процесс можно автоматизировать, настроив по расписанию загрузку документов в базу, чтобы не держать в голове постоянно задачу о необходимости принять документы. В этом случае ЭЦП и программы для работы с ними должны быть установлены на Сервере 1С. Подписание документов После получения документа он попадает на вкладку Утвердить. Данную функцию могут выполнять несколько человек или один: все зависит от объема документов и ваших процессов. Изначально у нас принимали документы все менеджеры без какой-либо схемы. Это приводило к тому, что многие документы могли быть долго неподписанными. Мы решили разделить входящие документы по определенным критериям и делегировали каждый блок отдельному человеку. Возникла сложность: на рабочем столе были видны все документы. Менеджеры могли подписать не свой документ или не заметить неподписанный документ. Мы сделали простую доработку, которая при записи электронного документа по заданному алгоритму представляла нужного ответственного менеджера. После этой доработки сотрудник может настроить фильтр и на вкладке Утвердить видеть только те документы, которые ему нужно подписать. Сверка взаиморасчетов Приемом документов и утверждением у нас занимаются менеджеры, а сверку взаиморасчетов с поставщиками уже делает бухгалтер. Исходящие документы Отправка документов Отправка документов у нас разбита по ответственным менеджерам. Если менеджер ведет сделку с покупателем, он и отправляет документы по ЭДО, а также контролирует, подписан ли документ со стороны клиента. Также у нас имеется массовая выписка реализаций. Обработка сама отправляет документы по ЭДО, а ответственный за клиента менеджер контролирует документооборот. Хранение документов Как правило, бумажные документы бухгалтеры хранят по папкам двумя способами: 1. Все поставщики в одной папке 2. Для каждого поставщика своя папка. Мы предлагаем небольшой лайфхак: когда вы уже перешли на ЭДО с контрагентом, в папку с бумажными документами добавьте информацию, с какого числа вы перешли на ЭДО. Это поможет при поиске быстро понять, что документов на бумажном носителе нет, и их стоит искать в хранилище системы ЭДО. Переход на ЭДО упрощает жизнь бухгалтера, но нужно знать, что у него появятся новые задачи. На первом этапе внедрения ЭДО необходимо определить их: Кто загружает документы? Кто отправляет? Кто разбирает ошибки? Кто отправляет приглашения на обмен ЭДО контрагентом? Кто контролирует, что все сообщения разобраны? После нужно назначить ответственного на каждую задачу, чтобы документы всегда были вовремя приняты, исправлены и отправлены.

Смотреть

ЭДО: как у нас устроен процесс учета электронных документов

Обычно серверы называют просто «сервер» или «сервер 1С». У нас серверы — это персонажи. Серверы-супергерои Сначала мы назвали серверы по вселенной Marvel. Железный человек — наш первый сервер, а Халк — самый мощный, на нем работает наша основная база. Следующий сервер мы назвали Бэтмен, хотя кто-то возражал — это же из другой вселенной! Так нельзя, как они могут быть в одной локальной сети? Сейчас на Бэтмене все работают, и он всем помогает :) Если сотрудник работает удаленно, он подключается через Бэтмена. А Робин снимает с него часть нагрузки. Тор — мощный сервер, на котором мы работаем с клиентскими базами. Сервер с виртуальными серверами — Готэм, потому что можно сказать, что в нем живут разные сервера, виртуальные герои. Еще у нас есть Трэшмен. Такого героя еще не существовало, у нас это файловое хранилище. Чтобы не путаться, на каждом компьютере настроен рабочий стол: если подключаешься к Халку, картинка тоже будет с Халком. Когда в кинотеатре шел очередной марвеловский фильм, мы купили там фигурки специально для серверной. Ironman, наш самый первый сервер, устарел. Сейчас мы готовимся к тому, что он скоро умрет. Обычно серверы называют просто «сервер» или «сервер 1С». У нас серверы — это персонажи. Серверы-супергерои Сначала мы назвали серверы по вселенной Marvel. Железный человек — наш первый сервер, а Халк — самый мощный, на нем работает наша основная база. Следующий сервер мы назвали Бэтмен, хотя кто-то возражал — это же из другой вселенной! Так нельзя, как они могут быть в одной локальной сети? Сейчас на Бэтмене все работают, и он всем помогает :) Если сотрудник работает удаленно, он подключается через Бэтмена. А Робин снимает с него часть нагрузки. Тор — мощный сервер, на котором мы работаем с клиентскими базами. Сервер с виртуальными серверами — Готэм, потому что можно сказать, что в нем живут разные сервера, виртуальные герои. Еще у нас есть Трэшмен. Такого героя еще не существовало, у нас это файловое хранилище. Чтобы не путаться, на каждом компьютере настроен рабочий стол: если подключаешься к Халку, картинка тоже будет с Халком. Когда в кинотеатре шел очередной марвеловский фильм, мы купили там фигурки специально для серверной. Ironman, наш самый первый сервер, устарел. Сейчас мы готовимся к тому, что он скоро умрет.

Смотреть

Серверы-супергерои. Почему все работают на Бэтмене, и как мы похоронили Айронмена

Мы используем внутренний телеграм-бот для своих сотрудников и внешний для ребят на аутсорсе. Основная задача бота — быстро находить исполнителя задачи, чтобы клиентам не нужно было долго ждать. Но еще мы добавляем довольно неожиданные команды, чтобы порадовать наших сотрудников. Например, на Восьмое марта бот генерировал поздравления и комплименты. Рассказываем, почему мы решили, что нам нужен бот, и какими функциями пользуемся каждый день. Сначала исполнителя искал диспетчер Когда у нас в команде было меньше человек, заявки принимал диспетчер. Мы все сидели в одном помещении и она спрашивала у каждого, возьмется ли он за эту задачу. Для этого диспетчеру нужно было помнить, кто в чем компетентен. А потом приходилось на всякий случай перезванивать сотруднику и напоминать о задаче. Следующим шагом после звонков была рассылка. Всем потенциальным исполнителям уходило письмо о том, что поступило такое-то обращение. Но в письме тогда не было никаких элементов управления, чтобы сотрудник быстро ответил, берет он задачу или нет. Сотрудники по рознице могли быть в этот момент в разъездах, например, настраивать кассу в магазине у клиента. Не было уверенности, что они это письмо увидели. Теперь исполнителя находит бот Сейчас заявки от клиентов принимают несколько сотрудников первой линии. Они кратко описывают задачу и определяют тип обращения — Бухгалтерия, Зарплата, ЖКХ и так далее. Разные виды обращений заранее закреплены за специалистами, которые лучше всего в них разбираются. Так оповещение о новой задаче приходит всем потенциальным исполнителям на рабочий стол и в мессенджер. Если сотрудник берется за задачу, он нажимает Взять в работу и указывает срок, когда обещает её начать. При этом другие сотрудники могут оставлять к задаче комментарии. Если они уже работали с этим клиентом или сталкивались с похожей проблемой, они подскажут, на что стоит обратить внимание. Так можно что-то обсудить в комментариях и помочь коллегам, пока сам находишься в дороге или дозваниваешься до клиента. Бот помогает сориентироваться по дежурным У нас есть дежурства — кто-то из ребят отдела Розницы всегда на связи в выходные дни. Если клиент позвонит в субботу или воскресенье, сообщения не будут дергать всех потенциальных исполнителей в выходной день, будут приходить только к нему. В боте можно посмотреть, кто сегодня дежурит. Бот подсказывает, когда у кого день рождения и помогает свериться с фото, если кто-то забыл, как выглядят коллеги :) У нас в команде уже больше ста человек, офис находится в нескольких домах на одном участке — бывает, что приходят новенькие, и еще не со всеми познакомились. В такой большой команде мы боялись, что пропустим чей-то день рождения. Сейчас накануне дня рождения и в сам день бот подсказывает, кого мы будем поздравлять. Еще с новичками бывает так: коллеги тебе сказали к кому обратиться по какому-то вопросу, а ты не знаешь, кто это. В боте есть команда Whois — набираешь фамилию, и можно посмотреть фото, день рождения телефон и должность. Еще можно подписаться на рефлексию от бота: каждый день он просит ответить на несколько вопросов в конце для. Ну, или сам можешь порефлексировать, когда захочется. Мы используем внутренний телеграм-бот для своих сотрудников и внешний для ребят на аутсорсе. Основная задача бота — быстро находить исполнителя задачи, чтобы клиентам не нужно было долго ждать. Но еще мы добавляем довольно неожиданные команды, чтобы порадовать наших сотрудников. Например, на Восьмое марта бот генерировал поздравления и комплименты. Рассказываем, почему мы решили, что нам нужен бот, и какими функциями пользуемся каждый день. Сначала исполнителя искал диспетчер Когда у нас в команде было меньше человек, заявки принимал диспетчер. Мы все сидели в одном помещении и она спрашивала у каждого, возьмется ли он за эту задачу. Для этого диспетчеру нужно было помнить, кто в чем компетентен. А потом приходилось на всякий случай перезванивать сотруднику и напоминать о задаче. Следующим шагом после звонков была рассылка. Всем потенциальным исполнителям уходило письмо о том, что поступило такое-то обращение. Но в письме тогда не было никаких элементов управления, чтобы сотрудник быстро ответил, берет он задачу или нет. Сотрудники по рознице могли быть в этот момент в разъездах, например, настраивать кассу в магазине у клиента. Не было уверенности, что они это письмо увидели. Теперь исполнителя находит бот Сейчас заявки от клиентов принимают несколько сотрудников первой линии. Они кратко описывают задачу и определяют тип обращения — Бухгалтерия, Зарплата, ЖКХ и так далее. Разные виды обращений заранее закреплены за специалистами, которые лучше всего в них разбираются. Так оповещение о новой задаче приходит всем потенциальным исполнителям на рабочий стол и в мессенджер. Если сотрудник берется за задачу, он нажимает Взять в работу и указывает срок, когда обещает её начать. При этом другие сотрудники могут оставлять к задаче комментарии. Если они уже работали с этим клиентом или сталкивались с похожей проблемой, они подскажут, на что стоит обратить внимание. Так можно что-то обсудить в комментариях и помочь коллегам, пока сам находишься в дороге или дозваниваешься до клиента. Бот помогает сориентироваться по дежурным У нас есть дежурства — кто-то из ребят отдела Розницы всегда на связи в выходные дни. Если клиент позвонит в субботу или воскресенье, сообщения не будут дергать всех потенциальных исполнителей в выходной день, будут приходить только к нему. В боте можно посмотреть, кто сегодня дежурит. Бот подсказывает, когда у кого день рождения и помогает свериться с фото, если кто-то забыл, как выглядят коллеги :) У нас в команде уже больше ста человек, офис находится в нескольких домах на одном участке — бывает, что приходят новенькие, и еще не со всеми познакомились. В такой большой команде мы боялись, что пропустим чей-то день рождения. Сейчас накануне дня рождения и в сам день бот подсказывает, кого мы будем поздравлять. Еще с новичками бывает так: коллеги тебе сказали к кому обратиться по какому-то вопросу, а ты не знаешь, кто это. В боте есть команда Whois — набираешь фамилию, и можно посмотреть фото, день рождения телефон и должность. Еще можно подписаться на рефлексию от бота: каждый день он просит ответить на несколько вопросов в конце для. Ну, или сам можешь порефлексировать, когда захочется.

Смотреть

Как мы находим исполнителя с помощью бота в телеграме

Сейчас у нас работают три линии поддержки. Мы создали систему обращений и тестируем разные варианты, чтобы быстрее обрабатывать заявки клиентов. К примеру, сначала у нас принимали звонки клиентские менеджеры, потом консультанты, а теперь снова менеджеры — и получается быстрее. Сейчас расскажем, почему. Важно, чтобы дежурный определял сложность задачи Сначала звонки принимали клиентские менеджеры — один, потом уже несколько. Но менеджеры не могли решить проблему клиента, они только фиксировали вид обращения и передали его в очередь. Из-за этого получалось так, что простой вопрос мог пролежать в очереди два дня, потом консультант звонил клиенту и помогал ему за пару минут. Конечно, это вызывало раздражение — если это так просто, почему сразу нельзя было сделать? Нужно было, чтобы дежурный определял, насколько сложная у клиента задача. Если совсем простая, помогал бы сразу, а если сложная — хотя бы примерно обозначил сроки. Мы решили, что дежурить будут консультанты. Но через какое-то время мы посчитали, что 50% звонков получаются ложными — дежурный разбирается в бухгалтерии, а ему поступает звонок про кассы, и он тоже не может помочь сразу. При этом теряет время на звонки и не решает задачи, в которых он силен. В каждом отделе свои дежурные — первая линия поддержки Мы сделали гибридный вариант. Звонки от клиентов снова принимают менеджеры, как мы и работали в начале. Они фиксируют обращение и определяют его тип — про что это вопрос, например, по Бухгалтерии или по ЖКХ. И дальше они переводят звонок на дежурного нужного отдела — на первую линию. Сейчас у нас три линии поддержки. На первой лини дежурный сотрудник оценивает задачу, и либо решает ее сразу, либо передаёт ее на вторую линию. На второй линии работают более опытные сотрудники. Задача попадает к ним в очередь, и клиенту нужно подождать какое-то время. Но ему уже не придется ждать ради решения простого вопроса — их может решить дежурный. Мы придумали систему мотивации для тех, кто с ходу решает вопрос клиента. Если дежурный консультант решает задачу за полчаса — то есть не переводит клиента на другого специалиста, не перезванивает ему, а помогает ему сам и сразу, эти задачи оплачиваются в три раза выше обычных. Для клиента, конечно, разницы по оплате не будет. Мы собираем статистику, сколько заявок закрыто сразу, и этот процент растет. Есть еще третья линия поддержки — руководители, самые опытные сотрудники. К ним обращаются в самых сложных ситуациях. Заявок больше, отвечаем быстрее С каждым годом заявок становится больше. Во-первых, растет число клиентов. Во-вторых, у клиентов появляются новые вопросы: по маркировке, по изменениям из-за коронавируса. Многие компаний внедряют управленческий учет. На этом графике видно, как число обращений поквартально росло с 2018 года: А здесь процент обращений, закрытых в 2021 году на первой линии — то есть когда дежурный нужного отдела сразу, в течение получаса, решает задачу клиента: В октябре на графике небольшой спад, потому что идет отчетность, и вопросы по ней не получается решать быстро :) Эти задачи попадают в общую очередь. Сейчас у нас работают три линии поддержки. Мы создали систему обращений и тестируем разные варианты, чтобы быстрее обрабатывать заявки клиентов. К примеру, сначала у нас принимали звонки клиентские менеджеры, потом консультанты, а теперь снова менеджеры — и получается быстрее. Сейчас расскажем, почему. Важно, чтобы дежурный определял сложность задачи Сначала звонки принимали клиентские менеджеры — один, потом уже несколько. Но менеджеры не могли решить проблему клиента, они только фиксировали вид обращения и передали его в очередь. Из-за этого получалось так, что простой вопрос мог пролежать в очереди два дня, потом консультант звонил клиенту и помогал ему за пару минут. Конечно, это вызывало раздражение — если это так просто, почему сразу нельзя было сделать? Нужно было, чтобы дежурный определял, насколько сложная у клиента задача. Если совсем простая, помогал бы сразу, а если сложная — хотя бы примерно обозначил сроки. Мы решили, что дежурить будут консультанты. Но через какое-то время мы посчитали, что 50% звонков получаются ложными — дежурный разбирается в бухгалтерии, а ему поступает звонок про кассы, и он тоже не может помочь сразу. При этом теряет время на звонки и не решает задачи, в которых он силен. В каждом отделе свои дежурные — первая линия поддержки Мы сделали гибридный вариант. Звонки от клиентов снова принимают менеджеры, как мы и работали в начале. Они фиксируют обращение и определяют его тип — про что это вопрос, например, по Бухгалтерии или по ЖКХ. И дальше они переводят звонок на дежурного нужного отдела — на первую линию. Сейчас у нас три линии поддержки. На первой лини дежурный сотрудник оценивает задачу, и либо решает ее сразу, либо передаёт ее на вторую линию. На второй линии работают более опытные сотрудники. Задача попадает к ним в очередь, и клиенту нужно подождать какое-то время. Но ему уже не придется ждать ради решения простого вопроса — их может решить дежурный. Мы придумали систему мотивации для тех, кто с ходу решает вопрос клиента. Если дежурный консультант решает задачу за полчаса — то есть не переводит клиента на другого специалиста, не перезванивает ему, а помогает ему сам и сразу, эти задачи оплачиваются в три раза выше обычных. Для клиента, конечно, разницы по оплате не будет. Мы собираем статистику, сколько заявок закрыто сразу, и этот процент растет. Есть еще третья линия поддержки — руководители, самые опытные сотрудники. К ним обращаются в самых сложных ситуациях. Заявок больше, отвечаем быстрее С каждым годом заявок становится больше. Во-первых, растет число клиентов. Во-вторых, у клиентов появляются новые вопросы: по маркировке, по изменениям из-за коронавируса. Многие компаний внедряют управленческий учет. На этом графике видно, как число обращений поквартально росло с 2018 года: А здесь процент обращений, закрытых в 2021 году на первой линии — то есть когда дежурный нужного отдела сразу, в течение получаса, решает задачу клиента: В октябре на графике небольшой спад, потому что идет отчетность, и вопросы по ней не получается решать быстро :) Эти задачи попадают в общую очередь.

Смотреть

Кто должен отвечать на звонки клиентов

Мы уже рассказывали, как собрали в одну систему сообщения клиентов из всех мессенджеров. Так мы видим историю обращений клиента, и консультировать его смогут разные сотрудники — вся информация уже собрана в учетке, не надо ничего переспрашивать у коллег. Для некоторых задач мы сделали еще одну интеграцию — с таск-менеджером Асаной. Рассказываем, в каких ситуациях нам это помогает. Когда нужен таск-менеджер. Режим сопровождения VS Проектная деятельность С большей частью клиентов мы работаем в режиме сопровождения — у клиентов периодически возникают вопросы, и мы быстро помогаем их решить. Для этого достаточно бывает поговорить по телефону или ответить в мессенджере. Это разовые задачи, и инструменты для управления проектами здесь не нужны. Но когда к нам приходит новый клиент или появляется большая задача по автоматизации бизнеса, процесс разбивается на множество подзадач. В работу включается больше людей — и с нашей стороны, и со стороны клиента. Например, мы занимаемся внедрением 1С:УНФ. Работают специалисты по складу, по бухгалтерии, задачи курируют их руководители, сотрудники клиента из разных отделов тоже оставляют свои комментарии. Нужно знать, что происходит с каждой задачей проекта в текущий момент времени и обсуждать конкретно этот участок работ — а в чате мы бы писали сотни сообщений вразнобой. Клиент имеет доступ к доске таск-менеджера и видит, что происходит При внедрениях мы стали использовать облачную систему Asana. Это как раз инструмент, который помогает контролировать проектную деятельность. Мы заводим проект под каждого клиента, и клиент имеет доступ к своей доске в Асане. На доске выделяем столбцы для разных статусов задачи: идеи, в работе, на следующий спринт. Клиент может сам добавлять задачи и двигать их по столбцам, если, например, что-то уже проверил и нужно идти по процессу дальше. Мы со своей стороны тоже перемещаем задачу, когда какую-то часть уже закончили — так клиент знает, что сейчас происходит в проекте. В карточках на доске оставляем комментарии, задаем вопросы, так что если подключаются другие сотрудники, контекст сразу понятен. Настроили интеграцию с Асаной так, чтобы не приходилось копировать туда информацию В проектной работе нам тоже важно, чтобы специалисты не запутались в учетных системах. Нашим сотрудникам удобнее работать в 1С, а не в таск-менеджере, поэтому мы сделали интеграцию 1С с Асаной. Когда задача получает в Асане статус «В работу» или «На следующий спринт», она дублируется в нашу учетную систему. Дальше система формирует обращение или задание программисту — так же, как если бы это была задача по звонку клиента. В итоге программисту вообще не надо заходить в Асану. Он работает как обычно, в нашей учетной системе, если нужно, оставляет комментарии. Когда он отмечает задачу как решенную, система переносит ее в нужный столбец Асаны со всеми комментариями. Туда же система добавляет информацию, сколько часов ушло у программиста на эту задачу, чтобы клиент сориентировалася по затраченному времени. Мы уже рассказывали, как собрали в одну систему сообщения клиентов из всех мессенджеров. Так мы видим историю обращений клиента, и консультировать его смогут разные сотрудники — вся информация уже собрана в учетке, не надо ничего переспрашивать у коллег. Для некоторых задач мы сделали еще одну интеграцию — с таск-менеджером Асаной. Рассказываем, в каких ситуациях нам это помогает. Когда нужен таск-менеджер. Режим сопровождения VS Проектная деятельность С большей частью клиентов мы работаем в режиме сопровождения — у клиентов периодически возникают вопросы, и мы быстро помогаем их решить. Для этого достаточно бывает поговорить по телефону или ответить в мессенджере. Это разовые задачи, и инструменты для управления проектами здесь не нужны. Но когда к нам приходит новый клиент или появляется большая задача по автоматизации бизнеса, процесс разбивается на множество подзадач. В работу включается больше людей — и с нашей стороны, и со стороны клиента. Например, мы занимаемся внедрением 1С:УНФ. Работают специалисты по складу, по бухгалтерии, задачи курируют их руководители, сотрудники клиента из разных отделов тоже оставляют свои комментарии. Нужно знать, что происходит с каждой задачей проекта в текущий момент времени и обсуждать конкретно этот участок работ — а в чате мы бы писали сотни сообщений вразнобой. Клиент имеет доступ к доске таск-менеджера и видит, что происходит При внедрениях мы стали использовать облачную систему Asana. Это как раз инструмент, который помогает контролировать проектную деятельность. Мы заводим проект под каждого клиента, и клиент имеет доступ к своей доске в Асане. На доске выделяем столбцы для разных статусов задачи: идеи, в работе, на следующий спринт. Клиент может сам добавлять задачи и двигать их по столбцам, если, например, что-то уже проверил и нужно идти по процессу дальше. Мы со своей стороны тоже перемещаем задачу, когда какую-то часть уже закончили — так клиент знает, что сейчас происходит в проекте. В карточках на доске оставляем комментарии, задаем вопросы, так что если подключаются другие сотрудники, контекст сразу понятен. Настроили интеграцию с Асаной так, чтобы не приходилось копировать туда информацию В проектной работе нам тоже важно, чтобы специалисты не запутались в учетных системах. Нашим сотрудникам удобнее работать в 1С, а не в таск-менеджере, поэтому мы сделали интеграцию 1С с Асаной. Когда задача получает в Асане статус «В работу» или «На следующий спринт», она дублируется в нашу учетную систему. Дальше система формирует обращение или задание программисту — так же, как если бы это была задача по звонку клиента. В итоге программисту вообще не надо заходить в Асану. Он работает как обычно, в нашей учетной системе, если нужно, оставляет комментарии. Когда он отмечает задачу как решенную, система переносит ее в нужный столбец Асаны со всеми комментариями. Туда же система добавляет информацию, сколько часов ушло у программиста на эту задачу, чтобы клиент сориентировалася по затраченному времени.

Смотреть

Как мы интегрировали Асану с внутренней учетной системой

Есть два подхода к работе с клиентами — ждать, чтобы другие подстраивались под твои условия или быть гибким самому. Например, можно сказать: «Не пишите нам, только звоните». Или «Пишите нам только в телеграме, это лучший мессенджер, другими не пользуемся». Мы считаем, что покупатели привыкли к гибкости, и подстраиваться должны не они, а мы. Если человеку сегодня удобнее позвонить, пусть позвонит, а завтра напишет из любого мессенджера или из соцсети. При этом важно позаботиться и о сотрудниках. Если принимать звонки, мониторить почту и отвечать сразу в нескольких чатах в разных мессенджеров, человек просто разорвется. И еще и потеряет в этом хаосе какое-то обращение или звонок. Мы собрали все обращения в одну систему, чтобы сотрудникам было удобнее сориентироваться, что происходит и на что нужно отреагировать. Рассказываем, как у нас это организовано. Какими каналами коммуникациями пользуемся Чаще всего клиенты нам звонят. Второй по популярности канал — электронная почта. Письмо попадает в служебный ящик, наша система забирает письмо, определяет клиента и тип обращения — к примеру, это звонок про кассы или про расчет зарплаты. После этого система будет искать сотрудника, по обычному порядку нашей системы тикетов. Сотрудники тоже могут отправить любому клиенту письмо сразу из базы. Например, чтобы отправить счет, можно просто нажать в базе кнопку. Не надо ничего печатать, сканировать и прикладывать к письму — счет уже отправится с факсимиле. Еще нам часто бывает нужно удаленно подключиться к компьютеру клиента — разобраться, что происходит, и быстро ему помочь. Для этого мы пользуемся сервисом 1С-Коннект. В нем можно переписываться с клиентом, как в мессенджере, и при необходимости подключаться к его компьютеру, без лишних паролей и кодов для подключения. Когда мы удаленно работаем на компьютере клиента, можно договориться, чтобы мы сделали запись экрана, и потом клиент может пользоваться ей как видео-инструкцией. Когда клиент или его сотрудники весь день работают за компьютером, кажется, что 1С-Коннект удобнее всего. Но кто-то не хочет его устанавливать, или часто находится где-то в дороге. Им, конечно, удобнее написать в обычном мессенджере. Для работы с такими клиентов мы настроили интеграцию практически со всеми мессенджерами: телеграм вайбер вацап скайп Алиса вконтакте одноклассники Откуда бы ни написал клиент, нашему сотруднику не нужно переключаться между чатами, он видит сообщение в нашей учетной системе. А ответ клиенту придет в тот мессенджер, откуда он написал. По каждому клиенту у нас хранится журнал обращений, в нем собраны звонки, письма и сообщения из разных мессенджеров — целая база знаний по одному клиенту. Есть два подхода к работе с клиентами — ждать, чтобы другие подстраивались под твои условия или быть гибким самому. Например, можно сказать: «Не пишите нам, только звоните». Или «Пишите нам только в телеграме, это лучший мессенджер, другими не пользуемся». Мы считаем, что покупатели привыкли к гибкости, и подстраиваться должны не они, а мы. Если человеку сегодня удобнее позвонить, пусть позвонит, а завтра напишет из любого мессенджера или из соцсети. При этом важно позаботиться и о сотрудниках. Если принимать звонки, мониторить почту и отвечать сразу в нескольких чатах в разных мессенджеров, человек просто разорвется. И еще и потеряет в этом хаосе какое-то обращение или звонок. Мы собрали все обращения в одну систему, чтобы сотрудникам было удобнее сориентироваться, что происходит и на что нужно отреагировать. Рассказываем, как у нас это организовано. Какими каналами коммуникациями пользуемся Чаще всего клиенты нам звонят. Второй по популярности канал — электронная почта. Письмо попадает в служебный ящик, наша система забирает письмо, определяет клиента и тип обращения — к примеру, это звонок про кассы или про расчет зарплаты. После этого система будет искать сотрудника, по обычному порядку нашей системы тикетов. Сотрудники тоже могут отправить любому клиенту письмо сразу из базы. Например, чтобы отправить счет, можно просто нажать в базе кнопку. Не надо ничего печатать, сканировать и прикладывать к письму — счет уже отправится с факсимиле. Еще нам часто бывает нужно удаленно подключиться к компьютеру клиента — разобраться, что происходит, и быстро ему помочь. Для этого мы пользуемся сервисом 1С-Коннект. В нем можно переписываться с клиентом, как в мессенджере, и при необходимости подключаться к его компьютеру, без лишних паролей и кодов для подключения. Когда мы удаленно работаем на компьютере клиента, можно договориться, чтобы мы сделали запись экрана, и потом клиент может пользоваться ей как видео-инструкцией. Когда клиент или его сотрудники весь день работают за компьютером, кажется, что 1С-Коннект удобнее всего. Но кто-то не хочет его устанавливать, или часто находится где-то в дороге. Им, конечно, удобнее написать в обычном мессенджере. Для работы с такими клиентов мы настроили интеграцию практически со всеми мессенджерами: телеграм вайбер вацап скайп Алиса вконтакте одноклассники Откуда бы ни написал клиент, нашему сотруднику не нужно переключаться между чатами, он видит сообщение в нашей учетной системе. А ответ клиенту придет в тот мессенджер, откуда он написал. По каждому клиенту у нас хранится журнал обращений, в нем собраны звонки, письма и сообщения из разных мессенджеров — целая база знаний по одному клиенту.

Смотреть

Как мы собираем звонки и сообщения в одну учетную систему

Сейчас, осенью 2021 года, у нас 1760 клиентов. Каждый день поступает 100-200 обращений — звонки, письма или сообщения в мессенджерах. Эти задачи разного уровня сложности: бывает, что просто нужно подсказать, где нужная кнопка. Или наоборот, требуется доработка, которую программист будет писать несколько дней. Все эти обращения принимают и разбирают 60 консультантов из разных подразделений. Розница, Управление торговлей, Бухгалтерия, Зарплата и кадры — всего 8 отделов. У сотрудников внутри одного отдела компетенции тоже могут отличаться. Кто-то из Бухгалтерии глубже разбирается в налоге на прибыль и НДС, а кто-то специалист по упрощенке. Рассказываем, как мы организовали прием обращений клиентов, чтобы вопрос быстрее попадал к нужному специалисту. Сначала мы работали в одной комнате. Менеджер поднимал трубку и спрашивал, кто возьмет задачу Нельзя придумать решение, которое всегда работает. Поэтому работу с обращениями мы меняли несколько раз, по мере роста компании. Когда все мы помещались в одном кабинете, быстрее всего было делать так: менеджер отвечал на звонок клиента, и потом всех спрашивал — кто возьмет? Тот, кто был свободен, отвечал — я возьму. Тогда это было удобно и без автоматизации. Клиентов становилось больше, и когда звонил телефон, все консультанты могли быть заняты. Они могли только пообещать — я возьму, но попозже. Уже нужно было сохранять информацию: кто звонил, с какой проблемой. Мы не теряли обращения, и сотрудник не ломал голову, вспоминая, что там нужно было сделать. Так появились обращения или тикеты — документы, в которых мы фиксируем клиента, суть вопроса, прикрепляем необходимые файлы. В нем же можно посмотреть переписку с клиентом, если в ней была дополнительная информация. Сотрудник освобождался, смотрел список неразобранных обращений и брал одно из них в работу. Появились сотрудники с разной специализацией, и мы разработали автоматический поиск исполнителя Сначала одна сотрудница досконально разобралась с зарплатными вопросами. С этого началась специализация, и появился зарплатный отдел. Теперь когда клиент звонил с вопросом, к примеру, про НДФЛ, мы направляли его к этой сотруднице. А к тикетам мы добавили вид обращений — помечали, к какой области относится вопрос клиента. Отделы добавлялись, расширялись, можно было запутаться, когда разбираешь обращения: теперь не один, а пять сотрудников сумеют решить эту задачу. Менеджеру уже не всегда понятно, кто именно ее будет решать. Тем более, в одних вопросах компетенции сотрудников могут пересекаться, и они одинаково справятся с задачей, а в других вопросах — нет. Сотруднику тоже было сложно выбрать входящее обращение по своей специализации из очереди неразобранных — он не знал, какие задачи уже в работе. Мы разработали «Поиск исполнителя» и указали в системе компетенции сотрудников. Когда менеджер фиксирует новое обращение и указывает его тип, система начинает автоматический поиск людей, которые могут его решить. Теперь у каждого вида обращений есть своя очередь неразобранных задач, и сотрудник видит только те, в которых он компетентен. Бывают критичные обращения, к примеру, касса не работает, и не может работать весь магазин. Мы добавили интеграцию с телеграмом. Если критичное обращение никто не берет в работу уже дольше двух часов, потенциальным исполнителям начнут приходить уведомления в мессенджер. Сейчас мы собираем статистику, к примеру, сколько времени клиент ждал, когда с ним свяжутся. Так мы хотим на числах увидеть, как работают наши гипотезы по обработке заявок и где можно улучшить процесс. Сейчас, осенью 2021 года, у нас 1760 клиентов. Каждый день поступает 100-200 обращений — звонки, письма или сообщения в мессенджерах. Эти задачи разного уровня сложности: бывает, что просто нужно подсказать, где нужная кнопка. Или наоборот, требуется доработка, которую программист будет писать несколько дней. Все эти обращения принимают и разбирают 60 консультантов из разных подразделений. Розница, Управление торговлей, Бухгалтерия, Зарплата и кадры — всего 8 отделов. У сотрудников внутри одного отдела компетенции тоже могут отличаться. Кто-то из Бухгалтерии глубже разбирается в налоге на прибыль и НДС, а кто-то специалист по упрощенке. Рассказываем, как мы организовали прием обращений клиентов, чтобы вопрос быстрее попадал к нужному специалисту. Сначала мы работали в одной комнате. Менеджер поднимал трубку и спрашивал, кто возьмет задачу Нельзя придумать решение, которое всегда работает. Поэтому работу с обращениями мы меняли несколько раз, по мере роста компании. Когда все мы помещались в одном кабинете, быстрее всего было делать так: менеджер отвечал на звонок клиента, и потом всех спрашивал — кто возьмет? Тот, кто был свободен, отвечал — я возьму. Тогда это было удобно и без автоматизации. Клиентов становилось больше, и когда звонил телефон, все консультанты могли быть заняты. Они могли только пообещать — я возьму, но попозже. Уже нужно было сохранять информацию: кто звонил, с какой проблемой. Мы не теряли обращения, и сотрудник не ломал голову, вспоминая, что там нужно было сделать. Так появились обращения или тикеты — документы, в которых мы фиксируем клиента, суть вопроса, прикрепляем необходимые файлы. В нем же можно посмотреть переписку с клиентом, если в ней была дополнительная информация. Сотрудник освобождался, смотрел список неразобранных обращений и брал одно из них в работу. Появились сотрудники с разной специализацией, и мы разработали автоматический поиск исполнителя Сначала одна сотрудница досконально разобралась с зарплатными вопросами. С этого началась специализация, и появился зарплатный отдел. Теперь когда клиент звонил с вопросом, к примеру, про НДФЛ, мы направляли его к этой сотруднице. А к тикетам мы добавили вид обращений — помечали, к какой области относится вопрос клиента. Отделы добавлялись, расширялись, можно было запутаться, когда разбираешь обращения: теперь не один, а пять сотрудников сумеют решить эту задачу. Менеджеру уже не всегда понятно, кто именно ее будет решать. Тем более, в одних вопросах компетенции сотрудников могут пересекаться, и они одинаково справятся с задачей, а в других вопросах — нет. Сотруднику тоже было сложно выбрать входящее обращение по своей специализации из очереди неразобранных — он не знал, какие задачи уже в работе. Мы разработали «Поиск исполнителя» и указали в системе компетенции сотрудников. Когда менеджер фиксирует новое обращение и указывает его тип, система начинает автоматический поиск людей, которые могут его решить. Теперь у каждого вида обращений есть своя очередь неразобранных задач, и сотрудник видит только те, в которых он компетентен. Бывают критичные обращения, к примеру, касса не работает, и не может работать весь магазин. Мы добавили интеграцию с телеграмом. Если критичное обращение никто не берет в работу уже дольше двух часов, потенциальным исполнителям начнут приходить уведомления в мессенджер. Сейчас мы собираем статистику, к примеру, сколько времени клиент ждал, когда с ним свяжутся. Так мы хотим на числах увидеть, как работают наши гипотезы по обработке заявок и где можно улучшить процесс.

Смотреть

Как мы создали систему обращений, чтобы быстрее обрабатывать заявки клиентов