Как настроить правильную техподдержку (helpdesk, service desk на коленке)

Публикация № 1052789

Управление - Управление взаимоотношениями с клиентами (СRM)

процесс автоматизация техподдержка техническая поддержка service desk helpdesk тикет клиент заявка

Эта статья будет полезна для компаний, которые оказывают техническую поддержку своим пользователям - внешним или внутренним клиентам. В статье я расскажу, как оказываем поддержку мы, как выстроили этот бизнес-процесс, что контролируем и на что обращаем внимание в работе. Вы можете использовать наш опыт при построении собственной системы поддержки или обратиться к нам за помощью за построением такой системы, будем рады помочь. В статье формируется основной набор правил, которые мы сформировали при настройке системы для себя, а так же небольшие примеры того, как мы эти правила применяем.

Оглавление

Экономический эффект поддержки

Что это и для чего нужно 

Основные правила хорошей поддержки

Заключение

 

Статья большая, добавляйте в закладки, чтобы не потерять. Будут вопросы - заказывайте презентацию

 

Экономический эффект поддержки

Начнем с того, что часто пропускается при рассмотрении будущего процесса поддержки - такое внедрение обычно стартует из разряда «как все достало, давайте внедрять». Рассмотрим эффекты для компании от поставки адекватного процесса «service desk» 

 

  1. Косвенный. Как и от любых внедрённых бизнес-процессов вы получаете положительный эффект «в долгую». 
    1. В виде высвобожденного времени специалистов, которое сейчас тратится на хаотическую обработку заявок. Если вы читаете эту статью, такие заявки у вас, скорее всего, есть :) Будет система со сроками, будет автоочередь задач - все негативные моменты ручной диспетчеризации, жалобы по поводу забытых заявок уйдут, ответственности станет больше
    2. В виде дополнительной расположенности клиентов к вам - продлять поддержку, совершать доп. продажи лояльному клиенту проще
    3. Снижается вес риска ухода специалиста - если поддержка перестаёт быть уникальным знанием, то новые сотрудники быстрее входят в работу и это принципе возможно без краха системы
    4. Оцифровка и объективность данных - система фиксирует сроки обработки, ответственных, количество запросов, себестоимость заявок и прочее. Арбитраж ситуаций с недовольным клиентом («мне ни разу не помогли!»), с перегрузкой специалистов работой («не успели, потому что у нас 1000 задач!») и т.д. решаются по данным, а не по эмоциям. Можно планово масштабировать сервисы при необходимости. 
    5. Снижение излишних затрат. Частый пример, вопрос выходит за рамки поддержки, но специалист все равно его делает - по факту лишние затраты времени на пост-согласование с клиентом стоимости и возможности оплаты вообще, вместо предварительного согласования.
    6. Качество продукта растет. Процесс предоставления поддержки - это практически бесконечный процесс улучшений. Сейчас вы создадите одну версию, через месяц поймете, что, например, запросы вида «А как месяц закрыть?» должны решаться в другие сроки и не в режиме аврала - запустите их по иному маршруту сервиса. Если под качеством понимать соответствие заявленным стандартам, то тенденция безусловно будет положительной.
  2. Прямой. Тут больше подходит для внешнего клиента, но и для для внутреннего иногда применимо
    1. Соответствие лимитам. Количество услуг поддержки должно оказываться согласно тем договоренностям, что вы выставили. Если клиент свой лимит исчерпал, то система должна на это реагировать - предложить продлить сервис, перенести вопрос на другой период (в зависимости от того, что вы в процессе предусмотрите). 
    2. Контроль стоимости обращения. Это относится к инцидентной системе управления, задача системы - уметь инциденты создавать. Например, «превышен лимит затрат в 10 часов специалиста на заявку» - такой инцидент получит руководитель по факту его происхождения, а не случайно найдет в отчете через месяц. 
    3. Своевременное пополнение бюджета. «Здоровая» компания должна получать стабильное финансирование с определенной частотой. То есть, не «менеджер решил проверить, у кого поддержка заканчивается и сделать всем счета», а «система заранее подготовила счета клиентам согласно их запросам и запустила процесс контроля оплаты».

 

Картинка из разряда «Как процесс поддержки представить на графике». Подробнее о показателях дальше по тексту

 

к оглавлению

 

Что это и для чего нужно 

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

  1. Это сервис - у него есть свой порядок предоставления, рамки и правила. (По каким каналам и вопросам можно получать ответы, в какие сроки будет ответ)
  2. Сервис оказывается персонально - конкретному человеку (пользователю среды) по его конкретному вопросу. Это не обучение пользованием продуктом, это не справочник с общим доступом. Да, такие функции тоже должны быть в системе. Да, ответом техподдержки может быть ссылка на статью, решающая вопрос пользователя. Но как нельзя поддержкой называть общедоступную документацию, так и нельзя общаться с эмоциями вроде «У меня тут отчет запрашивают какой-то… А времени нет!».
  3. Среда должна быть определена. Ваша поддержка может быть точкой входа как для вопросов по 1С, по Windows, по почтовику, так и по предоставлению 2-НДФЛ, запросов на отпуск и т.д. Вы сами определяете спектр вопросов, которые будете решать в рамках этого процесса. У нас, например, и задачи собираются, и консультации оказываются и документы запрашиваются через «одно окно». 

 

Можно ли жить без такого сервиса? Да, бесспорно. Будет ли при этом у ваших сотрудников и клиентов меньше вопросов? Нет, они просто будут действовать как умеют (или вовсе не действовать, а жаловаться на тяжелую долю). Будут слать письма по почте с копией на всех и вся, тратить время своего начальника, бегать по офису и «пытаться решить вопрос». Кстати, гораздо хуже узнать через несколько лет работы, что ваши юристы тратят на один договор «от двух дней», вместо того, чтобы делать его за 30 минут в настроенной программе - просто потому, что однажды «что-то сломалось, а куда с этим идти-то, мы не знаем…», чем уметь обрабатывать такие ситуации. 

 

Абсолютно все компании к определенному уровню зрелости приходят к тому, что нужен централизованный сервис обращений. Такой сервис может быть необходим как для внешних клиентов, так и для ваших внутренних пользователей - нет разницы, с чего начинать. К этому знанию приходят через несколько этапов:

• Приказы уровня «по 1С обращаться напрямую к Андрею и не дергать бухгалтерию!», «2-НДФЛ выдается каждый четверг в порядке очереди в кабинете 218»

