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

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

Управленческий учет - С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 - общая оценка в баллах, можно сказать, «выше среднего». Значит, процесс хорошо описан и стабильно работает.

 

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

 

к оглавлению

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

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

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

См. также

"Процессы 3.0: CRM, Бизнес-процессы, Управление по целям". Универсальная система управления процессами и показателями для любой конфигурации 1С Промо

Управление бизнес-процессами (BPM) v8 1cv8.cf УУ Платные (руб)

"Процессы 3.0" - это подсистема для любой конфигурации 1С. Она управляет бизнес-процессами, считает показатели, зарплату сотрудников, создает интерфейсы. "Процессы" состоят из конструкторов, с помощью которых можно создавать бизнес-процессы, скрипты продаж, системы стимулирования, мотивации и многое другое без программирования.

45000 руб.

15.08.2014    68156    26    124    

Новые возможности 1С: Документооборот – чат-бот

Инструкции пользователю Документооборот и делопроизводство v8 ДО Бесплатно (free)

В данной статье будет рассмотрено нововведение в конфигурации 1С:Документооборот, а именно – чат-бот по имени Ася. Будет представлена инструкция по особенностям и пользованию данным чат-ботом в 1С:ДО. Чат-бот доступен для версий 1С:Документооборот КОРП и ДГУ. Ася может отвечать на вопросы, открывать различную документацию и файлы и исполнять некоторые задания.

02.12.2021    701    Koder_Line    2    

Оплата недоработок. Сменный график работ. Настройка ЗУП 3.1

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

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

08.11.2021    320    NataVic    0    

Простое бронирование заказов на каждый день

Монитор заказов v8 1cv8.cf Бытовые услуги, сервис Россия Бесплатно (free)

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

02.11.2021    345    1Eset    4    

Как мы визуализировали отдел продаж - графические отчеты для 1С Промо

СRM Инструкции пользователю СRM v8 УНФ ERP2 УТ11 КА2 1С:CRM Россия УУ Бесплатно (free)

После выполнения очередного проекта по автоматизации отдела продаж на 1С (конфигурация 1C:CRM 8, ред. 2.0) мы вдруг поняли, что чего-то не хватает. Странно: вроде и бизнес-процессы внедрены, и цифры в отчетах бьются, и заказчик в целом доволен. Но, реальным финалом проекта должна была стать визуализация данных по отделу продаж и установка TV-панели в кабинете у менеджеров по продажам.

05.09.2017    43623    alexrovich_ru    56    

Как вносить изменения в новое ЭДО от 1С в БП 3? Июнь 2021, БП 3.0.93.20

Документооборот и делопроизводство Обмен через XML v8 v8::БУ БП3.0 БУ Бесплатно (free)

Обновились на 3.0.93.20, и все мои расширения под ЭДО перестали работать. Разберем, где вообще искать код, который выводит данные электронного документа в XML, где вмешиваться в ход этого вывода?

03.06.2021    6762    fixin    26    

Исправление вывода списка процессов в 1С:Документооборот с группировкой

Документооборот и делопроизводство v8 ДО Россия Бесплатно (free)

Начиная с версии 2.1.13.28 разработчики 1С:Документооборот изменили порядок отправки документа в обработку. Запуск процесса начинается с одной кнопки Отправить. Это здорово, так как не надо гадать, какой тип процесса настроен для документа, но список процессов неинтуитивный. Особенно, когда количество настроенных процессов более 1000. Все процессы выводятся в один список и сортируются по наименованию.

24.05.2021    1505    Xleo777    5    

Диадок, модуль 1С - заполнение полей с дополнительной информацией

Документооборот и делопроизводство v8 Россия Бесплатно (free)

Некоторые контрагенты для настройки электронного обмена документами требуют заполнения специальных полей  ИнфПолФХЖ1 и ИнфПолФХЖ2 дополнительной информацией.

21.05.2021    2926    _Vovik    9    

Права доступа в 1С:Документооборот 2.1 Промо

Информационная безопасность Документооборот и делопроизводство Документооборот и делопроизводство v8 ДО Бесплатно (free)

В программе 1С:Документооборот ред 2.1 механизм системы прав доступа сильно изменился. С одной стороны, права доступа в данной версии стали проще и быстрее, с другой стороны - права по рабочим группам объектов теперь могут противоречить политикам доступа. Разберемся в данной статье как работает механизм прав доступа в 1с документообороте 2.1.

16.09.2016    88857    vlush78    0    

Пример организации HTTP сервиса на 1С: Документооборот. Источник 1С: ЕРП => Приемник 1С: Документооборот

Интеграция с сервисами Документооборот и делопроизводство v8 ДО Бесплатно (free)

Статья - пример для разработчика, как можно, не используя подсистему Интеграция с Документооборотом, управлять процессами, а именно на нашем примере прерывать выполнение процессов в 1С: Документооборот. Используя данный пример, можно организовать http-сервис в любой конфигурации 1С, которая поддерживает механизм HTTP сервисов.

13.05.2021    2688    Flover    0    

