Процесс обработки обращений | Creatio Academy

Тикет-система для работы с электронной почтой

Где-то 15 лет назад, с появлением доступного интернета и распространением электронной почты, появился новый тип сервисов — для работы с электронной почтой. Они умели всё то же самое, что тикетницы для сайтов, но научились автоматически регистрировать обращения из почты.

Процесс обработки обращений | Creatio Academy — Громоздкий и непонятный интерфейс OTRS — тикет-системы для работы с электронной почтой.

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

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

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

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

Как можно было заметить, выше описаны преимущества для работы внутри компании. Но еще есть ряд достоинств Service Desk, которые помогают решать задачи для работы с клиентами и заказчиками. К таким преимуществам сервисдеск относится:

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

Ещё про Yota: Yota научила любить мегафон за 5 дней! | Пикабу

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

Что представляют собой современные it-технологии для обработки заявок

Ярким примером современной IT-технологии для обработки заявок является Smart Service, который объединяет в себе заказчиков, поставщиков и подрядчиков. То есть эта программа позволяет оптимизировать бизнес-процесс, работу персонала, а также контроль за этими процессами.

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

Иногда предприниматели путают две разных технологии: хелпдеск (Help Desk) и сервисдеск (Service Desk). В первом случае речь идет об инструменте для техподдержки пользователей, который облегчает работу (наиболее популярными вариантами выбора являются Exel или другая система учета).

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

принимать заявки потребителей;
формировать клиентский запрос (будь это претензия, похвала или заявка);
контролировать выполнение тикета;
информировать клиентов и пользователей о состоянии их тикета или другого запроса;
управлять базой данных;
соблюдать SLA (соглашение об уровне обслуживания – внешний официальный документ);
передавать данные от потребителя в необходимый отдел компании;
внедрять API (интерфейс программирования приложений) в инфосреду компании;
производить интеграцию с CRM и любыми другими сервисами;
составлять отчетность пользовательских запросов;
систематизировать пользовательские запросы;
вести клиентскую базу.

И если первые семь пунктов может выполнять система хелпдеск, то остальные пункты Help Desk реализовать не сможет. В этом и заключается преимущество сервисдеска, хоть эта технология и стоит несколько дороже. При этом Service Desk может обладать дополнительными параметрами, которые облегчат предпринимателю и его команде использование этой IT-технологии. К таким дополнительным функциям можно отнести:

контроль времени ожидания;
прогноз времени разрешения;
внутренняя wiki;
оценка удовлетворенности пользователей;
быстрый ответ;
и многое другое.

Начало работы над обращением

Чтобы начать работу над обращением, выберите его в реестре раздела Обращения или Единое окно. Открыв страницу обращения, выберите состояние “В работе” на индикаторе стадий (Рис. 1).

В результате состояние обращения будет изменено на “В работе”, а текущий пользователь указан в поле Ответственный. Клиенту будет отправлено email-сообщение о том, что обращение было взято в работу, с информацией по плановому сроку разрешения.

Завершив работу по разрешению обращения, переведите его на следующий шаг, используя индикатор стадий.

На заметку. Если вы хотите, чтобы после внесения изменений на странице обращения и нажатия кнопки Сохранить страница обращения автоматически закрывалась, и выполнялся переход к реестру раздела Обращения, то установите признак Закрывать при сохранении в справочнике “Состояния обращений”. Подробнее >>>

Автоматическая обработка входящих email, сообщений в мессенджерах и заявок

В системе 1С:CRM могут быть настроены правила автоматической обработки входящих email, сообщений в мессенджерах или заявок. Для каждого нового обращения может быть назначен ответственный за обработку. Обращение можно отклонить или на его основании создать Интерес клиента, Обращение в поддержку.

Обработка выполняется по заранее настроенным правилам. Для различных каналов обращений могут быть настроены разные правила обработки. Настройки правил хранятся в справочнике Клиенты → Справочники и настройки → Обращения и заявки → Правила обработки email, сообщений в мессенджерах и заявок.

Правило обработки входящих email выбирается на форме Учетной записи электронной почты. Правило обработки входящих сообщений в мессенджерах выбирается на форме Учетной записи мессенджера или социальной сети, а правило обработки заявок учитывается на форме Источника заявок. Для этого нужно выбрать флаг «Обрабатывать обращения» и выбрать правило обработки.

Выбор правила обработки на форме учетной записи электронной почты

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

Выбор правила обработки на форме учетной записи электронной почты

Каждое условие применения правила — это набор ключевых слов. Условие считается выполненным, если хотя бы одно из слов содержится в теме или в содержании email, заявки, во входящем сообщении мессенджера.

Условия применения правил обработки хранятся в справочнике Клиенты → Справочники и настройки → Обращения и заявки → Условия применения правил обработки email, сообщений в мессенджерах и заявок. Ключевые слова должны быть разделены символом “;”.

Условие применения правила обработки

Каждое правило обработки обращения — это набор настроек, определяющих правила назначения ответственного за обработку обращения, а также описание действия которое нужно выполнить (создать интерес или отклонить обращение).

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

Обращение, для которого не определен ответственный, может быть адресовано одновременно нескольким пользователям, для этого в поле «Адресовать обращение» выбрать значение «На роль исполнителя» и выбрать роль исполнителя, в которую включены нужные сотрудники. Также обращения могут распределяться по очереди между несколькими сотрудниками. Для этого нужно в поле «Адресовать обращение» выбрать значение «На пользователя в очереди» и заполнить список ответственных.

Настройка правила обработки обращения

Также правило обработки позволяет настроить автоматическое создание на основании обращения Интереса клиента или Обращения в поддержку. Для этого нужно в поле Действие выбрать значение «Создать интерес клиента или обращение в поддержку» и указать параметры создания. Также можно настроить автоматическое отклонение обращения. Для этого в поле Действие выбрать значение «Отклонить обращение» и выбрать причину отклонения.

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

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

Вернуться к списку статей

Автоматическое закрытие обращений

Автоматическое закрытие обращений происходит при выполнении следующих условий:

Обращение находится в состоянии разрешения.
У обращения заполнено фактическое время разрешения.
Срок ожидания оценки работ по обращению истек.

На заметку. Срок ожидания оценки по обращению регулируется системными настройками “Количество дней ожидания после запроса оценки” (код “FirstReevaluationWaitingDays”) и “Количество дней ожидания после повторного запроса оценки” (“SecondReevaluationWaitingDays”).

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

Вы можете отключить автоматическое закрытие обращений. Для этого необходимо в системной настройке “Автоматически закрывать решенные обращения” (код “CloseResolvedCases”) снять признак Значение по умолчанию.

Диагностировать и решить инцидент

В Service Creatio, enterprise edition используется подпроцесс “Диагностика и решение инцидента”, который начинает работу при выполнении следующих условий:

На ответственного специалиста службы поддержки создали или назначили инцидент. Состояния инцидента “Новое” или “В работе”.
Состояние неактивного инцидента было изменено на “Новый”, “В работе”, “Переоткрыт”. Заполнено поле Ответственный.
На сотрудника службы поддержки был эскалирован инцидент.

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

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

Источники

1997 — Steve Vinoski — CORBA: Integrating Diverse Applications Within Distributed Heterogeneous Environments2000 — Roy Fielding — Architectural Styles and the Design of Network-based Software Architectures2004 — Microsoft — Message Bus2004 — Microsoft — Understanding Service-Oriented Architecture2023 — Chris Ostrowski — Understanding Oracle SOA — Part 1 — Architecture2023 — Chris Ostrowski — Understanding Oracle SOA — Part 2 — Technologies2023 — Chris Ostrowski — Understanding Oracle SOA — Part 3 — Development2023 — Chris Ostrowski — Understanding Oracle SOA — Part 4 — Business Benefits2023 — Prabhu — Service Oriented Architecture — SOA2023 — Martin Fowler — Microservices2023 — PWC — Agile coding in enterprise IT:

Code small and local2023 — Udi Dahan — Messaging Architecture and Services Bus2023 — Sam Newman — Principles Of Microservices2023 — Kai Wähner — Microservices: Death of the Enterprise Service Bus?2023 — Abraham Marín Pérez — Java 9 Will Remove CORBA from Default Classpath2023 — Oracle — CORBA Technology and the Java Platform Standard Edition2023 — Wikipedia — Distributed object communication2023 — Wikipedia — CORBA2023 — Wikipedia — Сервисная шина предприятия2023 — Wikipedia — REST2023 — Wikipedia — SOAP2023 — Wikipedia — Сервис-ориентированная архитектура2023 — Microsoft — Enterprise Architecture: SOA in the real world