• Попытки свести поддержку в почту: «Пишите на help1c@supercompany.ru по 1С», «Не пишите на help1c@supercompany.ru по вопросам резервов, ими заведует кладовщик!». Бонусом получаем письма [RE:117 Ошибка!!!], где ведется переписка по разным вопросам за несколько месяцев - и уже никто не помнит, что нужно в итоге, обращения стихийно возникают в процессе и умирают.

• Супер-идеи - «Сейчас мы в 1С быстро напилим Заявку, сделаем статусы и будет счастье». Это действительно работает, пока есть 2-3 запроса в неделю. С ростом различных сервисов, вы начинаете постепенно захлебываться в количестве различных статусов «В работе», «Ожидает», «Передан в бухгалтерию» и т.д. - их, оказывается, тоже надо поддерживать. Добавить новый сервис - та еще головная боль, как это все работает знал только Петрович, который уволился на прошлой неделе. Иногда вашему монстру «Заявке» надо одновременно быть в двух статусах, например, «Согласована» и «В очереди на следующий месяц» - о таком лучше вообще не думать.

• Мы все поняли. Давайте развернем нормальный helpdesk. «Но только чтобы с там и договора согласовывать можно было! А еще нужен календарь!» и подбор «идеальной системы» на пару лет, в которой есть все-все-все и еще немного

• …

 

Как и с любым бизнес-процессом тут нужно работать итерациями, внедрять мелкие части процесса в работу, но делать это часто. Например, наш процесс оказания поддержки проработан и автоматизирован на 136 попугаев и 57% - есть куда расти

Но это нисколько не мешает нам работать по этому процессу уже сейчас - система настроена и обеспечивает качественное выполнение.

 

Мы построили довольно хорошую системы поддержки наших клиентов внутри своего основного продукта «Процессы 3». Она ни разу не претендует на звание «единственно верная и покрывающая любой кейс система поддержки», у нас тоже есть недовольные клиенты (претензии, кстати, тоже пришлось научиться обрабатывать), но все-таки одно неоспоримое преимущество у нее есть: наша система на 99% кастомизируема. Она построена на бизнес-процессах с дополнительными фишками вроде работы через браузер, почту, telegram, всеми любимыми статусами, календарями, отчетами, настраиваемыми рабочими местами и т.д. Даже сейчас мы меняем наши процессы работы поддержки прямо по ходу пьесы и от этого никто не страдает. 

 

Переходим к тому, что обязательно должно быть в системе поддержки и как это должно использоваться (все, о чем пойдет речь дальше - настроено в системе, а не запрограммировано кодом). Мы осознанно не будем углубляться в методологию, ваши пользователи, скорее всего, даже мельком про ITIL и иже с ним не слышали. 

 

Основные правила хорошей поддержки

Я могу выделить 9 пунктов, которые стоит продумать для того, чтобы вашу поддержку можно было назвать жизнеспособной:

  • Правила работы. Как работаем
  • Доступность и точки входа. Где работаем
  • Интерфейс. В чем работаем
  • Сервисы. По каким направлениям работаем
  • Взаимодействия. Как общаемся в процессе работы
  • Гомеостаз. Как поддерживается рабочее состояние процесса
  • Регламент и бизнес-процессы. Чем руководствуемся при работе
  • Приоритеты. Как выстраиваем очередь задач
  • База знаний. Где и как храним информацию

 

Разберем каждый из этих пунктов с небольшими примерами

к оглавлению

Правила работы

Все начинается с некоторого соглашения, в рамках которого вы будете оказывать поддержку. Как правило, не нужно расписывать талмуд на 1000 страниц, что вы будете делать, чего не будете (его банально не прочитают). Но обязательно нужно осветить:

  1. Место оказания поддержки. Куда пользователю нужно идти, чтобы получить помощь. Например, «Единый портал технической поддержки доступен по адресу www… Регистрация на портале происходит … ». Обязательно назовите этот ресурс, чтобы избежать дальнейшую подмену понятий, например «… (далее [Портал])».
  2. Состав поддержки. На какие вопросы пользователь получит ответ, на какие - нет. Не нужно обнадеживать себя - все равно вопросы будут не только из этого списка, поэтому и нужна квалификация вопросов, которую рассмотрим дальше, но правила следует описать все равно. Например, «На портале вы получите ответы на вопросы по функциям и возможностям Продукта, сможете зарегистрировать нового контрагента и согласовать договор» или «Вы получите доступ к сервисам технической поддержки по 1С, согласования договоров, инициации процедуры проверки контрагента, согласно Приказу №…». Важно простыми словами описать что будет - лучше написать меньше, а в инструкциях первой линии техподдержки уже прописать детальную квалификацию - Ваша задача не отпугнуть пользователя, но и не дать ложных надежд, что поддержка все сделает за него. Важно, что если вы даете клиенту (внутреннему или внешнему) вариативность сервисов, то следует в соглашении прописать эту вариативность «Критическими являются вопросы, поставленные с пометкой СРОЧНО. Вопросы генерального директора всегда ставятся с пометкой СРОЧНО». 
  3. Предмет поддержки. То есть, "как действовать для получения помощи». Нужно договориться, что будет «центром» обсуждения и уметь его правильно наполнить. Обычно запрос оформляется в Тикет (в нем фиксируется тема, добавляются файлы и описывается проблема). Тут самая важная часть - для клиента на один вопрос один тикет, но с разными статусами. Статусы показывают, что сейчас происходит с тикетом. У вас же по этому тикету создаются задачи - много, разные и без статусов. Так достигается максимальная кастомизируемость обработки заявки пользователя. Разные типы обращения должны обрабатывать разные люди по разным маршрутам, но клиенту это не интересно - у него есть вопрос, который должен быть решен, детали не волнуют. Еще раз - клиент создает Тикет, в тикете статусами отображается, на каком мы этапе. По тикету создаются задачи на сотрудников поддержки, задачи не видны клиенту. Мы подробнее это разберем позже, пока зафиксируем так. Соответственно, для клиентов поддержки желательно описать, как именно ставить задачи, что означают статусы и как будут приходить уведомления об их смене. 
  4. Максимальные сроки реакции. Пользователь должен знать примерные сроки реакции на вопросы. Например, «Техническая поддержка предоставляется в размере до 3 вопросов в день от пользователя, гарантированный срок ответа - 3 рабочих дня. Срок поддержки может быть изменен в связи с загруженностью службы». Это не значит, что вы не будете принимать больше 3 вопросов в день, это не значит, что на запрос «все пропало» вы будете неторопливо кликать на крестик закрытия окна, т.к. «Еще не пришло время». Это сроки для клиента, а ваши специалисты должны работать минимум в 3 раза быстрее. Вы должны влезть в этот срок в случае полного провала, когда умерли последние бэкапы и уволились все сотрудники, проще говоря :) Важно, что если у вас с клиентами вариативность сервисов, то в соглашении следует прописать эту вариативность «Реакция на критический запрос - 1 час, реакция на вопрос генерального директора - 1 час, без учета выходных дней». 
  5. Исключения из правил. Здесь следует описать, что делать, если что-то пойдет не так. Например, если поддержка не отвечает, пользователя не устраивает оказанный сервис или ваш портал недоступен. Например, «При недоступности Портала … направляйте запрос по электронной почте … с пометкой Технической поддержке», «Если у вас возникли вопросы по качеству оказания сервиса, то оставьте ваш комментарий по электронной почте …». 

 

Например, у нас основные моменты прописаны в договоре (это место, сроки и состав в сжатом и упрощенном виде). Дополнительно есть «Соглашение по сервису», которое рассказывает пользователю больше информации об услуге. Даже если вы оказываете поддержку для внутреннего клиента, то все равно такое соглашение нужно - все должны понимать, что, в каком объеме и сроках вы производите. 

 

Ну а клиентам мы записали и отправили простое видео с общим обзором «их стороны работы», посмотреть можно тут

к оглавлению

 

Доступность и точки входа

Система поддержки должна быть доступна пользователям в «онлайне» в виде приложения со своим интерфейсом. Идеально, если это будет браузер, который открыт почти всегда. Неплохой вариант, если это будет сервис внутри 1С или другой системы. Гораздо хуже, если вы решите поддерживать пользователей исключительно через почту, по телефону или мессенджеры. Важно! Задать вопрос и получить на него ответ можно через мессенджеры, звонки и письма, но обрабатывать эти обращения вы должны именно системно. Поддержка других каналов, скорее, бонус системы. У нее нет обязательного требования «оказывать поддержку там, где пользователю удобно», напротив, продуктом поддержки будет «вовремя обеспеченный знанием о продукте пользователь». Всегда нужно сначала выстроить систему поддержки с одним, но понятным входом заявки, затем уже анонсировать, что точек входа несколько.

 

Наши «Процессы» загружены в УНФ и опубликованы в вебе (забегая вперед, такой сценарий возможен и в отдельной базе, и внутри старенькой УТ 10.3). У нас прием заявок идет 

• Через специальное настроенное рабочее место клиента. Об этом знают все наши пользователи

• Некоторые заявки мы принимаем через форму обратной связи на сайте и письма. Об этом знают некоторые

• Задачу можно поставить в telegram-боте. Об этом знают единицы (вот, кстати, пример того, как можно с telegram систему подружить)

 

Правило тут следующее: «Пользователь должен знать гарантированную точку входа для подачи запроса». «Пользователь должен знать единый ресурс просмотра своих заявок, поставленных из всех точек входа».

к оглавлению

 

Интерфейс 

Кто вообще работает в системе оказания технической поддержки? Тут по классике управления бизнес-процессами (если не знаете эту удобную классификацию, приходите к нам на бесплатные вебинары):

  • Инициатор тикета. То есть, сам пользователь 
  • Специалисты разных уравнений решения вопроса пользователя
  • Руководитель технической поддержки

 

У каждой из этих ролей должен быть свой интерфейс, у каждой роли свои потребности от системы. Минимальный состав элементов управления будет такой:

 

Инициатор тикета должен иметь возможность:

  • Создать тикет по нужному сервису
  • Посмотреть прошлые тикеты
  • Видеть оперативные оповещения от других пользователей системы (преимущественно, от специалистов)
  • Смотреть статьи базы знаний - правила и регламенты работы, важные новости

 

Рабочий стол клиента поддержки

 

Специалисты:

  • Видеть задачи по разным тикетам в порядке автоматического приоритета. Специалист не должен думать, что делать следующим шагом, всегда берем то, что имеет больший приоритет. В задаче специалиста уже содержится необходимая для решения тикета информация в зависимости от уровня поддержки - если это первый уровень, то это описание клиента, доступы к нему. Для второго уровня уже выводится оформленный комментарий от первого уровня поддержки.
  • Иметь доступ к статьям базы знаний и документации. Многие вопросы решаются просто ссылкой на документацию. Чтобы продолжать и дальше работать в этой удобной манере, документация должна быть пополняемой - это должно управляться прямо по выполнению процесса поддержки (ставиться задача на пополнение документации на первую линии поддержки).
  • Планировать работы по тикетам. Некоторые тикеты решаются в несколько приёмов и не за 5 минут. Работа по таким тикетам должна быть внесена в календарь для оценки занятости служб поддержки
  • Видеть личные показатели работы. «А насколько я в этом месяце исполняю план / закрыл задач / допустил ошибок?» - эта информация первое руководство к действиям ответственного сотрудника, которое должно быть перед глазами всегда
  • Видеть оперативные оповещения от других пользователей. Это обычная лента оповещений, как хроника в Facebook - уведомления в порядке их свежести

 

Оперативная страница специалиста-разработчика

 

Планирование задач специалиста-разработчика

 

Внешний вид задачи со встроенной справкой

 

Одна из рабочих страниц специалиста первой линии поддержки

 

Руководитель

  • Видеть происшествия, которые возникли по ходу процесса поддержки. Система должна мониторить важные вещи (потенциальные проблемы, как уже говорили выше) и оперативно создавать на руководителя задачу для ручного управления.
  • Видеть показатели процесса поддержки. Это может быть счетчики по важным областям, показатели работы сотрудников и т.д.

 

Оперативная информация

 

Динамика по количеству новых тикетов по дням

 

График затраченного времени поддержки по дням по клиентам

 

Контроль тикетов - доска из карточек «ожидают нас», «ожидаем мы»

 

Картина рабочего дня специалистов

 

Я прокомментирую некоторые обязательные, на мой взгляд, показатели, которые выводятся у нас на рабочем столе руководителя:

  • План / факт работ (день и неделя). Сколько запланировали и сколько успели из этого сделать
  • Просрочено задач в разработке. Сколько задач второй линии вышли из своего срока и по ним нужно разбираться с ходом работ
  • Количество ошибок за 14 дней. Баги, которые мы допустили в процессе разработки
  • Тикеты в работе. Общее количество тикетов, которое находится сейчас в работе для оценки общего уровня загруженности
  • Просроченные тикеты. Количество тикетов, процессы по которым просрочены. Должно быть 0
  • Время по клиентам. Сколько времени по поддержке потратили на тех или иных клиентов в день
  • Рабочий день сотрудников. Карта дня сотрудников, где видны отметки времени работы по задачам
  • Канбан-доска по активным тикетам в ключе «на чьей стороне мячик»
  • Динамика тикетов по дням возникновения. Чтобы отслеживать пики запросов

 

Показатели процесса - это как приборная доска, вы можете обращать внимание на что-то иное, главное, чтобы было на что обращать внимание :)

Правила: «Руководитель поддержки должен видеть оперативные показатели, должен реагировать на отклонения в процессе», «Каждый специалист должен иметь рабочее место, согласно исполняемым обязанностям». Правила вроде как простые, но одни из самых важных и самых игнорируемых. Функции системы, нужные конкретному исполнителю, должны быть в одном рабочем месте, а не раскиданы по кнопкам системы.

к оглавлению

 

Сервисы 

У клиента должен быть базовый выбор сервисов для подачи вопросов. Удобно через одну систему обрабатывать несколько разных кейсов. Например, если это вопрос к отделу бухгалтерии, то он пойдет по одному простому маршруту, если это запрос на изменение программы, то маршрут уже другой, более сложный, обвешенный согласованиями и утверждениями. Не нужно пользователя заставлять делать сложную классификацию (вроде «вопрос к старшему начальнику», «вопрос к самому главному из заместителей»). Нужно определить те сервисы, которые пользователь может получить и сделать понятным момент запроса этого сервиса.

 

У нас есть несколько вариантов сервисов в рабочем месте клиента:

1. Вопрос по функционалу. Это самый сложный процесс, выдаваемый наружу. Тут внутри и вопросы к первой линии поддержки по функционалу Процессов, и указания багов, и предложения по доработкам.

2. Запрос документов. Если нужно получить от нас какие-то сканы или оригиналы

3. Запрос ключа к базе данных. Это автоматический процесс, который сам генерирует регистрационный номер для активации новой версии процессов, сам смотрит лимит по выданным ключам.

 

Для запуска каждого сервиса пользователю нужно нажать на соответствующую кнопку - тогда система создаст и откроет для заполнения тикет. Пользователь его наполнит (может в несколько этапов это делать, пока статус не поменяет, тикет будет в «черновиках»), прикрепит вложения и запустит в работу. Система тикет подхватит и запустит его в обработку. О том, как система обеспечивает получение пользователем ответа, рассмотрим в разделе «Регламенты». 

 

Это старт обычного процесса поддержки - по вопросу клиента

 

А это - старт другого процесса по запросу ключа к информационной базе. У каждого процесса свой маршрут (этот вообще полностью автоматический без действий пользователя).

 

Для пользователя запуск процесса начинается нажатием соответствующей кнопки в своем рабочем столе. Дальше уже система сама формирует внешний вид тикета в зависимости от сервиса

 

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

 

Правила здесь: «При постановке вопроса у пользователя должна быть возможность воспользоваться разными сервисами с простой классификацией». «Вопросы в рамках разных сервисов должны обрабатываться по разным правилам», «Система должна обеспечивать соответствие действий специалистов и правил оказания выбранного сервиса».

к оглавлению

 

Взаимодействия

В ходе получения поддержки пользователю нужно всего три вещи:

1. Получать обратную связь по прохождению тикета

2. Знать дату следующего шага. Это не обязательно дата и время, до которого пользователь получит ответ (тут уже от ваших соглашений зависит). Клиент чувствует себя спокойно, если знает, что «с его вопросом до такого-то числа что-то случится».

3. Получить ответ на свой вопрос в указанный срок

 

С пользователем должно быть налажено взаимодействие в рамках его вопроса. Клиент должен знать, что если он сделает такой такой-то набор действий, то его запрос примут в обработку. О том, что его запрос увидели, он узнает так-то и так-то. У пользователя сразу же рождается в голове «мини-проверка» - если мне не ответили в такое-то время, то что-то не так и стоит проверить, а туда ли я написал. К тому же, у пользователя должна быть возможность общаться в рамках своей заявки с «живыми людьми» - в комментариях к тикету важно иногда что-то спросить или уточнить срок.

 

У нас общение идёт в рамках тикета. Пользователь после создания тикета отправляет его в «плавание» по определенному маршруту. Система создаёт нашим специалистам задачи, что-то транслирует обратно в тикет. Но часто у пользователя возникают вопросы по ходу, например «А может быть вот так надо?». Чтобы такой вопрос не ломал цепочку задач бизнес-процесса (технически, процесс уже может быть далеко у программистов на анализе), в таком случае ответственный сотрудник поддержки подключается в тикет и отвечает на этот вопрос либо о том, что для анализа требуется время, либо принимая ответ пользователя и завершая процесс. Все вопросы клиента попадают в общую ленту рабочего места стола специалиста поддержки и обрабатываются по мере поступления. Тут не вводится дополнительных сложных правил - клиенты бывают разговорчивые и наоборот молчаливые - максимальный срок ответа 1-2 часа в рабочем интервале, часто обрабатывается раньше. Пользователь получит ответ оповещение об ответе на почту (или в telegram) - сможет так же на это письмо в почте ответить и оно прилетит обратно в задачу в 1С. 

 

В процессе работы по обращению клиента система несколько раз будет назначать срок обработки. Сначала она выставит (с учетом выходных и расписания работы) первичный срок реакции на тикет, скинет его в комментарии на клиента. Затем, после квалификации вопроса этот срок уточнит. Дополнительно важные этапы прохождения из бизнес-процесса система будет также транслировать в тикет, чтобы пользователь знал, когда «обращение квалифицировано как Критическая ошибка», например. 

 

Так выглядит тикет для клиента

 

А вот так он смотрится «внутри системы». Специалисты же получают задачи по каждой стадии этого тикета.

 

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

 

То есть, у нас есть универсальный документ, один из его видов мы настроили в «тикет», вокруг него прописали процессы, выдающие специалистам задачи. Клиент видит только тикет (в нем идет переписка, устанавливаются статусы, скидываются оповещения), специалисты работают по задачам процесса. Тикет один, задач много - согласно маршруту процесса.