Бонусная система. Разработка, внедрение

СRM Розничная торговля v8 УТ10 УУ Бесплатно (free)

Задача: необходимо запрограммировать механизм начисления бонусов не в день покупки товаров, а только по истечении 14 дней.

02.04.2021    1947    Rustig    19    

Иной подход к схемам комплексных процессов (возможность пользователям в удобном формате видеть участников процесса до его запуска) в 1С: Документооборот

Документооборот и делопроизводство v8 ДО УУ Бесплатно (free)

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

30.03.2021    2569    Capitullo    2    

Интеграция «1С:Управление производственным предприятием» с «1С:Документооборот» Промо

Перенос данных из 1C8 в 1C8 Документооборот и делопроизводство Документооборот и делопроизводство v8 КА1 УПП1 ДО Бесплатно (free)

В данной статье пойдет речь о возможности интеграции 1С:Управление производственным предприятием ред. 1.3 с 1С:Документооборот КОРП и о том, что может получить предприятие от этой интеграции.

18.02.2013    66152    Vladimir_Konyrev    38    

Перенос присоединенных файлов в документооборот при бесшовной интеграции

Документооборот и делопроизводство v8 ДО ERP2 Бесплатно (free)

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

26.02.2021    1536    ВикторП    21    

Доступность процессов и задач по предмету всем участникам рабочей группы документа

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

Простой способ сделать задачи и процессы доступными всем участникам рабочей группы документа. Для этого нужно добавить дополнительный обработчик бизнес-события, который будет срабатывать по виду события "Старт процесса". Актуально, если используете комплексные процессы, и не все участники видят задачи друг друга.

15.02.2021    709    Capitullo    4    

Новое в 1С:Документооборот 3.0

Документооборот и делопроизводство v8 ДО УУ Бесплатно (free)

Под новый год фирма 1С сделала нам всем подарок – вышла ознакомительная версия долгожданного 1С:Документооборот 3.0! По традиции новая версия кардинально отличается от предшественника как в плане интерфейса, так и по “начинке”. В данной статье рассмотрим самые интересные нововведения. Приступим к обзору.

11.02.2021    4990    Koder_Line    5    

Сложное ранжирование клиентов по классам Промо

СRM Оптовая торговля Розничная торговля Управленческие СRM Оптовая торговля Розничная торговля v8 УТ10 Россия УУ Бесплатно (free)

Пример реализации усложненной ABC-классификации клиентов. Данная статья написана для конфигурации "1С: Управление торговлей, ред. 10.3", но, я думаю, предложенный метод подойдет и для других конфигураций, имеющих механизм ABC-классификации.

28.03.2012    24139    charushkin    9    

CRM в облаках

СRM Облачные сервисы, хостинг v8 Бесплатно (free)

Организация единой CRM-системы для группы компаний требует особого подхода к построению интерфейсов, продуманной архитектуры обмена данными, оптимизации интеграционных форматов и т.д. О том, как построить CRM-систему, используя 1С только как back-end для получения данных по HTTP-протоколу, рассказал инженер-программист ООО «Протон» Сергей Плоткин.

29.01.2021    1365    Plotks2017    1    

Автоматизация логистики: кейс компании-поставщика зоотоваров

СRM Монитор заказов Оптовая торговля Управление услугами и сервисом Управление торговлей v8 Платформа 1C v8.2 1cv8.cf УУ Бесплатно (free)

Лояльность клиентов напрямую зависит от организации и качества бизнес-процессов компании. С каждым годом спрос на услугу доставки товара "до двери" возрастает. поэтому если курьеры опаздывают или вовсе переносят доставку на другой день компания рискует потерять клиента или пожертвовать своим имиджем. В статье представлен актуальный кейс об оптимизации процесса доставки с помощью модуля логиста на базе системы 1С.

10.12.2020    1696    RAU IT    5    

Настройка телефонии 1С:УНФ, Манго

Телефония, SIP СRM v8 УНФ УУ Бесплатно (free)

Настраиваем телефонию Манго в 1С:Управление нашей фирмой. Как это работает и с чем предстоит столкнуться.

25.11.2020    3333    ogre2007    22    

Диалог с клиентом. Правда vs ложь. Промо

Методология СRM СRM v7.7 v8 1cv8.cf 1cv7.md Россия Бесплатно (free)

Как оценить работу и стоит ли говорить всю правду клиенту? Где та золотая середина, которая поможет «настроить» крепкие деловые отношения исполнителя с заказчиком?

02.01.2012    26805    Yury1001    238    

Сказ о том, как в одной крупной компании документооборот внедряли, или проблемы типовых обменов между КА и ДО

Интеграция с сервисами Перенос данных из 1C8 в 1C8 Документооборот и делопроизводство v8 ДО КА2 Бесплатно (free)

Приветствую всех. Сегодня пойдет речь о том, как на одной крупной компании внедряли 1С:Документооборот 2.1 в связке с КА 2.4. Вроде бы системы типовые, мы практически не добавляли ничего в них, но проблем было столько, что я решил изложить их в статье. Может, кому-то пригодится это в дальнейшем, и не придется тратить кучу времени на поиск решений.