Как можно обрабатывать заявки

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

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

Справка! Например, для приема звонков большинство крупных компаний создают Call-центры, а в последнее время большую популярность набрали SMM-специалисты, которые работают с социальными сетями.

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

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

Коммуникации с заявителем

Для отправки клиенту ответов по обращению используйте кнопки Email и Сообщение на портале на панели действий (Рис. 2).Чтобы добавить вложения в email-сообщение или сообщение на портале самообслуживания, нажмите кнопку

Если сотрудник оставляет на портале сообщение по обращению, то клиент получит соответствующее уведомление по электронной почте.

По окончании работы с обращением, например, если клиенту был отправлен запрос на дополнительную информацию, переведите обращение в состояние “Ожидает ответа” (Рис. 3), которое подразумевает, что по обращению ожидается ответ пользователя.

Пользователь может ответить по электронной почте либо оставить сообщение на портале. В любом случае, его ответ появится в блоке История (Рис. 4). При этом обращение автоматически будет переоткрыто. Поле Ответственный будет очищено и обращение будет возвращено в очередь на обработку.

Чтобы быстро совершить звонок клиенту, поместите курсор на его имя в профиле обращения. Если на странице контакта были добавлены средства связи, то в открывшейся мини-карточке будут доступны опции для совершения звонка (Рис. 5).

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

Микросервисы

В основе микросервисной архитектуры лежат концепции SOA. Назначение у неё то же, что и у ESB: создать единое общее корпоративное приложение из нескольких специализированных приложений бизнес-доменов.

Главное различие микросервисов и шины в том, что ESB была создана в контексте интеграции отдельных приложений, чтобы получилось единое корпоративное распределённое приложение. А микросервисная архитектура создавалась в контексте быстро и постоянно меняющихся бизнесов, которые (в основном) с нуля создают собственные облачные приложения.

То есть в случае с ESB у нас уже были приложения, которые нам не «принадлежат», и поэтому мы не могли их изменить. А в случае с микросервисами мы полностью контролируем приложения (при этом в системе могут использоваться и сторонние веб-сервисы).

Характер построения/проектирования микросервисов не требует глубокой интеграции. Микросервисы должны соответствовать бизнес-концепции, ограниченному контексту. Они должны сохранять своё состояние, быть независимыми от других микросервисов, и потому они меньше нуждаются в интеграции.

[Микросервисы — это] маленькие автономные сервисы, работающие вместе и спроектированные вокруг бизнес-домена.
— Sam Newman 2023, Principles Of Microservices

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

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

Сэм Ньюман, автор Building Microservices, выделяет восемь принципов микросервисной архитектуры. Это:

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

Сообщество предпочитает другой подход: умные конечные точки и глупые каналы. Микросервисы, из которых собираются приложения, должны как можно меньше зависеть друг от друга и при этом быть очень тесно связанными — они содержат собственную доменную логику и работают скорее как фильтры с точки зрения классического Unix: получают запросы, применяют логику и генерируют ответы. Они оркестрируются с помощью простых REST-подобных протоколов, а не сложных протоколов вроде WS-Choreography или BPEL либо какого-то централизованного инструмента.
— Martin Fowler 2023, Microservices

Найти решение обращения

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

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

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

Если в списке есть полностью аналогичное обращение, то выберите это обращение, нажав кнопку Выбрать. В результате выбранное обращение будет указано в поле Родительское обращение текущего обращения.

Настраиваем автоматические действия

Сначала настроим оповещение для клиента при регистрации обращения . В форме карты маршрута «Обращение» выберем команду «Настройка этапов», выделим самый первый этап в карте «Классификация обращения» и справа в группе «Контроль выполнения условий на этапе» введем нужные условия:

Событие: в значение «При переходе на этап»;
Тип действия: в значение «Оповещение email»;
Условие для выполнения: оставим пустым.
Цель: выберем подготовленный шаблон оповещения при регистрации обращения

В самом конце установим признак отправки оповещения клиенту:

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

Так же настроим оповещения для этапа «Отработка»:

Событие: в значение «При завершении»;
Тип действия: в значение «Оповещение email»;
Условие для выполнения: без условия;
Цель: выберем подготовленный шаблон оповещения клиента о закрытии обращения;

И, как в прошлый раз, установим признак отправки оповещения клиенту:

‼️Чтобы клиенту ушло оповещение, нужно при регистрации обязательно заполнить способ контакта — номер телефона, чтобы отправить СМС, или адрес электронной почты.