к оглавлению

 

Регламент и бизнес-процесс

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

  1. Система маршрутизирует прохождение тикета в зависимости от сервиса
  2. Специалисты получают уведомления о новых событиях и знают, как их обрабатывать

 

По поводу маршрутизации у нас работает так - когда пользователь создаёт тикет, система смотрит на его вид и запускает нужный бизнес процесс. Начнём с процесса выдачи ключа - это полная автоматика. Система сама принимает на вход ключ, проверяет, можно ли пользователю давать ключ, если все ок, то в комментарий к тикету отдаёт его и завершает процесс. Если что-то идёт нет так, то подключается ответственный сотрудник и разбирается с запросом вручную. 

 

Процесс из нескольких блоков - автоматически формирующий ключ для программы по запросу клиента

 

Процесс поддержки немного сложнее. Все начинается с того, что система проанализирует сроки и от лица нашего сотрудника оповестит в задаче, что ответ будет в такое-то время. Одновременно с этим для следущей задачи процесса ставится этот же срок. Убиваем двух зайцев - и пользователя оповестили, и срок в задаче поставили. За это время специалист должен подключиться к тикету и классифицировать вопрос. Всего для классификации есть четыре варианта:

  1. Вопрос по функционалу. Что-то спросили по программе - нужно в обычном режиме посмотреть документацию, ответить на вопрос
  2. Ошибка. Случилось что-то некритическое, например, в новом релизе допустили в коде баг, который не даёт создать группу побочного справочника 
  3. Критическая ошибка. Любая ошибка, которая делают работу невозможной: 1С перестаёт запускаться, шаблон процесса не создаётся, веб-клиент не открывается. 
  4. Предложение по доработке. Что-то из разряда «Было бы здорово, если бы вы добавили отображение всех комментариев в едином месте бизнес-процесса»

 

Классификацию нужно проводить потому, что она влияет на:

  • Сроки процесса
  • Схему обработки

 

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

 

Классификацию выполняет первая линия поддержки. Ее задача тут максимально выяснить, что клиент на самом деле хочет, постараться воспроизвести ситуацию и проверить на тестовой базе. Далее, если ответ классифицируется как вопрос по функционалу, то первая линия же и отвечает на вопрос, транслирует в комментарий тикета свой ответ. Пользователь получает ответ на почту (или в telegram), видит его в тикете и отписывается либо, что все ок, либо продолжает переписку. Первая линия поддержки по факту общения с пользователем либо завершает свою задачу ответа на вопрос с закрытием тикета, либо переводит его дальше с другой классификацией состояния. 

 

Схема работы первой линии поддержки довольно простая:

 

Обратите внимание, что в схеме есть ссылка на вложенные процессы. Почему бы не обработать все варианты в одной схеме? Это тоже вопрос идеологии, приходите на вебинары, будем вместе разбираться, почему так правильно. 

 

Для «ошибки» и «критической ошибки» формируется уже задача на разработчиков (следующая линия поддержки), система переносит в неё пояснения от первой линии, назначает задаче срок и приоритет. 

 

После выполнения задачи разработки нам нужно уведомить клиента, что ошибка устранена, функционал добавлен или запрос закрыт - первая линия поддержки получает задачу оповестить клиента о выполнении. Клиента оповестили, тикет закрыли, обратную связь получили - все довольны, все молодцы. 

 

Отдельно хочу обратить внимание на регламентацию для специалистов. Например, на первой линии поддержки нужно знать:

  • Банальные правила работы с клиентом в профессиональном стиле (что делать, чего не делать, вежливо обращаться, но не работать за клиента - помогать в настройке)
  • Как квалифицировать обращения, по каким правилам
  • Какую информацию нужно у клиента уточнить для воспроизведения ситуации

 

Разработчики должны знать:

  • Правила приоритетов задач (критические решаются быстро и без разбора «кто виноват»)
  • Что такое «решить задачу» - некоторые думают, что его задача просто диагностировать ошибку и описать, когда она появляется

 

Правила тут следующие: «Пользователь поддержки должен получать решение своего вопроса в объёме и сроке, зависящем от дополнительной квалификации вопроса», «Специалисты всех линий оказания сервиса должны знать, что им делать и в какой срок»

 

Вся эта работа описывается несколькими регламентами - правилами работы специалистов, которые зафиксированы в системе, в дополнение система сама по этим регламентам выдает задачи. Для обычной поддержки клиентов по нашему основному продукту есть регламент «Поддержка» (инициатива идет от пользователя). По проектным работам, где важна другая оперативность работ, используется регламент «Оперативная поддержка» (инициаторы запросов - система автотестирования или пользователи). Мы сейчас рассматриваем общий случай с обычной поддержкой, если интересен второй - пишите.

к оглавлению

 

Гомеостаз

 Когда вы делаете шаг, то не задумываетесь, как действовать, чтобы не упасть. Ваше тело умеет выполнять такие базовые вещи на автомате. С процессами так не получается - чтобы обеспечить их «жизнедеятельность» нужно немного постараться. Например, специалист написал ответ на тикет клиента, а клиент молчит. Тикет умирает постепенно, потому как с «нашей стороны» все ок - а увидел ли клиент сообщение, понял ли его и т.д., это уже не ясно. Поэтому, мы должны приложить максимум усилий, чтобы все-таки выполнить основной продукт поддержки - «клиент вовремя обеспечен достоверной информацией о продукте». Для этого система должна создавать задачи обзора тикетов на техподдержку, в ходе которой нужно пройтись по всем вопросам и «попинать» либо вторую линию, либо клиента, либо закрыть тикет. Управляется это простым регламентом «Ежедневный обзор тикетов».

 

 

В то же время, не все действия обязательно выполнять сотрудникам. Например, если тикет висит давно, в нем нет ответов от клиента после нескольких наших сообщений, то такой тикет должен закрываться автоматом системой. У нас так работает для тикетов, связи по которым нет больше 3 дней. 

 

Правила: «Для корректного выполнения процесс поддержки должен быть снабжен «процессом-компаньоном», в котором сотрудники должны актуализировать состояние тикетов».

к оглавлению

 

Приоритеты

