И снова здравствуйте. Сегодня мы бы хотели обсудить не столько вопрос разработки технологий, о которых мы рассказывали в этой и вот этой статьях, сколько вопрос поддержки клиентов, которые эти технологии используют. На самом деле, это вовсе не праздный вопрос, а решение сложной проблемы, не менее трудной, чем обучение многослойной нейросети. Техподдержка - одна из головных болей стартапов и молодых компаний.  Ведь хочется, чтобы поддержка продукта была круглосуточной и круглогодичной, а клиенты были всем довольны. Когда планируешь, как все это будет работать, то нередко рисуешь себе идеальную картину с розовыми пони. К сожалению, в реальной жизни все немного иначе - розовые пони исчезают сразу, как начинается планирование службы поддержки со всеми деталями, включая стоимость оплаты услуг специалистов, планирование смен, ТК РФ. Сегодня хотим поделиться опытом. Мы не собирались строить все из ничего, сходу создавая сложную структуру саппорта. Начали с малого в апреле 2020 года. Тогда мы пригласили тимлида и попросили его найти коллегу-инженера. Вместе они занимались решением технических вопросов, которые нужно было решать партнерам и клиентам. Чуть подробнее о том какие вопросы решались - ниже, в подразделе “Диверсификация обязанностей”.  Ни о какой круглосуточной работе изначально не было и речи, это была стандартная пятидневка и график с 9:00 до 18:00. Первые пару месяцев они без проблем справлялись со своими обязанностями. Во многом благодаря тому, что мы не афишировали создание нового отдела. Не скрывали, но и не анонсировали - хотели проверить, как все работает. Но когда пользователи, партнеры и коллеги узнали, что появился отдел, который помогает разобраться в нюансах работы продукта, может решить сложные проблемы и задачи, то нагрузка этих двух героев фронта поддержки резко возросла. Стало ясно, что отдел поддержки нужно расширять, и мы пригласили еще пару специалистов. В течение еще 2-3 месяцев все шло относительно неплохо.  Через 2-3 месяца работы саппорта стало ясно, что клиентов и партнеров нужно поддерживать и по выходным. У бизнеса задачи не ограничиваются рабочей неделей, многие компании выполняют те либо иные задачи и тогда, когда все отдыхают.  В отделе технической поддержки на тот момент было уже 3 инженера и 1 тимлид. Задумались мы тогда и о круглосуточной поддержке, но эту идею пришлось отложить. Не потому, что организовать ее сложно, а потому, что это дорого.  Подсчитали, сколько еще людей нужно добрать, прокалькулировали связанные с расширением операционные расходы, посмотрели статистику звонков. Как оказалось, основной трафик идет по будням с 10:00 до 20:30, так что смысла оплачивать дополнительные 14 часов в день пока не было. Но вот субботу и воскресенье решили добавить. Решение нашли быстро: недельный дежурный с дополнительной оплатой по выходным.  Компания росла, расширялся и отдел поддержки. Не очень быстро - к октябрю 2020 года количество сотрудников в нем достигло 6 человек. Это 1 тимлид и 5 инженеров.  Клиенты и партнеры саппортом были вполне довольны. Но задач, конечно, стало больше, увеличилось и их разнообразие. С течением времени мы стали замечать, что отдел сам по себе разделился на две части, как раз по типам решаемых задач. Условно это было разделение на "Help Desk" и на "мониторинг". Работа стала эффективнее, и мы уже официально разделили отдел на два подразделения:  Help Desk - 2 человека Мониторинг - 3 человека Единственное - тимлида разделить не удалось, поскольку он был один и не хотел, чтобы его делили. Пришлось оставить его как есть, с условием, чтобы он координировал работу всего отдела.  Задачи Help Desk: Поддержка платформы и локализация ее проблем (ошибки API; кнопка работает не так, как должна; нет доступа и тд.). Поддержка сервисов платформы и локализация проблем с ними (робот не звонит, вместо "привет" распознает "вечер, море, хочу в отпуск", тарабанит фразы как… робот и становится не похож на человека). Поддержка SIP-телефонии (сетевые проблемы телефонии). Поддержка External API. Задачи мониторинга: Мониторинг сетевой инфраструктуры и своевременная реакция на возникающие проблемы (сервера, базы данных, сетевое оборудование). Мониторинг коммерческого трафика и своевременная реакция на возникающие проблемы (прослушивание некоторого кол-ва звонков, отслеживание ключевых показателей проектов). Спустя некоторое время оценили преимущества разделения:   Специалисты саппорта прекрасно знали свои обязанности и не мешали друг другу. Специализация в рамках своего подразделения помогла сотрудникам быстро замечать и лучше понимать те места, где требуются улучшения. Задачи выстроились в стройную систему. Выходные можно закрывать без дежурного. Последний пункт стоит немного пояснить. Дело в том, что на этом этапе мы отказались от дежурного в подразделении Help Desk. Вместо этого мы предложили подразделению мониторинга  7-часовой рабочий день по будням с тем, чтобы на выходные у сотрудников оставалось 10 дополнительных часов. Это решение обсуждалось вместе с сотрудниками, которые были не против. Схема простая: сначала один человек работает по 7 часов по будням и в выходные, потом второй, потом третий и так далее. Ну а затем - наша песня хороша, начинай сначала.  Выше уже упоминалось, что круглосуточную поддержку мы не вводили, поскольку подавляющее большинство клиентов и партнеров обращались с вопросами в обычное время - с 10:00 до 20:30. Почему так? Все просто - те, с кем мы работали ранее, находились в одном с нами часовом поясе.  Все изменилось после того, как Neuro.net стала выходить на зарубежный рынок. Сразу же появились обращения во “внеурочное время” и здесь пришлось взять быка за рога, т.е. все же ввести круглосуточный саппорт.   Сначала получалось так: Help Desk - c 9:00 до 18:00 по будням. Здесь пока что ничего не менялось.  Мониторинг - 3 смены: 9:00-18:00 (2 человека), 14:00-21:00 (1 человек), 1:00-9:00 (1 человек, добрали позже из другого часового пояса на ГПХ). Но чуть позже количество зарубежных клиентов значительно выросло, увеличился и трафик.  И мы ввели круглосуточную поддержку для двух подразделений - как мониторинга, так и хелп деска.  Изначально выбирали из трех перспективных вариантов реализации полноценного круглосуточного саппорта:   Три смены по 9 часов - утро, вечер, ночь. 2/2 по 12 часов Сутки через трое (Why not? как гипотеза подойдет) По деньгам все варианты более-менее были равны, поэтому стали выбирать, исходя из потребностей и внешних факторов. Основных пунктов было четыре: Желание сохранить команду (многим не нравится сменный график, и в этом нельзя никого винить) Необходимость сделать оплату смен достойной (текучка кадров никому не нужна) Необходимость рассчитать количество сотрудников, которых нужно пригласить дополнительно.  Поиск сотрудников.  Поразмыслив, мы решили оставить первый вариант - три смены по 9 часов. Почему так? Режим “сутки через трое” рассматривался просто как экзотичный вариант. Но работать 24 часа, а потом трое суток быть дома - на это соглашаются далеко не все, и это понятно. Суточные смены очень сложные.   Два дня по 12 часов через каждые 48 часов - вариант вроде бы неплохой. Но мы - молодая компания с развивающимися технологиями. И не хотелось, чтобы сотрудники выпадали на 48 часов каждые два дня, ведь новая информация и задачи у нас появляются буквально каждый день.   Что было сразу, до глобального перехода на круглосуточную работу? Help Desk - 4 инженера. Мониторинг - 3 инженера + 1 инженер ночью. Теперь решаем наши задачи: Сохраняем команду - оставляем у всех все так, как есть сейчас. Пусть продолжают работу по стандартному графику - 9:00-18:00 Рассчитываем минимальное количество людей на смене - тут все зависит от нагрузки и трафика в вечер и ночь. В нашем случае достаточно по 1 человеку на ночную смену для каждого подразделения: Итого нужно: Help Desk - 4 утро, 1 вечер, 1 ночь. Мониторинг - 3 утро, 1 вечер, 1 ночь. После решения этой задачи приступаем уже к реализации. Набрасываем график с 18-20 обязательными сменами (естественно, его можно варьировать), чтобы был запас на больничные/отпуска и ребята могли добрать смен вплоть до 25+. Где мы искали дополнительных сотрудников для вечерних и ночных смен? Да где и все, собственно - HH, Rabota, LinkedIn и др. Кстати, были даже попытки найти разработчиков на Tinder, но об этом уже в другой раз. В качестве завершения стоит сказать, что нас этот вариант устроил идеально - он оказался более чем работоспособным. Какие-то советы здесь давать сложно, ведь у каждой компании собственная ситуация. Зато можем устроить обмен опытом в комментариях - можете задавать дополнительные вопросы и рассказывать о своем опыте создания круглосуточной поддержки и формирования соответствующего отдела. Technical manager