Смотреть
В этом разделе рассказываем про себя — но не просто, кто мы такие. А про себя как своего собственного клиента. Сейчас поясним.
Конечно, мы не только помогаем автоматизировать бизнес другим компаниям, но и организовали все свои процессы. И продолжаем тестировать гипотезы и переорганизовывать еще лучше. Иначе бы ничего не получилось и с внешними задачами, для других.
Осенью 2021 года нам исполнилось десять лет, и в честь юбилея подготовили большой рассказ о том, как у нас всё устроено, чтобы мы работали быстрее и ничего не упускали.
На видео о процессах внутренней автоматизации рассказывает руководитель компании Андрей Ефимов. А ниже — цикл статей.
Подробные кейсы нашей автоматизации
В статьях подробно описали, как создавали систему обращений, интегрировали таск-менеджер, и создали бота в Телеграме. Предлагаем читать в таком порядке, но вообще-то, начать можно с любого кейса.
- Как мы создали систему обращений, чтобы быстрее обрабатывать заявки клиентов
- Как мы собираем звонки и сообщения в одну учетную систему
- Кто должен отвечать на звонки клиентов
- Как мы интегрировали Асану с внутренней учетной системой
- Как мы находим исполнителя с помощью бота в телеграме
- Как мы похоронили Ironman’а
- Почему мы не называем стоимость всего проекта сразу
Если что-то подобное вам захочется настроить у себя — напишите или позвоните нам. Подробнее поделимся опытом и, конечно, поможем :)
А в этом видео рассказываем, как 1С:Коннект помогает нам принимать более 15 000 заявок в год и все их вовремя обрабатывать.
Наша автоматизация
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С работает, а доработки не ломаются.
Всего на полдня, но всё же — 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С. Столкнуться с этой ошибкой было практически невозможно, но мы справились:) Теперь тщательнее следим за тем, какого формата фотографии добавляем.
В Простых решениях около 100 сотрудников. Зарплатный и кадровый учёт ведут наши консультанты по зарплате. То есть они работают и с клиентами, и с коллегами.
Мы внедрили сервис 1С-Кабинет сотрудника именно для того, чтобы упростить решение кадровых вопросов внутри компании и облегчить работу консультантов по зарплате.
4 самые частые задачи, которые решали наши консультанты по зарплате
Справки для сотрудников: от 4 до 10 штук в месяц.
Обращались за ними кому как удобно: лично, по телефону, по почте, в мессенджерах. Работа с каждым сотрудником занимала 10–20 минут. С ростом числа сотрудников обработка таких обращений стала отнимать много рабочего времени.
Вопросы по информации в расчётных листках, которые было сложно обсуждать здесь и сейчас. Поэтому приходилось тратить время и восстанавливать цепочку обсуждения.
Согласование отпусков.
Приходилось прилагать дополнительные усилия, чтобы, с одной стороны, сохранить для сотрудников их гибкость планирования, а с другой — избежать неравномерной загруженности отделов.
Работа с удалёнными сотрудниками.
С ними нужно было подписывать различные кадровые документы удалённо.
Как изменилась работа после внедрения сервиса 1С-Кабинет сотрудника
Вопросы по остаткам отпусков решаются самостоятельно сотрудником без участия расчётного отдела.
Сотрудник в личном кабинете видит актуальный остаток отпуска на текущий день или на заданную дату. Теперь для этого не нужно ходить в расчётный отдел. Соответственно, сотрудники расчётного отдела больше не тратят на это своё время.
Общение с сотрудниками происходит прямо в сервисе 1С-Кабинет сотрудника.
Если возникает вопрос по расчётным листкам, то обсуждение ведётся в рамках специализированного канала — теперь не нужно искать, где и когда задали вопрос по зарплате, всё в одном месте.
Вопросы с сотрудниками-удалёнщиками решаются без распечатки кадровых приказов, а с использованием сервиса КЭДО, который законодательно разрешён для подписания кадровых документов.
Сотрудник бесплатно получает Усиленную неквалифицированную электронную подпись (УНЭП) в 1С:Кабинет сотрудника, которая потом хранится в этом же сервисе. И подписывает приказы прямо в сервисе кабинета.
Освобождается время консультанта-расчётчика, так как раньше надо было распечатать и отправить по почте приказы на подпись. К тому же такой подход экономит деньги, ведь не нужно оплачивать почтовые отправления.
Настроили согласование отпуска по отделам.
Исключили возможность ухода в отпуск сотрудника без согласования с руководителем.
Наталья — сотрудник, который собирается в отпуск. Юлия — её руководитель, которая увидит заявление Натальи и согласует его.
Вячеслав — руководитель отдела, в столбике слева список сотрудников, которые согласовывают свой отпуск с ним.
Сотрудник формирует заявление на отсутствие прямо из кабинета сотрудника, его согласовывает непосредственный руководитель, бухгалтер-расчётчик видит его в программе.
Консультанту-расчётчику не надо быть постоянно в программе и следить за запросами. Если появилось какое-то новое заявление, то приходит оповещение на почту.
Результаты внедрения 1С-Кабинет сотрудника
Сотрудники не тратят своё время на походы в расчётный отдел.
Всю информацию по отпускам и расчётным листкам сотрудник видит в приложении на смартфоне.
Продуктивность расчётного отдела повысилась, так как они не отвлекаются на визиты сотрудников и поиск нужной информации. Все обсуждения по кадровым и зарплатным вопросам в одном месте.
В Простых решениях около 100 сотрудников. Зарплатный и кадровый учёт ведут наши консультанты по зарплате. То есть они работают и с клиентами, и с коллегами.
Мы внедрили сервис 1С-Кабинет сотрудника именно для того, чтобы упростить решение кадровых вопросов внутри компании и облегчить работу консультантов по зарплате.
4 самые частые задачи, которые решали наши консультанты по зарплате
Справки для сотрудников: от 4 до 10 штук в месяц.
Обращались за ними кому как удобно: лично, по телефону, по почте, в мессенджерах. Работа с каждым сотрудником занимала 10–20 минут. С ростом числа сотрудников обработка таких обращений стала отнимать много рабочего времени.
Вопросы по информации в расчётных листках, которые было сложно обсуждать здесь и сейчас. Поэтому приходилось тратить время и восстанавливать цепочку обсуждения.
Согласование отпусков.
Приходилось прилагать дополнительные усилия, чтобы, с одной стороны, сохранить для сотрудников их гибкость планирования, а с другой — избежать неравномерной загруженности отделов.
Работа с удалёнными сотрудниками.
С ними нужно было подписывать различные кадровые документы удалённо.
Как изменилась работа после внедрения сервиса 1С-Кабинет сотрудника
Вопросы по остаткам отпусков решаются самостоятельно сотрудником без участия расчётного отдела.
Сотрудник в личном кабинете видит актуальный остаток отпуска на текущий день или на заданную дату. Теперь для этого не нужно ходить в расчётный отдел. Соответственно, сотрудники расчётного отдела больше не тратят на это своё время.
Общение с сотрудниками происходит прямо в сервисе 1С-Кабинет сотрудника.
Если возникает вопрос по расчётным листкам, то обсуждение ведётся в рамках специализированного канала — теперь не нужно искать, где и когда задали вопрос по зарплате, всё в одном месте.
Вопросы с сотрудниками-удалёнщиками решаются без распечатки кадровых приказов, а с использованием сервиса КЭДО, который законодательно разрешён для подписания кадровых документов.
Сотрудник бесплатно получает Усиленную неквалифицированную электронную подпись (УНЭП) в 1С:Кабинет сотрудника, которая потом хранится в этом же сервисе. И подписывает приказы прямо в сервисе кабинета.
Освобождается время консультанта-расчётчика, так как раньше надо было распечатать и отправить по почте приказы на подпись. К тому же такой подход экономит деньги, ведь не нужно оплачивать почтовые отправления.
Настроили согласование отпуска по отделам.
Исключили возможность ухода в отпуск сотрудника без согласования с руководителем.
Наталья — сотрудник, который собирается в отпуск. Юлия — её руководитель, которая увидит заявление Натальи и согласует его.
Вячеслав — руководитель отдела, в столбике слева список сотрудников, которые согласовывают свой отпуск с ним.
Сотрудник формирует заявление на отсутствие прямо из кабинета сотрудника, его согласовывает непосредственный руководитель, бухгалтер-расчётчик видит его в программе.
Консультанту-расчётчику не надо быть постоянно в программе и следить за запросами. Если появилось какое-то новое заявление, то приходит оповещение на почту.
Результаты внедрения 1С-Кабинет сотрудника
Сотрудники не тратят своё время на походы в расчётный отдел.
Всю информацию по отпускам и расчётным листкам сотрудник видит в приложении на смартфоне.
Продуктивность расчётного отдела повысилась, так как они не отвлекаются на визиты сотрудников и поиск нужной информации. Все обсуждения по кадровым и зарплатным вопросам в одном месте.
Начиная работать с ЭДО, может возникнуть необходимость перестроить процессы, которые были в организации при обмене бумажным документами.
При переходе на ЭДО нужно определить, кто будет:
настраивать ЭДО и решать технические вопросы связанные с ним
принимать и подписывать входящие документы
делать сверку взаиморасчетов
отправлять документы покупателям
организовывать хранение документов
Если компания небольшая и небольшой оборот документов, эти функции может выполнять один сотрудник. Мы распределили задачи по ЭДО между несколькими сотрудниками.
В этой статье рассказываем, как организовали работу с ЭДО в Простых решениях.
Подключение ЭДО
Чтобы подключить ЭДО, нужно знать много технических нюансов, поэтому данному процессу мы обучили наш отдел Сервис-инженеров.
Они помогают клиентам с подключением, смотрят ошибки ЭДО. Также они настраивали подключение для нашей компании.
Сейчас сервис-инженеры помогают нашим сотрудникам, ответственным за ЭДО, разбираться с ошибками и проблемами в приеме и отправке документов.
Входящие документы
Приемка
Прием документов у нас осуществляется в ручном режиме — принимать документы может любой менеджер.
Но данный процесс можно автоматизировать, настроив по расписанию загрузку документов в базу, чтобы не держать в голове постоянно задачу о необходимости принять документы. В этом случае ЭЦП и программы для работы с ними должны быть установлены на Сервере 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 отделов. У сотрудников внутри одного отдела компетенции тоже могут отличаться. Кто-то из Бухгалтерии глубже разбирается в налоге на прибыль и НДС, а кто-то специалист по упрощенке.
Рассказываем, как мы организовали прием обращений клиентов, чтобы вопрос быстрее попадал к нужному специалисту.
Сначала мы работали в одной комнате.
Менеджер поднимал трубку и спрашивал,
кто возьмет задачу
Нельзя придумать решение, которое всегда работает. Поэтому работу с обращениями мы меняли несколько раз, по мере роста компании.
Когда все мы помещались в одном кабинете, быстрее всего было делать так: менеджер отвечал на звонок клиента, и потом всех спрашивал — кто возьмет? Тот, кто был свободен, отвечал — я возьму. Тогда это было удобно и без автоматизации.
Клиентов становилось больше, и когда звонил телефон, все консультанты могли быть заняты. Они могли только пообещать — я возьму, но попозже. Уже нужно было сохранять информацию: кто звонил, с какой проблемой. Мы не теряли обращения, и сотрудник не ломал голову, вспоминая, что там нужно было сделать.
Так появились обращения или тикеты — документы, в которых мы фиксируем клиента, суть вопроса, прикрепляем необходимые файлы. В нем же можно посмотреть переписку с клиентом, если в ней была дополнительная информация. Сотрудник освобождался, смотрел список неразобранных обращений и брал одно из них в работу.
Появились сотрудники с разной специализацией,
и мы разработали автоматический
поиск исполнителя
Сначала одна сотрудница досконально разобралась с зарплатными вопросами. С этого началась специализация, и появился зарплатный отдел.
Теперь когда клиент звонил с вопросом, к примеру, про НДФЛ, мы направляли его к этой сотруднице. А к тикетам мы добавили вид обращений — помечали, к какой области относится вопрос клиента.
Отделы добавлялись, расширялись, можно было запутаться, когда разбираешь обращения: теперь не один, а пять сотрудников сумеют решить эту задачу. Менеджеру уже не всегда понятно, кто именно ее будет решать. Тем более, в одних вопросах компетенции сотрудников могут пересекаться, и они одинаково справятся с задачей, а в других вопросах — нет.
Сотруднику тоже было сложно выбрать входящее обращение по своей специализации из очереди неразобранных — он не знал, какие задачи уже в работе.
Мы разработали «Поиск исполнителя» и указали в системе компетенции сотрудников. Когда менеджер фиксирует новое обращение и указывает его тип, система начинает автоматический поиск людей, которые могут его решить.
Теперь у каждого вида обращений есть своя очередь неразобранных задач, и сотрудник видит только те, в которых он компетентен.
Бывают критичные обращения, к примеру, касса не работает, и не может работать весь магазин. Мы добавили интеграцию с телеграмом. Если критичное обращение никто не берет в работу уже дольше двух часов, потенциальным исполнителям начнут приходить уведомления в мессенджер.
Сейчас мы собираем статистику, к примеру, сколько времени клиент ждал, когда с ним свяжутся. Так мы хотим на числах увидеть, как работают наши гипотезы по обработке заявок и где можно улучшить процесс.