Как уже писали выше, сотрудник не должен думать, что и в какую очередь делать. Система приоритеты должна назначать сама. Это простое правило помогает сделать так, чтобы тикеты исполнялись не в зависимости от эмоций, а в порядке, настроенном шаблонами. Здесь сколько важен не сам приоритет, а то, что он в принципе существует и назначается в зависимости от каких-то данных. Например, у нас задачи первой линии исполняются в порядке возникновения, они, как правило, простые. А вот задачи второй линии уже лежат в рамках приоритизации в зависимости того, что внесено в задачу:

 

 

Правило: «Необходимо выработать ручные или автоматические правила приоритезации задач и тикетов заранее»

 

 

База знаний

Тут все просто - она должна быть :) Причем, должна быть прямо в службе поддержки. Мы в базе знаний храним описания релизов, описания правил работы, описания порядка разработки - ту информацию, которая в зависимости от ситуации нужна либо клиенту, либо специалисту. Важно, чтобы для клиента и для специалиста база данных имела бы разный состав. Для специалистов в базе должны находиться свои правила и внутренние регламенты, для клиентов - соглашения, описание и порядок работы «с их стороны».

 

Обязательные статьи базы:

  • Порядок работы с технической поддержкой. Для клиента
  • Порядок работы с клиентом по технической поддержке. Для наших специалистов
  • Описание-документация по частым вопросам или вашему продукту. Для клиентов (этот вид должен быть автоматически пополняем, но это уже другая история)

 

Правила: «База знаний должна быть», «База знаний должна содержать актуальную информацию по оказываемым сервисам и работе в них».

к оглавлению

 

Заключение

Словом, описание нашего процесса поддержки на текущий момент в цифрах можно представить так:

136 - общая оценка в баллах, можно сказать, «выше среднего». Значит, процесс хорошо описан и стабильно работает.

 

Это все - неполное описание процесса нашей поддержки. Есть еще куча тонкостей и моментов, которые в эту статью просто не влезли. Мы прошли довольно долгий путь по оформлению этого сервиса и набили кучу шишек). Если хотите так же и в вашей компании (а еще из без набивания шишек) - заказывайте презентацию, поможем!

 

к оглавлению

«Простые процессы»

Специальные предложения

Автор запретил комментарии

См. также

Отправка "Заявления на подключение к ЭДО ПФР" из программы "1С: Бухгалтерия предприятия, ред. 2" для СЗВ-ТД

Статья Бухгалтер Нет файла v8 v8::БУ БП2.0 Россия БУ ФОМС, ПФ, ФСС Бесплатно (free) Документооборот и делопроизводство Зарплата Управление персоналом (HRM)

Инструкция по отправке "Заявления на подключение к ЭДО ПФР" из программы "1С Бухгалтерия предприятия, ред. 2" для обмена сведениями об электронных трудовых книжках и отправки отчетов по форме СЗВ-ТД.

11.02.2020    9398    rusmil    8       

1C:Предприятие для программистов: Запросы и отчеты. Второй поток. Онлайн-интенсив с 17 марта по 16 апреля 2020 г. Промо

Данный онлайн-курс предусматривает углубленное изучение языка запросов и возможностей системы компоновки данных, которые понадобятся при разработке отчетов, работающих на платформе “1С:Предприятие” в рамках различных прикладных решений. Курс предназначен для тех, кто уже имеет определенные навыки конфигурирования и программирования в системе “1С:Предприятие”, а также для опытных пользователей различных прикладных решений, которые используют в своей работе отчеты разного назначения.

6500 рублей

Электронные трудовые книжки, СЗВ-ТД в ЗУП 3.1 - сборник ответов на вопросы и полезные ссылки

Статья Бухгалтер Нет файла v8 v8::СПР ЗУП3.x Россия БУ Бесплатно (free) Документооборот и делопроизводство Зарплата

С 1 января 2020 г. начался переход на электронные трудовые книжки. До середины февраля 2020 г. все работодатели должны сдать первый отчет по форме СЗВ-ТД. Не смотря на то, что срок сдачи уже достаточно близок, информация по данному направлению постоянно изменяется и уточняется. Я постаралась собрать ключевые моменты, касающиеся перехода на электронный формат ведения трудовых книжек сотрудников в программе ЗУП 3.1, которые возникли при изучении этого нововведения. Данный сборник будет полезен как бухгалтеру/кадровику, так и 1С программисту или консультанту, сопровождающему переход. Весь предложенный материал можно найти самостоятельно, моей целью было собрать разные источники воедино дабы облегчить работу моим коллегам. В связи с тем, что информация может корректироваться и уточняться, необходимо проверять ее актуальность, поэтому в каждом найденном ответе указан источник для проверки. Внимание - данный сборник является справочным, работодатель должен руководствоваться исключительно Законодательством об электронных трудовых книжках. В сборник первоначально вошли только те вопросы, с которыми я столкнулась в своей работе лично, поэтому критика и предложения по дополнению приветствуются!

28.01.2020    25349    Bene_Valete    192       

Программы для исполнения 488-ФЗ: Маркировка товаров Промо

1 января 2019 года вступил в силу ФЗ от 25.12.2018 № 488-ФЗ о единой информационной системе маркировки товаров с использованием контрольных (идентификационных) знаков, который позволяет проследить движение товара от производителя до конечного потребителя. Инфостарт предлагает подборку программ, связанных с применением 488-ФЗ и маркировкой товаров.

Добавление собственного виджета в 1С:Документооборот

Статья Программист Нет файла v8 ДО Бесплатно (free) Практика программирования Документооборот и делопроизводство

В данной публикации я хочу описать процесс добавления собственного виджета для функционала отсутствий в 1С документооборот.

14.12.2019    2147    pavelpribytkin96    1       

Базовый курс по управлению ИТ-проектами. Курс проходит с 26 февраля по 22 апреля 2020 года. Промо

Отличительная черта курса - органичное сочетание трех вещей: 1.Теория проектного управления (PMI®+Agile Alliance+Российские ГОСТ+Методологии от 1С); 2. Опыт внедрения продуктов 1С (опыт франчайзи и успешных компаний + тренды Infostart Event и Agile Days); 3. Разбор реальных проблем и рекомендации экспертов по проектам слушателей. Мы будем фиксироваться на тех инструментах, которые реально оказываются полезными в практике руководителей проектов внедрения. Ведущая курса - Мария Темчина.

от 11000 рублей

Вывод полной истории в задаче по всему "дереву" бизнес-процессов

Статья Программист Нет файла v8::Бизнес-процессы ДО Россия УУ Бесплатно (free) Документооборот и делопроизводство Практика программирования

Вашему вниманию предлагается моя версия текста общего модуля "ОбзорЗадачВызовСервераПереопределяемый" для конфигурации 1С:Документооборот.

20.11.2019    2361    rmIvanT    9       

1С:Документооборот. Уведомление параллельных исполнителей. Дополнительный обработчик Бизнес-события

Статья Программист Нет файла v8::Бизнес-процессы ДО Россия Бесплатно (free) Документооборот и делопроизводство Практика программирования

Вашему вниманию предлагается пользовательский обработчик бизнес-события по созданию уведомлений параллельных исполнителей. Для бизнес-процесса "Исполнение".

14.11.2019    1528    rmIvanT    0       

Программы для исполнения 54-ФЗ Промо

С 01.02.2017 контрольно-кассовая техника должна отправлять электронные версии чеков оператору фискальных данных - правила установлены в 54-ФЗ ст.2 п.2. Инфостарт предлагает подборку программ, связанных с применением 54-ФЗ, ККТ и электронных чеков.

Модернизация КА 2.4 под маркетинговую компанию. Часть 1

Статья no Нет файла v8 КА2 Россия УУ Бесплатно (free) Управление взаимоотношениями с клиентами (СRM) Техническое задание

Выполнил для компании, которая занимается маркетингом и продвижением продуктов, проектирование и модификацию конфигурации КА 2.4 и справочника «Проекты». Теперь в конфигурации «Проекты» имеют особенную роль и на основании выполненной доработки руководство компании принимает решения по продолжению, закрытию или продвижению проекта/ов, поиск путей решения возникающих вопросов. При необходимости доработку можно реализовать под ERP конфигурацию. Архитектура решения выполнена «рядом» с основной конфигурацией. В настоящее время конфигурация поддерживается, модификация ведется в актуальной версии КА 2.4.10 на платформе 8.3.14.1630.

29.10.2019    2588    BraunAlex    1       

Использование справочника "Условия маршрутизации" для бизнес-событий в 1С Документооборот.

Статья Системный администратор Программист Нет файла v8 ДО Бесплатно (free) Документооборот и делопроизводство

Часто возникает ситуация, когда нужно написать обработчик бизнес-события, в алгоритмах которого необходимо, например, использовать данные внутреннего документа (значения доп. реквизитов, обычных реквизитов и т.д.). В данной публикации я хочу поделиться своим решением данной задачи через условия маршрутизации.

28.10.2019    4096    pavelpribytkin96    1       

Новый раздел на Инфостарте - Electronic Software Distribution Промо

Инфостарт напоминает: на нашем сайте можно купить не только ПО, связанное с 1С. В нашем арсенале – ESD-лицензии на ПО от ведущих вендоров: Microsoft, Kaspersky, ESET, Dr.Web, Аскон и другие.

  • Низкие цены, без скрытых платежей и наценок
  • Оперативная отгрузка
  • Возможность оплаты с личного счета (кешбек, обмен стартмани на рубли и т.п.)
  • Покупки идут в накопления для получения скидочных карт лояльности Silver (5%) и Gold (10%)

Автоматический запуск бизнес-процессов по входящим письмам с электронной почты в 1С Документооборот.

Статья Системный администратор Программист Пользователь Нет файла v8 ДО Бесплатно (free) Документооборот и делопроизводство

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

28.10.2019    5153    pavelpribytkin96    5       

Отображение схемы комплексного процесса в карточке процесса через бесшовную интеграцию с ДО.

Статья Программист Нет файла v8 ДО ERP2 УТ11 КА2 Бесплатно (free) Практика программирования Документооборот и делопроизводство

В данной публикации я хочу описать доработку, с помощью которой можно вывести схему комплексного процесса через бесшовную интеграцию с ДО в форме комплексного процесса.

23.10.2019    2522    pavelpribytkin96    2       

Управление ИТ-проектами. Модуль 2: продвинутый онлайн-курс по классическим методам управления проектами. Вебинары проходят с 12 марта по 11 июня 2020 года. Промо

Продвинутый онлайн-курс по классическому управлению ИТ-проектами позволит слушателям освоить инструменты из PMBoK® и 1С:Технологии корпоративного внедрения и научиться их применять для проектов любого масштаба. Курс включает в себя 12 вебинаров и 12 видеолекции, разбор кейсов и рекомендации экспертов по проектам слушателей. Ведущая курса - Мария Темчина.

от 13000 рублей

Работа с автозаполнением шаблонов файлов в документообороте

Статья Программист Нет файла v8 ДО Бесплатно (free) Практика программирования Документооборот и делопроизводство

При автозаполнении шаблонов файлов средствами MS Word возникает такая проблема - если одно и то же поле используется несколько раз в документе, тогда приходится дублировать закладки, например, если поле "Ответственный" используется 2 раза приходится создавать 2 закладки (Ответственный", "Ответственный2") и дублировать правила заполнения для этих полей. В данной статье я хочу рассказать каким образом можно создавать только 1 закладку и использовать данные из этой закладки в других местах документа.

22.09.2019    2627    pavelpribytkin96    2       

Как внедрить 1С:Документооборот в условиях хаоса

Статья no Нет файла v8 ДО УУ Документооборот и делопроизводство Бесплатно (free) Управление проектом

Не всегда проекты можно внедрить по заранее спланированному алгоритму. Скорее, даже никогда проекты не удается выполнить по универсальному плану: в каждой конкретной ситуации есть свои сложности и свои проблемы. Опытом внедрения 1C:Документооборот в отсутствии описанных процессов и утвержденной структуры предприятия на конференции поделилась руководитель отдела автоматизации торговой сети РЕМИ Марина Лимонтова (г. Владивосток).

21.08.2019    8929    limm28    11       

Базовый курс по обмену данными в системе 1С:Предприятие. Онлайн-интенсив с 12 по 28 мая 2020 г. Промо

Данный онлайн-курс предусматривает изучение механизмов платформы “1С:Предприятие”, обеспечивающих обмен данными между различными прикладными 1С-решениями и взаимодействие с другими информационными системами. Курс предназначен для тех, кто уже имеет определенные навыки конфигурирования и программирования в системе “1С:Предприятие”.

5500 рублей

CRM PROF 1.4. Практика доработки

Статья Программист Пользователь Нет файла v8 1С:CRM УУ Управление взаимоотношениями с клиентами (СRM) Бесплатно (free) Практика программирования

Статья описывает реальный опыт внедрения и доработки CRM PROF 1.4, а также показывает, какие были пожелания у заказчика и как они были реализованы. Статья предназначена для программистов 1С и пользователей CRM ПРОФ которые хотели бы расширить функционал программы.

08.04.2019    3240    script    0       

Готовые переносы данных из различных конфигураций 1C Промо

Рекомендуем готовые решения для переноса данных из различных конфигураций 1C. C техподдержкой от разработчиков и гарантией от Инфостарт.

Механизм бизнес-событий на конкретном примере

Статья Программист Нет файла v8::Бизнес-процессы ДО Россия УУ Документооборот и делопроизводство Бесплатно (free) Управление бизнес-процессами (BPM)

Есть в системе 1С:Документооборот механизм бизнес-событий. Когда мне понадобилось решить конкретную задачу, гугление ни к чему конкретному не привело. Хотелось так «вжух» и всё понять про данный механизм, но в итоге пришлось лезть в код 1С и смотреть реализацию данного механизма. В данной публикации поделюсь результатами исследований, может, кому-то это поможет быстро и легко во всём разобраться.

18.02.2019    7586    soulner    0       

Подборка решений для взаимодействия со ФГИС «Меркурий» Промо

С 1 июля 2019 года все компании, участвующие в обороте товаров животного происхождения, должны перейти на электронную ветеринарную сертификацию (ЭВС) через ФГИС «Меркурий». Инфостарт предлагает подборку программ, связанных с этим изменением.

Вдохнем вторую жизнь во встроенный почтовый клиент из 1С:Управление торговлей 10.3

Статья Программист Нет файла v8 УТ10 УУ Управление взаимоотношениями с клиентами (СRM) Бесплатно (free) Email

Хотели было воспользоваться почтовым клиентом из Управление торговлей 10.3, да не тут-то было. К сожалению, фирма "1С" почти совсем ее забросила и если Ваш респондент отправляет Вам письма, содержащие HTML, то Вас ждут матюки... Ну что же, как говорится: "Спасение утопающих - дело рук самих утопающих".

25.12.2018    6150    1c.pro.fun    8       

Воронка продаж в 1С: Управление торговлей v. 11. Рабочий вариант

Статья Пользователь Руководитель проекта Нет файла v8 v8::ОУ УТ11 УУ Управление взаимоотношениями с клиентами (СRM) Оптовая торговля Бесплатно (free) Бухгалтерский учет

Мы предлагаем рассмотреть альтернативную методику построения воронки продаж с использованием штатных средств 1С: УТ v.11. Этот подход опирается на типовые документы и механизмы, но, вместе с тем, на наш взгляд, дает руководителю более качественный инструмент управления при меньшем объеме трудозатрат на поддержание актуальной информации.

05.10.2018    6198    ЕленаЧерепнева    2       

Онлайн-курс "Подготовка к экзамену 1С:Эксперт и 1С:Профессионал по технологическим вопросам" с 7 по 24 апреля 2020 г. Промо

На курсе вы получите практические навыки решения задач производительности 1С, в том числе характерных для высоконагруженных информационных систем (более 1000 пользователей). Подготовка к экзамену – только одна из составляющих курса. 70% слушателей приходят за знаниями, которые позволят расти и зарабатывать, делать сложные задачи на крупных проектах.

16450 рублей

Создание web-площадки на технологиях 1С, или как Водоканал сделал "Личный кабинет потребителя"

Статья Программист Нет файла v8 Энергетика и ЖКХ УУ Управление взаимоотношениями с клиентами (СRM) Дебиторская и кредиторская задолженность Бесплатно (free) WEB

Гончаров Максим делится опытом создания «Личного кабинета потребителя» на сайте водоканала. Он описывает архитектуру системы и объясняет, какую роль в ней играют технологии: «Битрикс», OData, веб-сервисы, «1С:БСП». Также в статье раскрываются возможности использования подсистемы «Анкетирование» в «1С:БСП» как конструктора документов.

25.06.2018    13516    maxx    31       

Голосование за доклады на INFOSTART MEETUP Kazan - до 25 февраля. Промо

Выбирайте и голосуйте за самые интересные доклады! Лучшие из лучших попадут в окончательную программу казанского митапа. Оставить свой голос можно до 25 февраля 2020 года.

Интеграция Zimbra и 1С

Статья Программист Нет файла v8 Россия УУ Управление взаимоотношениями с клиентами (СRM) Бесплатно (free) Внешние источники данных

В публикации описывается способ интеграции 1С с почтовым сервером Zimbra, используя SOAP сервис. Рассматривать вопрос интеграции будем на примере бизнес задачи, из блока CRM. Реализации общей адресной книги(GAL-Global Address List) между сотрудниками. Сотрудники(компания) ведет весь учет в 1С, в том числе и элементы CRM, а Zimbra выступает лишь в роли почтового сервиса. Сделать данную публикация побудило отсутствие в интернете готовых примеров совместной работы 1С и Zimbra. Надеюсь, она поможет кому-либо сократить время на реализацию похожей задачи.

16.04.2018    9379    Гексагон    17       

INFOSTART MEETUP Kazan. 13 марта 2020 г. Промо

Инфостарт продолжает путешествие по России. Следующая остановка - Казань. Тема мероприятия - управление и технологии автоматизации учета на платформе "1С: Предприятие". Ждем всех: докладчиков и участников! Стоимость участия - 5 500 рублей. Цена действительна до 30.01.2020

5 500

Настройка Рарус: СофтФон с SIP телефонией на примере оператора Телфин

Статья Системный администратор Программист Нет файла v8 1С:CRM Windows Управление взаимоотношениями с клиентами (СRM) Бесплатно (free) Телефония, SIP

Описание настройки Рарус СофтФон для работы с SIP телефонией на примере конфигурации Управление торговлей и взаимоотношениями с клиентами (CRM), редакция 2.0.

26.02.2018    12707    de0nis    0       

Автоматизация для "полевых" сотрудников (тех, кто не работает в офисе)

Статья Программист Руководитель проекта Нет файла v8 1cv8.cf 1С:Франчайзи, автоматизация бизнеса УУ Учет рабочего времени Бесплатно (free) Управление бизнес-процессами (BPM)

Статья о том, как подходить к автоматизации процессов, где должны действовать сотрудники «в поле» - торговые представители, сервис-инженеры и т.д. На что стоит обратить внимание для таких видов бизнес-процессов

24.01.2018    13336    siddy    0