10.11.2020    7632    maks_20    30    

Запрет повторного запуска комплексных процессов типовыми средствами в 1С: Документооборот

Документооборот и делопроизводство v8 ДО Бесплатно (free)

Реализация решения изложенного в статье, исключает ошибочный (повторный) запуск комплексного процесса в 1С: Документооборот.

09.11.2020    2056    sulig    5    

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

Документооборот и делопроизводство v8 ДО БУ Бесплатно (free)

Доработка в 1С: Документооборот позволяет заблокировать повторный запуск комплексного процесса по шаблону для данного документа, если процесс по этому шаблону уже запущен.

02.11.2020    1378    vlad356987    15    

Лиды в УНФ

СRM v8 УНФ Россия УУ Бесплатно (free)

Обзор функционала работы с лидами в 1С:Управление нашей фирмой.

15.10.2020    2325    user1269837    3    

Договоры и соглашения в 1С:ERP

СRM v8 ERP2 УУ Бесплатно (free)

В наше время трудно представить организацию, которая вступает во взаимоотношения с контрагентами, не оформив договор. Договор – юридический документ, который является гарантом выполнения сторонами взаимных обязательств. В системе 1С:ERP реализован очень удобный механизм, который позволяет отобразить ключевую информацию по договору, прикрепить скан-копию документа.

01.10.2020    8017    Koder_Line    7    

Модуль логиста: как обычная доработка стала тиражным решением

СRM Монитор заказов Розничная торговля Управление услугами и сервисом v8::ОУ 1cv8.cf УУ Бесплатно (free)

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

18.08.2020    3318    RAU IT    2    

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

Документооборот и делопроизводство v8 ДО Бесплатно (free)

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

20.07.2020    2830    Maito    8    

Проблемы организаций при подготовке к внедрению документооборота

Документооборот и делопроизводство v8 Россия Бесплатно (free)

Что необходимо сделать для реализации проекта по внедрению «1С:Документооборота?»Как мы говорили в предыдущей статье необходимо осознать проблему, провести классификацию проблем, определить риски и обосновать необходимость внедрения документооборота.

18.06.2020    3291    Marta_Snytkina    4    

Состояния заказов клиентов

Оптовая торговля Монитор заказов v8::ОУ УТ11 Россия УУ Бесплатно (free)

Конфигурация «Управление торговлей, редакция 11 (11.4.11.104)». Регистр сведений «Состояния заказов клиентов». Описание и устройство.

27.05.2020    8108    totchaz    15    

Визуализация электронной подписи в заполняемом файле MS Word в 1С:Документооборот

Документооборот и делопроизводство v8 ДО Бесплатно (free)

Произвольное размещение визуализации электронной подписи в заполняемом документе MS Word в конфигурации 1С:Документооборот.

09.04.2020    6355    Xleo777    6    

[ERP] Планирование и выполнение ремонтов

Производство готовой продукции (работ, услуг) Управление услугами и сервисом v8 ERP2 УУ Бесплатно (free)

Решим собственные примеры и подзадачу из билета экзамена "1С:Специалист - консультант" по внедрению подсистем "Управление производством и организация ремонтов". Статья носит исключительно практический характер.

10.03.2020    12609    leobrn    4    

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

Документооборот и делопроизводство v8 ДО Бесплатно (free)

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

25.02.2020    7628    Koder_Line    4    

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

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

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

11.02.2020    29981    rusmil    9    

Детектор завершения согласования для 1С: Документооборот КОРП

Документооборот и делопроизводство Практика программирования v8::УФ ДО УУ Бесплатно (free)

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

04.02.2020    3953    shiaju    3    

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

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

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

28.01.2020    59135    Bene_Valete    220    

Новые возможности обработки Печать договоров по шаблонам для УТ 11, КА 2, ERP 2

Печатные формы документов Документооборот и делопроизводство v8 ERP2 УТ11 КА2 Бесплатно (free)

В публикации описаны возможности обработки, которые появились в новых релизах

19.12.2019    5926    pparshin    9    

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

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

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

14.12.2019    6131    pavelpribytkin96    2    

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

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

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

20.11.2019    7340    rmIvanT    24    

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

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

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

14.11.2019    4007    rmIvanT    0    

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

СRM Техническое задание v8 КА2 Россия УУ Бесплатно (free)

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

29.10.2019    6778    BraunAlex    1    

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

Документооборот и делопроизводство v8 ДО Бесплатно (free)

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

28.10.2019    12906    pavelpribytkin96    6    

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

Документооборот и делопроизводство v8 ДО Бесплатно (free)

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

28.10.2019    14146    pavelpribytkin96    14    

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

Документооборот и делопроизводство v8 ДО ERP2 УТ11 КА2 Бесплатно (free)

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

23.10.2019    5845    pavelpribytkin96    2    

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

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

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

22.09.2019    6069    pavelpribytkin96    2