Обращение

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

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

При регистрации обращения работает поиск заявителя по фамилии, имени, отчеству (или их частям) а также по дате рождения:

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

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

Письмо о продлении срока рассмотрения обращения
Печать конверта

Обращения клиентов в социальных сетях и мессенджерах

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

Тикет-системы для электронной почты стали добавлять новые каналы: ВКонтакте, Инстаграм, WhatsApp, Телеграм и другие. Однако все системы, изначально рассчитанные на почту, столкнулись с проблемой поддержки чатов: чат с клиентом один, а запросов у клиента много — невозможно разбить переписку на тикеты.

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

Если половина обращений ваших клиентов идут из соцсетей и мессенджеров — нужно использовать омниканальные тикет-системы, изначально созданные для этого. На Западе уже довольно много таких систем: Front, Intercom, Gorgias, на русском языке только Еадеск.

Общая архитектура брокера объектных запросов (corba)

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

Стандарт CORBA был реализован несколькими вендорами. Он обеспечивает:

Сегодня CORBA всё ещё используется для разнородных вычислений. Например, он до сих пор является частью Java EE, хотя начиная с Java 9 будет поставляться в виде отдельного модуля.

Хочу отметить, что не считаю CORBA паттерном SOA (хотя отношу и CORBA, и SOA-паттерны к сфере распределённых вычислений). Я рассказываю о нём здесь, поскольку считаю недостатки CORBA одной из причин возникновения SOA.

Правило №1:фиксируйте все обращения

Чтобы ничего не потерять и не забыть — все обращения клиентов должны быть зафиксированы в одном окне.

Часто бывает, что сначала клиент напишет в чат, а по телефону сообщает важные детали — потом их невозможно будет найти и восстановить. Хорошо, если есть запись звонка, а если нет? И если записей по одному клиенту несколько, придётся переслушать все, чтобы найти нужный момент.

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

Главные каналы при работе с клиентами:

Правило №4: контролируйте показатели

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

Это правило последнее и будет ошибкой начинать работу в тикет-системе с отчётов и показателей. Показатели — это обратная связь по проделанной работы, которую нужно сначала сделать. Представьте, вы решили получить водительские права, и чтобы сдать экзамен в ГИБДД, вам нужно освоить базу: изучить теорию, пройти практику, закончить автошколу. И тогда набранные на экзамене баллы — это ваши показатели, но чтобы их получить — начать нужно с базы.

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

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

Ключевые показатели в службе поддержки:

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

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

В Еадеске вы найдёте единый дашборд, на котором собраны все необходимые данные: по нагрузке, по каналам, по сотрудникам. А вот заметка, как с его помощью принимать управленческие решения.

Принцип работы

Сначала нам нужно получить брокер объектных запросов (Object Request Broker, ORB), который соответствует спецификации CORBA. Он предоставляется вендором и использует языковые преобразователи (language mappers) для генерирования «заглушек» (stub) и «скелетов» (skeleton) на языках клиентского кода.

С помощью этого ORB и определений интерфейсов, использующих IDL (аналог WSDL), можно на основе реальных классов генерировать в клиенте удалённо вызываемые классы-заглушки (stub classes). А на сервере можно генерировать классы-скелеты (skeleton classes), обрабатывающие входящие запросы и вызывающие реальные целевые объекты.

Вызывающая программа (caller) вызывает локальную процедуру, реализованную заглушкой.

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

Простая тикет-система для технической поддержки на русском

Еадеск — это простая тикетная система для технической поддержки на русском языке. Он помогает увеличить скорость обработки обращений в 3−5 раз за счёт объединения разных каналов и источников в одном окне, интуитивно понятного интерфейса, автоматизации и контроля работы через наглядные показатели.

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

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

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

В этом разговоре нет ни одного тикета, зато есть диалог между начальником и сотрудником, например, по телефону или в переписке WhatsApp. Из диалога можно извлечь три задачи для сотрудника:

Дождаться или напомнить про детали участия в конференции.
Подготовиться к ней и принять участие.
Сделать отчёт к концу недели.

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

Разработка прототипа мобильного приложения банка для обработки обращений клиентов

УДК 330.4

DOI 10.21685/2309-2874-2022-2-2

П. А. Кармишин, С. В. Рындина

РАЗРАБОТКА ПРОТОТИПА МОБИЛЬНОГО ПРИЛОЖЕНИЯ БАНКА ДЛЯ ОБРАБОТКИ ОБРАЩЕНИЙ КЛИЕНТОВ

Аннотация.

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

Материалы и методы. Рассмотрены лучшие практики создания мобильных приложений банков: мобильное приложение «Сбербанк Онлайн» и мобильное приложение «Тинькофф Банк». Выявлены их сильные и слабые стороны в работе службы поддержки через мобильное приложение.

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

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

Ключевые слова: бизнес-процессы, банкинг, мобильные приложения, обращения клиентов.

P. A. Karmishin, S. V. Ryndina

DEVELOPMENT OF A PROTOTYPE OF A MOBILE APPLICATION FOR BANKS TO PROCESS CUSTOMER APPEALS

Abstract.

Background. The development of prototypes of mobile applications allows us to identify problems with the user interface at the earliest stages with the help of UX-testing. This reduces the costs for the entire development cycle, because the problems in the interface found at the testing stage of the finished software are much more expensive.

Materials and methods. In the article the best practices of creation of mobile applications of banks are considered: mobile application “Sberbank Online” and mobile application “Tinkoff Bank”. Identified their strengths and weaknesses in the service support through a mobile application.

Results. Based on the analysis of the interface of mobile applications of banks present in the banking services market, the requirements for the developed interface

© 2023 Кармишин П. А., Рындина С. В. Данная статья доступна по условиям всемирной лицензии Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), которая дает разрешение на неограниченное использование, копирование на любые носители при условии указания авторства, источника и ссылки на лицензию Creative Commons, а также изменений, если таковые имеют место.

of the mobile application for handling customer requests are defined. A prototype of the mobile application of the bank for handling customer requests was developed.

Conclusions. The development of a prototype mobile application allows early testing of the user interface and finalizing it based on identified user problems when using the application at the prototype stage.

Keywords: business processes, banking, mobile applications, customer appeals.

Рассмотрим лучшие практики мобильного банкинга: мобильные приложения крупнейшего банка России «Сбербанк» и крупнейшего онлайн-банка России «Тинькофф Банк».

Мобильное приложение Сбербанка – это сервис «Сбербанк онлайн». Интересующий нас раздел поддержки клиентов находится в сложно доступном месте: маленькая иконка есть только на главном окне приложения.

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

Звонок специалисту – стандартный способ связи и в нем нет принципиальных новшеств по сравнению с традиционным звонком со стационарного телефона.

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

Среди достоинств следует отметить: включенный в приложение мес-сенджер для общения между пользователями и продуманный графический дизайн: контрастность, яркость, читабельность – на высоте при сохранении стилистики корпоративных цветов банка (рис. 1) [1].

.■ Tele2RUi? 18:12 -f 13%

<] Обратная связь 0

Г-Н Входящие

Отправленные

[IJJ Корзина

Рис. 1. Интерфейс окна службы поддержки «Сбербанк Онлайн»

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

Большой плюс службы поддержки Тинькофф Банка в том, что у пользователя есть возможность в реальном времени связаться со специалистом,

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

Добрый день !

Здравствуйте!

Как пополнить карту банка ? С карточки белорусского банка

Сейчас уточню. Пару минут, пожалуйста,

пополнить карту можно в мобильном приложении. Для этого в разделе “Счета” выберите Вашу карту и нажмите “Пополнить”.

nfobanÜ.by ®

Рис. 2. Окно онлайн-чата в мобильном приложении «Тинькофф Банк»

Перейдем к разработке собственного прототипа. На главном экране (как и на любом другом) в нижнем меню расположено пять вкладок: последняя вкладка – Поддержка (рис. 3), при нажатии на которую он попадает в меню регистрации обращений.

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

Далее следует окно ввода обращения (рис. 4). Здесь пользователю нужно ввести ФИО, для первичной идентификации и дальнейшего обращения к нему. Также присутствует поле, в которое пользователь должен ввести текст обращения.

В следующем окне пользователю предлагается выбрать удобный для него способ дальнейшей связи с ним. На выбор предлагается три варианта: «Электронная почта», «8М8-сообщения», «Онлайн-чат».

«Электронная почта». После выбора данного способа связи пользователь переходит в окно ввода электронного адреса, на котором имеется поле для ввода адреса, а также кнопка «Назад» для возврата в предыдущее окно и кнопка «Готово» для перехода в следующее окно с подтверждением регистрации сообщения и благодарностью за обращение (рис. 5).

Рис. 3. Интерфейс меню регистрации обращений

Рис. 4. Интерфейс окна ввода обращения и выбора способа связи

«8М8-сообщения». После выбора данного способа связи пользователь переходит в окно ввода номера мобильного телефона, на котором имеется поле для ввода номера телефона, а также кнопки «Назад» для возврата в

предыдущее окно и «Готово» для перехода в следующее окно с подтверждением регистрации сообщения и благодарностью за обращение (рис. 6).

Вернуться на главный экран Рис. 5. Интерфейс окна ввода email и подтверждения регистрации

Рис. 6. Интерфейс окна ввода номера мобильного телефона и подтверждения регистрации

«Онлайн-чат». После выбора данного способа связи пользователь подключается к чату со специалистом в реальном времени. В окне чата мы видим основное поле, на котором видна история сообщений, также поле для ввода текста сообщения и кнопку для отправки сообщения (рис. 7). По окончании диалога пользователю будет предложено оценить работу специалиста по 5-балльной шкале, а также оставить комментарий по его работе. Реализовано это будет с помощью отдельного экрана, переход на который будет осуществлен после окончания диалога. На этом экране также расположены кнопка «Готово» для отправки оценки и кнопка «Вернуться на главный экран» для возврата на главный экран без оценки работы специалиста [2].

Рис. 7. Интерфейс окна онлайн-чата и оценки работы специалиста

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

Карта действий представляет собой последовательно расположенные окна интерфейса, с указаниями всех возможных путей возврата либо перехода из каждого окна (рис. 8).

Текстовое представление карты действий:

1) А – стартовый экран. В него пользователь попадает при нажатии на кнопку «Поддержка»;

2) из экрана А возможно сделать два прямолинейных перехода: А-В, В-С;

3) из экрана С мы можем сделать три перехода: С-Б, С-Б, С-Н;

4) из окна Б возможен переход в окно О и последующий возврат в окно А;

5) из окна Б возможен переход в окно Е и последующий возврат в окно А;

6) из окна Н возможен переход в окно I и последующий возврат в окно А.

Рис. 8. Карта действий для обращения в службу поддержки через мобильное приложение

На последнем этапе разработки прототипа проводят UX-тестирование. UX – user experience, в переводе значит «опыт пользователя». Это наиболее объективный метод тестирования интерфейса, так как тестирование проводится потенциальными пользователями продукта под наблюдением аналитиков. Большим плюсом является то, что тестирование можно проводить на разных этапах разработки, т.е. достаточно разработать прототип интерфейса и уже после его тестирования прийти к полезным выводам, которые позволят улучшить опытный образец.

Библиографический список

1. Блог Сбербанка. – URL: https://yota-inet.ru/company/sberbank/blog/353746/

2. Блог Тинькофф Банка. – URL: https://yota-inet.ru/company/tinkoff/blog/303580/

References

1. Blog Sberbanka [Blog Sberbank]. Available at: https://yota-inet.ru/company/sberbank/ blog/353746/

2. Blog Tin’koff banka [Tinkoff Bank Blog]. Available at: https://yota-inet.ru/company/ tinkoff/blog/303580/

Кармишин Павел Андреевич студент, Пензенский государственный университет (Россия, г. Пенза, ул. Красная, 40)

E-mail: mr.karmishin@mail.ru

Karmishin Pavel Andreevich Student, Penza State University (40 Krasnaya street, Penza, Russia)

Рындина Светлана Валентиновна

кандидат физико-математических наук, доцент, кафедра экономической кибернетики, Пензенский государственный университет (Россия, г. Пенза, ул. Красная, 40)

E-mail: svetlanar2004@yandex.ru

Ryndina Svetlana Valentinovna Candidate of physical and mathematical sciences, associate professor, sub-department of economic cybernetics, Penza State University (40 Krasnaya street, Penza, Russia)

УДК 330.4 Кармишин, П. А.

Разработка прототипа мобильного приложения банка для обработки обращений клиентов / П. А. Кармишин, С. В. Рындина // Известия высших учебных заведений. Поволжский регион. Экономические науки. -2023. – № 2 (8). – С. 13-20. – Б01 10.21685/2309-2874-2022-2-2.

Разрешение и оценка

После того как клиенту было предоставлено решение, переведите обращение в состояние разрешения.

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

В зависимости от того, как клиент оценит работу, состояние обращения изменится. Например:

На заметку. Взаимосвязь между оценкой уровня удовлетворенности клиента и состоянием обращения настраивается в справочнике Уровни удовлетворенности.

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

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

Сервисная шина предприятия (esb)

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

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

Поэтому разработчики приложений предусматривали конечные точки для отправки и приёма данных в определённом формате. Компании-клиенты потом интегрировали приложения, налаживая между ними каналы связи и преобразуя сообщения с одного языка приложения в другой.

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

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

Клиент (сервис или модульное приложение) отправляет запрос на сервисную шину, которая преобразует сообщение в формат, поддерживаемый в точке назначения, и перенаправляет туда запрос. Всё взаимодействие идёт через сервисную шину, так что если она падает, то с ней падают и все остальные системы. То есть ESB — ключевой посредник, очень сложный компонент системы.

Это очень упрощённое описание архитектуры ESB. Более того, хотя ESB является главным компонентом архитектуры, в системе могут использоваться и другие компоненты вроде доменных брокеров (Domain Broker), сервисов данных (Data Service), сервисов процессной оркестровки (Process Orchestration Service) и обработчиков правил (Rules Engine).

Тот же паттерн может использовать интегрированная архитектура (federated design): система разделена на бизнес-домены со своими ESB, и все ESB соединены друг с другом. У такой схемы выше производительность и нет единой точки отказа: если какая-то ESB упадёт, то пострадает лишь её бизнес-домен.

Главные обязанности ESB:

Создавая структуры связи между разными процессами, мы видели много продуктов и подходов, в которых применяются очень развитые механизмы связи. Хороший пример — сервисные шины предприятий, часто включающие в себя сложные средства маршрутизации сообщений, хореографии, преобразования и применения бизнес-правил.
— Martin Fowler 2023, Microservices

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

Также рекомендую не забывать, что реализации ESB уже достаточно развиты и в большинстве случаев позволяют использовать для своего конфигурирования пользовательский интерфейс с поддержкой drag & drop.

Система обработки обращений в ит-службу

Правильно организованная ИТ-служба – залог эффективной работы любой организации и ее сотрудников.. Предоставление качественных ИТ-услуг и их поддержка на должном уровне является важной задачей отдела Service Desk. Ключевой функцией 1-й линии поддержки является предоставление единого удобного канала взаимодействия с пользователем и своевременное решение всех проблем, возникающие в процессе использования оказываемых ИТ услуг.

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

В ITSM 365 обработка обращений пользователей проходит максимально удобно. В системе преднастроены все этапы работы с заявками пользователей: регистрация, классификация, разделение на конкретные работы, выполнение и закрытие. На старших тарифах процессы обработки обращений могут быть настроены индивидуально под Ваш процессы.

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

Создать статью базы знаний после решения обращения

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

По умолчанию подпроцесс не активен. Для активации подпроцесса:

Откройте дизайнер системы по кнопке .
В блоке Настройка системы перейдите по ссылке Библиотека процессов.
Снимите быстрый фильтр Активные, чтобы отобразились все бизнес-процессы системы.
Выберите бизнес-процесс “Создание новой статьи в БЗ после решения обращения” в реестре и нажмите Активировать (Рис. 7).

Работа подпроцесса будет происходить по следующему алгоритму:

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

Уведомить ответственного/группу о назначении обращения

Уведомления ответственному/группе о назначении обращения отправляются в случае, если обращение переводят в активное состояние и поля Ответственный и/или Группа ответственных заполнены. Также уведомления ответственному/группе отправляются в случае назначения активного обращения на группу/ответственного.

На заметку. Активным считается обращение, которое находится в одном из следующих состояний: “Новое”, “В работе”, “Переоткрыто”.

Уведомление ответственному отправляется в случае, если заполнено поле Ответственный. Поле Группа ответственных при этом может быть или пустым, или заполнено.

Уведомление группе ответственных отправляется в случае, если заполнено поле Группа ответственных, а поле Ответственный пустое. В этом случае в поле письма Кому подставляются адреса всех участников группы.

Текст уведомления, которое отправляется ответственному либо группе ответственных, настраивается в справочнике Шаблоны email сообщений. По умолчанию в уведомлениях используется шаблон “Назначение ответственного в обращении”.