Портал №1 по управлению цифровыми
и информационными технологиями

Упражнение про поддержку

Вот вам, уважаемые читатели портала, еще одна иллюстрация – на этот раз в форме задачки. Про поддержку.

 

Один замечательный банк, работающий с клиентами исключительно через интернет, с недавнего времени предлагает посетителям своего сайта возможность купить страховой полис одной замечательной страховой компании – для страхования путешествий, имущества или жизни. Мне нужно было путешествий. Причем не моих, а одного молодого человека, которому в конце июня должно исполниться 18 лет, и который будет праздновать это событие в коротком, но увлекательном путешествии по Европе. Путешествие состоится в июле, когда путешественник будет уже совершеннолетним, поэтому полис ему нужен "взрослый" – на сайте есть две возрастных категории: "дети" (0-17) и "взрослые" (18-64). Итак, выбираю условия страхования и перехожу к вводу информации о застрахованных лицах. И получаю от системы сообщение об ошибке: сверив дату рождения застрахованного с условиями полиса, она мне говорит: "Вам должно быть больше 18 лет". И не дает двигаться дальше. 

 

 

 

 

 

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

А надо сказать, что поддержка по телефону в этом банке очень даже приличная. Поэтому отвечают мне почти мгновенно, понимают меня с первого раза и очень оперативно переводят на следующую линию, где понимают тоже довольно быстро и берут минуту на размышление. Через минуту специалист вернулся ко мне с таким предложением: он переведет меня на поддержку страховой компании, и те мне помогут оформить полис. Я уточнил: "Они мне помогут оформить его на вашем сайте, или мне можно его (сайт) закрывать и отправляться непосредственно в страховую?" Ответ был уверенным и однозначным: "Помогут оформить на нашем сайте". Дальше была музыка, IVR, специалист страховой компании, еще немного ожидания – и наконец ответ: "Обратитесь в поддержку банка, ошибка – у них на сайте." Я, конечно, указал на то, что я оттуда и пришел, и тогда мне предложили оформить полис на сайте самой компании. "А вы уверены, что там такой ошибки нет?" "Во всяком случае, к нам с ней никогда не обращались". Ну хорошо. Спасибо, до свидания. 

Часть вторая. Та же задача, сайт другой. Очень быстро выяснилось, почему у них не было таких обращений: на сайте страховой компании тоже две возрастных категории: 0-3 года и 4-64. То есть нашей ошибки нет. Зато есть другая. Меню выбора зоны действия страховки реализовано в виде карты мира, на которой можно выирать сначала регионы, а потом страны. И есть еще кнопочка "все страны". Нам же был нужен весь Шенген, которого найти не удалось. А при этом на сайте посольства отдельно написано, что варианты вида "Страна, Шенген", даже если стран много, – недопустимы. Должен быть весь.

Снова звоним в поддержку. Lifehack: оказывается, если выбрать Финляндию, то в полисе будет написано просто "Шенген". Ура. Оформляем, платим, печатаем. 

 


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

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

Если среди читателей есть сотрудники того самого банка – ваши версии особо приветствуются!

 

«VAP: Управление поддержкой ИТ-услуг»
Строим эффективную ИТ-поддержку, оптимизируем существующую

Комментариев: 16

  • P.S.Да, стилистически и "проверка должна контролировать" и, в особенности, "сервисная служба" – это ужас что такое. Виноват. Но поздно уже слова из песни выкидывать,придется оставить так…

     

  • Максим

    На мой вкус стоит начать с ответа на вопрос о массовости подобных обращений. И, возможно, после ответа на этот вопрос работа над ошибкой и закончится;-)

    • Да, я ждал такого комментария. Это, конечно, не массовая проблема. Хотя, конечно, более массовая, чем на границе в три года. Но, во-первых, сама услуга со страхованием носит, скорее всего, имиджевый характер и не является для банка существенным источником прибыли. Когда имиджевый элемент не срабатывает, это портит имидж (о!). А во-вторых, это все-таки уход от ответа. Понятно, что решение "ничего не делать" – самое простое и дешевое в исполнении. Но я-то спрашивал о том, как делать.  Кто кому что как должен сообщить, чтобы в итоге ошибка исправилась? Как сделать так, чтобы цепочка не оборвалась? Кто должен ее контролировать? В общем, как система управления справится с задачей исправления ошибки, выявленной пользователем?

      А есть ли в самом деле ошибка и бизнес-кейс для ее исправления – для этой задачки не так уж важно… 

       

       

  • Ирина

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

    Участники: клиент банка, оператор call-центра, владелец бизнес-опции покупки страховки через сайт, разработчик ПО для реализации опции.

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

    • Ирина, спасибо! 

      Если позволите, пара вопросов:

      А кто должен инициировать перевод записи об обращении в клиентскую поддержку в инцидент для разработчиков ПО? 

      Зачем в этой ситуации разработчикам два объекта – инцидент и проблема?

      • Ирина

        Инициировать перевод записи – оператор call-центра (мне кажется, что адресат в данном случае очевиден, компетенции оператора должно хватить, если таких прав у оператора нет, то эскалация выше, на руководителя операторов).

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

  • АP

    Задачка (Часть 1)

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

    • АР, спасибо! А зачем банку страховая для решения этого обращения?

      • АP

        Роман, предположу, что при возникновении обращения, связанного с услугой "Страхование",  устранением занимаются специалисты Банка, сотрудники Подрядчика привлекаются как 3-я линия поддержки. Также возможны варианты привлечения специалистов Подрядчика для устранения проблем, которые будут регистрироваться в результате анализа инцидентов.

         

      • Максим Прынков

        Роман, кейс действительно интересный. И разработчики уже о нем знают :).

        Не нужно строить сложных теорий, все намного проще:

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

        • О, Максим, спасибо! Этак я и про отрисовку графика остатка на счете напишу пост 🙂 Если, конечно, придумаю подходящих сложных теорий…

          • Максим Прынков

            А вот в этом случае я к сожалению не смогу подсказать конкретики 🙂 Т.к. говорю за страховую компанию 🙂

  • A

    На самом деле, есть более не приятная проблемма в данном кейсе, чем ошибка бизнес-логики.

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

    Вариант решения задачи может быть такой:

    1.Регистрируется инцидент: "Ошибка бизнес-логики".

    2.привязывается к сервису: "Страхование"

    3.эскалируется специалистам, ответственным за данный сервис.

    4.решается

    5. результат проверяется поддержкой и желательно владельцем сервиса :"Страхование"

    6. (идеально бы 🙂 служба поддержки связывается с Романом, и рассказывает о своих успехах.

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

  • Анастасия

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

  • Юрий Алдунин

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

    1. С большой долей вероятности страховой калькулятор писался страховой – банк только "встраивал" его в страницу.

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

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

    Исходя из вышеизложенного, делаю вывод:

    на практике это решается никак;

    в теории можно строить цепочку SLA (банк-страховая) -> Инцидент (страховая) -> Проблема (страховая) -> …

    P.S. Поскольку было выбрано именно страхование ВЗР (не профильное для страховой компании направление, не приносящее особого дохода и позволяющее "один раз сделать и забыть") если я и далёк от истины, то не сильно.

  • Pavel Zhavoronkov

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

    В первом случае запрос должен быть выполнен вручную (я думаю это вполне реализуемо). А такой "футбол" клиентом не характеризует поддержку банка с лучшей стороны. Вопрос к руководителю поддержки банка – почему эскалируется не сам запрос, а клиент вместе с запросм?

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


Добавить комментарий для Роман ЖуравлёвОтменить ответ

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM