Что определяет sla битрикс ответ
Перейти к содержимому

Что определяет sla битрикс ответ

  • автор:

Создание уровня техподдержки

Настройка уровней сервиса выполняется на странице Уровни техподдержки (SLA) ( Сервисы > Техподдержка > Уровни поддержки ):

SLA

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

Примечание: Доступные группы определяются в настройках модуля Техподдержка ( Настройки > Настройки продукта > Настройки модулей > Техподдержка ), закладка Доступ.

  • доступные категории и уровни критичности обращений, а также оценки ответов на обращение. Например, пользователям с обычным SLA может быть предоставлено право на создание обращений с низкой критичностью, а клиентам с SLA «Партнеры» – с низкой, средней и высокой.
  • другие параметры.
  • Документация по теме:
    • Уровни поддержки
    • Создание и редактирование уровня поддержки

    Что определяет SLA?

    Скидка 25% на лицензии при заказе разработки сайта у нас

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

    Ваша заявка успешно отправлена!

    Наш менеджер свяжется с Вами в ближайшее время. Спасибо за интерес к услугам BUSSOL

    Полный регламент техподдержки

    Сайт школы

    В рамках технической поддержки решаются вопросы, определённые данным регламентом, согласно установленным уровням обслуживания (SLA — Service Level Agreement).

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

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

    1.4. Компания «Симай» не оказывает услуги в области разработки сайтов на платформах отличных от «1С-Битрикс: Управление сайтом».

    2. Уровни обслуживания (SLA)

    2.1. Все обращения классифицируются на различные уровни обслуживания (SLA– Service Level Agreement). Уровни обслуживания отличаются временем реакции на обращение (и другими параметрами) и зависят от категории клиента и/или категории проблемы.

    2.2. Режим работы службы технической поддержки

    По рабочим дням с 8 до 17 часов московского времени.
    Кроме выходных и праздничных дней (по календарю праздничных дней России и Республики Башкортостан).

    Обращения в службу технической поддержки обрабатываются в порядке их поступления. Максимальный срок реакции на обращение определяется установленным уровнем поддержки (SLA). Вне очереди могут обрабатываться обращения с высоким уровнем критичности, требующие экстренного вмешательства или консультации специалистов технической поддержки. К таким обращениям могут быть отнесены вопросы восстановления работоспособности Интернет-проектов, или отдельных сервисов данных проектов.

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

    2.3. При этом вопросы, которые не могут быть решены с использованием существующего функционала продукта, передаются для решения в отдел разработки компании «Симай».

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

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

    2.5. Служба технической поддержки предоставляет следующие уровни обслуживания (SLA):

    Для клиентов компании «Симай» предоставляются следующие уровни поддержки:

    2.5.1. Платное сопровождение: оперативная поддержка

    • Решаются вопросы экстренного характера: если в результате сбоя (но не по вине самого клиента) становится полностью невозможной работа с публичной или административной частью сайта.
    • Если обнаружена критическая ошибка в работе проекта (и подтверждена сотрудниками техподдержки) — оказывается консультация по восстановлению нормальной работы сайта. Сюда относятся ошибки, которые нельзя обойти (например, использованием другого браузера или элемента интерфейса).

    Максимальное время реакции на обращение – 3 рабочих часа.

    2.5.2. Платное сопровождение: стандартная поддержка

    • Рассматриваются проблемы, возникшие при работе проекта;
    • Вопросы связанные с добавлением информации;
    • Общие вопросы консультационного характера

    Максимальное время реакции на обращение – 5 рабочих часов.

    2.5.7. Гарантийное сопровождение

    Уровень поддержки устанавливается для пользователей которые заказали разработку сайта в компании «Симай».

    • Решаются вопросы по устранению ошибок программирования и верстки допущенные компанией «Симай» (но не по вине самого клиента).

    Максимальное время реакции на обращение – 24 рабочих часа (до трех календарных дней, не считая выходные).

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

    2.5.8. Консультирование по общим вопросам

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

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

    Максимальное время реакции на обращение – 40 рабочих часов (до пяти календарных дней, не считая выходные).

    2.5.9. Разработка

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

    Максимальное время реакции на обращение – 24 рабочих дня.

    2.6. Таблица: уровни поддержки (SLA)

    Уровень поддержки Гарантийная Платная
    Режим работы с 8 до 17 по московскому времени. В субботу, воскресенье и официальные праздничные дни РФ и РБ техподдержка не работает.
    Максимальное время реакции * 24 рабочих часа 5 рабочих часа
    Срок действия поддержки В течении года Согласно договору
    Поддержка по телефону (ICQ, Skype и т.д.) нет
    Исправление ошибок в программировании, верстки в течении гарантийного срока да
    Привлечение разработчиков к проблеме нет да
    Разработка нового функционала нет да

    3. Круг решаемых задач

    3.1. Вопросы установки и настройки

    • Оказываются консультации по установке продукта на сервере (демо-версия, коммерческая версия). Консультации оказываются в объеме руководства по установке.
    • Даются рекомендации по типовым проблемам возникающим при установке.
    • Оказываются общие консультации по выбору серверного ПО. Список рекомендаций также приводится в соответствующих разделах документации по продукту.
    • При размещение проекта на хостинге, переносе проекта с локального сервера на удаленный оказываются общие консультации по использованию средств для подготовки резервной копии проекта и использованию стандартных (встроенных) скриптов и механизмов.
    • Не производится установка программного продукта на сервере.
    • Не производится подготовка и перенос архивных копий системы на сервер.
    • Не производится диагностика серверного ПО на компьютере или сервере клиента.
    • Не производится установка серверного ПО на сервере или компьютере клиента.

    3.2. Вопросы улучшения производительности

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

    3.3. Вопросы обновления программного продукта

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

    3.4. Ошибки программного продукта

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

    3.5. Вопросы разработки

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

    3.6. Теоретические вопросы работы с системой

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

    4. Порядок подачи и обработки обращений в службу технической поддержки

    • с использованием формы «Задать вопрос» на сайте (предпочтительный способ);
    • с использованием отправки сообщения электронной почты на адрес support@simai.ru.
    • Описание проблемы и пошаговое описание действий по воспроизведению проблемы (по возможности).
    • Вопрос желательно задавать используя терминологию, принятую в продукте «1C-Битрикс: Управление сайтом».
    • Адрес сайта, на котором наблюдается проблема.
    • Номер используемой версии программного продукта и редакция.
    • Дополнительно, службой технической поддержки может быть запрошена информация по настройкам серверного ПО, используемым версиям и настройкам клиентского ПО (браузера).

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

    4.5. При получении обращения в службе технической поддержки, пользователь получает уведомление о начале ее обработки и указанному обращению присваивается уникальный идентификатор (TID). Идентификатор необходимо сохранять в заголовке письма во время последующей переписки со службой технической поддержки по данному вопросу. На основании TID письма автоматически добавляются к исходному обращению. Полное содержание переписки может быть просмотрено на сайте в интерфейсе технической поддержки.

    4.6. Техническая поддержка НЕ оказывается по другим каналам (например, телефон, ICQ, форум, GoogleTalk, Skype). Вопросы, заданные по этим каналам не являются официальными обращениями и не регистрируются в системе техподдержки. Подобные средства связи рассматриваются только как средства общения и общих консультаций.

    4.7. При создании обращения или при отправке обращения по электронной почте можно включать скриншоты и графические пояснения, которые могут помочь в решении проблемы. Скриншоты должны быть подготовлены в форматах: JPG, GIF, PNG. В случае использования скриншотов в форматах BMP следует их предварительно запаковать с использованием программы архиватора (RAR, ZIP).

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

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

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

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

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

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

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

    SLA: Что такое соглашение об уровне сервиса и зачем оно нужно?

    SLA: Что такое соглашение об уровне сервиса и зачем оно нужно?

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

    Определимся с понятиями

    SLA расшифровывается как Service Level Agreement, дословно Соглашение об уровне сервиса. Термин SLA пришел из сферы IT, но теперь применяется далеко за ее пределами.

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

    Роль Service Level Agreement для бизнеса

    Если компания при выполнении процессов обслуживания клиентов опускается ниже установленных показателей, значит, она плохо работает. Таким образом, SLA − это универсальный инструмент оценки уровня сервиса любого бизнеса как в B2C, так и в B2B. Правда, применяется далеко не повсеместно. Почему?

    1. Во-первых, в России пока еще не очень развита культура сервисного обслуживания.
    2. Во-вторых, мало кто глубоко погружается в этот вопрос, и в итоге большинство работает без регламентированных правил.

    На самом деле Service Level Agreement дает значимое конкурентное преимущество тому, кто его заключает.

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

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

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

    Структура классического SLA описана в ITIL, при этом она довольно универсальна и может быть применима в абсолютно любом бизнесе. Какие разделы включает Соглашение об уровне сервиса?

    Что описывается в договоре?

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

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

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

    Время оказания услуг
    Далее компания сама для себя устанавливает время оказания услуг и доводит это до сведения клиентов, чтобы не оказалось, что человек будет названивать в техподдержку среди ночи, тогда как она начинает работать только в 9 утра.

    Кстати, в случае с услугами важно четко обозначить, что в них входит, а что нет. К примеру, в сфере ИТ в договоре указывается, сколько рабочих мест пользователей и какая конкретно техника обслуживается. А если сотрудник принесет свой личный ноутбук, то он не входит в договор. Не должно возникать недосказанности и разночтений. Это позволит избежать взаимных претензий.

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

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

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

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

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

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

    Назовем этот параметр временем возврата заявки. Он тоже должен содержаться в SLA вместе с описанием условий, при которых заявка может откладываться и возвращаться в работу, и количеством раз такой отсрочки. Исполнитель не несет ответственности в случае, если заказчик сам не выполнил свою часть обязательств. В некотором смысле этот параметр защищает права исполнителя.

    Условия оплаты
    Еще в SLA должны быть зафиксированы условия оплаты за предоставляемый сервис − не только стоимость услуг, но и момент ее списания (предоплата или постоплата) и правила возврата при отмене заказа. Скажем, вы бронируете номер в отеле. Цена проживания тут же списывается с вашей карты. Потом вы отменили поездку. Если оповестите отель заранее, он вернет все деньги. А если, скажем, менее чем за сутки до въезда − за вычетом некой удержанной суммы. Эта процедура тоже регулируется SLA.

    Правила разрешения споров
    Также в Соглашении об уровне сервиса должны быть сформулированы правила разрешения конфликтных и спорных ситуаций. Что делать, если вам привезли ботинки не того цвета, такси не доставило вас вовремя или пицца опоздала к ужину. А может быть, вам обещали восстановить доступ в интернет и сообщили о решении проблемы, а интернета как не было, так и нет. Все эти моменты надо предусмотреть.

    Чек-лист по составлению Соглашения об уровне сервиса

    Итак, грамотное SLA включает как минимум семь ключевых параметров:

    • Список и состав предоставляемых услуг
    • Время и география – когда и где обслуживаем клиентов
    • Время реакции на заявку – наш первый ответ клиенту
    • Время решения заявки – когда клиент получит результат
    • Время возврата отложенной заявки
    • Порядок оплаты услуг клиентом
    • Правила решения спорных ситуаций

    Если компания не устанавливает значения этих параметров, значит, у нее нет стандартов обслуживания клиентов.

    К примеру, в компании Информатика и Сервис SLA состоит из универсальной части и индивидуальной (в которой могут содержаться не все услуги, а только некоторые из них) и является приложением к договору с каждым конкретным клиентом. В нем расписаны все наши услуги, стоимость и порядок их оказания. Это универсальная формула для всех видов бизнеса. Берите и пользуйтесь.

    Автоматизация процессов обслуживания клиентов

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

    Каждый шаг сервисного процесса должен быть интегрирован и автоматизирован в системе Service Desk. Как это выглядит?

    1. Все начинается с подачи заявки клиентом – это может быть электронная форма на сайте, письмо или звонок. Новая заявка немедленно регистрируется в журнале учета заявок Service Desk. Кстати, в самом простом виде ею может выступать даже обычный Excel, если все заявки собираются там. Под Service Desk может пониматься любая программа, в которой тем или иным способом регистрируются, обрабатываются и анализируются клиентские запросы. После этого система должна помогать выполнять процесс обслуживания клиентов в соответствии с параметрами, которые закреплены в SLA. Для начала − сообщить клиенту, что его заявка получена и будет обработана за конкретное время ответственным исполнителем. Желательно, чтобы исполнитель тоже назначался в автоматическом режиме с учетом профиля его деятельности, компетенций, загруженности и пр. Обычно все заявки клиентов попадают в единую очередь, доступ к которой имеют клиентские менеджеры, которые вручную разбирают запросы, реагируют на них и распределяют по ответственным за решение сотрудникам. Сам порядок этих действий и параметры процесса должны быть закреплены во внутреннем SLA компании. И если, к примеру, менеджер взял в обработку заявку, но вовремя не сообщил об этом клиенту, система должна напомнить ему об этом. В идеале, повторим, Service Desk сама должна автоматически реагировать на заявку, назначать компетентного исполнителя и сообщать ему, что он должен решить запрос клиента к определенной дате.
    2. Далее начинается этап решения заявки, то есть задачи клиента. Идеальная система автоматизации обслуживания клиентов должна содержать в себе базу знаний по решению различных запросов. Тогда ответственный специалист может к ней обратиться и ускорить весь процесс. Допустим, вы подбираете тур в Африку. У хорошей турфирмы сразу есть база всех отелей с ценами и вариантами размещения. Менеджеру не надо тратить время на поиск этой информации, она вся под руками. Подробнее о базе знаний можете почитать здесь.
    3. Следующий эволюционный этап автоматизации сервисного обслуживания − это когда «искусственный интеллект» внутри системы Service Desk, получая запрос от клиента, научится его правильным образом читать, сопоставлять с данными из базы знаний и тут же отправлять в автоматическом режиме ответ клиенту. Это то, к чему должны стремиться все сервисные системы − работать автономно, без менеджеров и исполнителей. Конечно, это подходит для решения типовых задач. Более сложные еще долго будут требовать участия компетентных специалистов. На этапе работы над заявкой клиента система автоматизации обязательно должна сообщать исполнителю об оставшемся времени до истечения срока решения заявки. Ведь если он не успеет вовремя, это будет нарушением SLA. И если в договоре с клиентом зафиксированы штрафные санкции за такое нарушение, то компания-исполнитель может понести убытки за низкое качество обслуживания клиентов, что справедливо. Service Desk должна фиксировать такие нарушения по каждой заявки, а руководители должны получать отчеты и сводную информацию о качестве услуг в соответствии с принятыми стандартами обслуживания и закрепленными в SLA.

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

    Например, любое мобильное приложение службы такси по окончании поездки предлагает вам оценить водителя и уровень сервиса. Если вы поставите низкую оценку, то приложение поинтересуется причинами. Любая система Service Desk тоже должна предоставлять такую возможность клиенту. Ну и, в идеале, система автоматизации должна быть интегрирована с сервисами оплаты или, по крайней мере, напоминать о формировании счетов или учитывать внесенный пользователем аванс.

    Решение для автоматизации процессов обслуживания

    9 октября 2017 года компания Информатика и Сервис выпустила новое приложение для Битрикс24 − оно называется Admin24 — Service Desk и помогает бизнес-пользователям Битрикс24 существенно улучшить качество обслуживания клиентов.

    В Битрикс24 есть модуль задач (более подробно о нем можно прочитать здесь), который позволяет создать задачу, назначить исполнителя, указать крайний срок выполнения и пр. Но все это делается в ручном режиме. Когда компания обслуживает большое количество клиентов, важно, чтобы их заявки регистрировались в системе автоматически, чтобы так же автоматически назначались исполнители в соответствии с каталогом услуг и чтобы система следила за исполнением параметров SLA. В штатных возможностях Битрикс24 этого нет. Но благодаря новому приложению Admin24 такой функционал стал доступен.

    В нашем приложении можно сформировать простейший каталог услуг. За каждой из них закрепить одного или нескольких ответственных исполнителей. Также в первых версиях приложения Admin24 можно указать три важнейших параметра SLA − время реакции на заявку клиента, время ее выполнения и срок автовозврата заявки (для случаев, когда она по тем или иным причинам была отложена исполнителем). При этом, для расчета всех параметров может применяться только то время, которое вы укажете как рабочее в настройках самого Битрикс24.

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

    Admin24 — Service Desk автоматически создает веб-форму заявки, в которой клиент может выбрать услугу, оставить свои контакты и поставить галочку, что соглашается на передачу и обработку своих персональных данных.

    Передайте ссылку на веб-форму Admin24 вашим клиентам любым удобным способом − по электронной почте или ссылкой на сайте компании

    Далее заявка клиента попадает в виде задачи в специально созданную в Битрикс24 группу Admin24 — Service Desk и автоматически назначается тем ответственным исполнителям, которые были определены на этапе формирования каталога услуг при установке и настройке приложения. Настройки можно изменить в любой удобный момент, и это не отразится на ранее полученных заявках.

    В задаче для исполнителя сразу указаны контактные данные клиента, текст обращения, а также услуга, по которой поступила заявка. Если этот клиент уже зарегистрирован в CRM Битрикс24, то задача автоматически прикрепляется к его карточке. Получается, что ответственный менеджер отдела продаж увидит, с какими запросами обратился его клиент в сервисный отдел, и сможет подумать, какие еще продукты или услуги продать клиенту дополнительно. В перспективе в Admin24 можно будет автоматически формировать и отправлять счета на оплату из CRM Битрикс24.

    В настоящее время реализован минимальный функционал Admin24 — Service Desk, который уже позволяет использовать Битрикс24 как систему автоматизации обслуживания клиентов. Все параметры SLA по каждой заявке фиксируются, и руководитель в специальном отчете видит, сколько заявок не решены в положенный срок, на сколько из них реагировали не вовремя. У руководителя появляется возможность принимать решения на основе этих отчетов, проводить работу над ошибками и повышать качество обслуживания. Этот процесс должен быть непрерывным.

    Таким образом, приложение Admin24 — Service Desk позволяет автоматизировать процесс выполнения заявок и обслуживать клиентов на основе SLA. Любая компания, которая использует Битрикс24, может начать обслуживать своих клиентов на основе Соглашения об уровне сервиса. То есть сформировать свои собственные стандарты обслуживания клиентов и постоянно их улучшать.

    Добавить комментарий

    Ваш адрес email не будет опубликован. Обязательные поля помечены *