UX-исследования в области обслуживания клиентов
Выступление на конференции RAUX
Анна Ефименко: Давайте начнем. В 2020 году отделы обслуживания клиентов существуют во всех уголках мира. Для них это один из самых загруженных периодов из-за пандемии COVID -19. Многие компании заметили значительное увеличение объема работы. Люди обращались в службу поддержки по разным причинам.
Возможно, у кого-то из вас тоже был отменен рейс из-за пандемии. Я хотела вернуть свои деньги и позвонила в службу поддержки авиакомпании, чтобы запросить возврат средств. Но вместо ответа мне предложили обратиться к ним по электронной почте. Тогда я отправила электронное письмо с просьбой о возврате денежных средств, и вскоре мне сообщили, что процедура возврата будет рассмотрена. Сейчас, спустя пару месяцев, довольно типичный случай для авиакомпаний, я так и не получила возврат денежных средств. Поэтому я снова связалась со службой поддержки, на этот раз спросив о статусе моего возврата. И они ответили, по сути, предложив мне подождать еще, поскольку процедура возврата продолжается.
Возможно, у кого-то из вас тоже был отменен рейс из-за пандемии. Я хотела вернуть свои деньги и позвонила в службу поддержки авиакомпании, чтобы запросить возврат средств. Но вместо ответа мне предложили обратиться к ним по электронной почте. Тогда я отправила электронное письмо с просьбой о возврате денежных средств, и вскоре мне сообщили, что процедура возврата будет рассмотрена. Сейчас, спустя пару месяцев, довольно типичный случай для авиакомпаний, я так и не получила возврат денежных средств. Поэтому я снова связалась со службой поддержки, на этот раз спросив о статусе моего возврата. И они ответили, по сути, предложив мне подождать еще, поскольку процедура возврата продолжается.
Меня зовут Анна, можно Аня, и я специалист в области изучения пользовательского опыта (UX-исследователь). У меня был доступ к тысячам подобных историй о службе поддержки, поскольку мне посчастливилось работать исследователем в отделе обслуживания клиентов.
Вы можете задаться вопросом, что же UX-исследователь делает в отделе обслуживания клиентов. Дело в том, что руководство данного отдела организовало мою исследовательскую группу, чтобы помочь с их представлением о создании потока данных от службы поддержки к тем, кто использует данные для принятия решений об улучшении продукта в техническом отделе и отделе управления продуктом, т.е. дизайнерам, продакт-менеджерам, разработчикам и копирайтерам.
Зачем они хотели создать этот поток данных?
Обслуживание клиентов рассматривалось как «золотая жила» с огромным объемом данных о наших клиентах, однако мало кто в компании, казалось, обращал на это внимание. Кроме того, получение и обработка этих данных представляли собой трудоемкий процесс для продуктовых команд. Таким образом, они бы пренебрегли ценным ресурсом. Предположим, что «золото» есть, но нужно, чтобы кто-то его добыл, отполировал и предоставил конечным пользователям. Моя исследовательская группа была создана как раз для того, чтобы выступать в качестве такого рода посредника, помогая привносить новые идеи, которые смогут улучшить продукты.
Обслуживание клиентов рассматривалось как «золотая жила» с огромным объемом данных о наших клиентах, однако мало кто в компании, казалось, обращал на это внимание. Кроме того, получение и обработка этих данных представляли собой трудоемкий процесс для продуктовых команд. Таким образом, они бы пренебрегли ценным ресурсом. Предположим, что «золото» есть, но нужно, чтобы кто-то его добыл, отполировал и предоставил конечным пользователям. Моя исследовательская группа была создана как раз для того, чтобы выступать в качестве такого рода посредника, помогая привносить новые идеи, которые смогут улучшить продукты.
Но почему вы, технический отдел и отдел управления продуктом вообще должны беспокоиться о сведениях отдела обслуживания клиентов?
Во-первых, эти сведения предоставляют возможности для улучшения пользовательского опыта, потому что обращение в службу поддержки в основном свидетельствует о неудачном пользовательском опыте, а лучший пользовательский опыт вполне может быть тот, при котором вам вообще не нужно обращаться в службу поддержки.
Во-первых, эти сведения предоставляют возможности для улучшения пользовательского опыта, потому что обращение в службу поддержки в основном свидетельствует о неудачном пользовательском опыте, а лучший пользовательский опыт вполне может быть тот, при котором вам вообще не нужно обращаться в службу поддержки.
Во-вторых, понимание данных отдела обслуживания клиентов также помогает достичь ключевых показателей эффективности компании (КПЭ). Например, вы можете определить способы снижения расходов и, в свою очередь, максимизировать прибыль. Кроме того, продуктовые команды могут сосредоточиться на новых показателях помимо традиционных. Например, они могут сконцентрировать свое внимание на сокращение количества обслуживаемых клиентов.
И, наконец, понимание данных отдела обслуживания клиентов также может помочь повысить их лояльность или, по крайней мере, избежать ее потери. Усилия клиентов (важное понятие), т.е. работа, которую клиенты должны проделать для решения проблемы, могут быть хорошим показателем лояльности.
Таким образом, сведения, полученные от отдела обслуживания клиентов, могут сильно повлиять на успех компании. Но с чего начать?
Мы договорились с заинтересованными сторонами сосредоточиться на одной области исследования и предоставить сведения о том, с какими проблемами сталкиваются клиенты, зачем они обращаются в службу поддержки, а также в чем заключаются основные причины их обращения. Нас попросили выявить способы, которые помогут предотвратить возникновение проблем у клиентов, а также помогут обеспечить успех как клиентам, так и компании.
Мы договорились с заинтересованными сторонами сосредоточиться на одной области исследования и предоставить сведения о том, с какими проблемами сталкиваются клиенты, зачем они обращаются в службу поддержки, а также в чем заключаются основные причины их обращения. Нас попросили выявить способы, которые помогут предотвратить возникновение проблем у клиентов, а также помогут обеспечить успех как клиентам, так и компании.
Мы начали с ознакомления и изучения инфраструктуры данных отдела обслуживания клиентов, поскольку мы были из UX, из технического отдела и совершенно не знакомы с данной областью. Как и в большинстве отделов обслуживания клиентов, там существовала система обработки заявок. Возможно, некоторые из вас знакомы с такими веб-сервисами, как «Zendesk» или «Jira». Такая система централизует и отслеживает все косвенные обращения по обслуживанию клиентов из разных каналов в одном месте.
Когда у клиента возникает проблема, он обращается в службу поддержки и, таким образом, открывается карточка. После этого агенты службы поддержки могут взаимодействовать с клиентами в одной и той же карточке, и когда проблема решена, карточки приобретают статус «решена» или закрываются. На них также могут быть теги, в нашем случае они были. Но тегов оказалось недостаточно, чтобы понять клиентский опыт. Например, если у вас есть такой тег, как оплата, он, конечно, о чем-то говорит, но все еще неясно, с какой именно проблемой столкнулся клиент. Кроме того, эта система не очень эффективна для продуктовых команд, если они пытаются улучшить продукт.
Имея базовое представление об инфраструктуре обслуживания клиентов, нашей исследовательской группе пришло время начать «поиски золота». Если вы хотите провести исследование в области обслуживания клиентов, следует начать с анализа данных, которые уже имеются у вашей компании. Таким образом, вы можете осуществить качественный и, в идеале, количественный анализ. Кроме того, у вас есть и другие варианты. Вы можете провести исследование, взаимодействуя с представителями службы поддержки. Например, вы можете задавать им вопросы или наблюдать за их работой, а также изучать темы обслуживания клиентов с вашей целевой аудиторией. Возможно, вам захочется узнать, чего они ожидают, когда возникают проблемы, а также какие шаги они предпринимают для их решения.
Когда у клиента возникает проблема, он обращается в службу поддержки и, таким образом, открывается карточка. После этого агенты службы поддержки могут взаимодействовать с клиентами в одной и той же карточке, и когда проблема решена, карточки приобретают статус «решена» или закрываются. На них также могут быть теги, в нашем случае они были. Но тегов оказалось недостаточно, чтобы понять клиентский опыт. Например, если у вас есть такой тег, как оплата, он, конечно, о чем-то говорит, но все еще неясно, с какой именно проблемой столкнулся клиент. Кроме того, эта система не очень эффективна для продуктовых команд, если они пытаются улучшить продукт.
Имея базовое представление об инфраструктуре обслуживания клиентов, нашей исследовательской группе пришло время начать «поиски золота». Если вы хотите провести исследование в области обслуживания клиентов, следует начать с анализа данных, которые уже имеются у вашей компании. Таким образом, вы можете осуществить качественный и, в идеале, количественный анализ. Кроме того, у вас есть и другие варианты. Вы можете провести исследование, взаимодействуя с представителями службы поддержки. Например, вы можете задавать им вопросы или наблюдать за их работой, а также изучать темы обслуживания клиентов с вашей целевой аудиторией. Возможно, вам захочется узнать, чего они ожидают, когда возникают проблемы, а также какие шаги они предпринимают для их решения.
Но почему вы, технический отдел и отдел управления продуктом вообще должны беспокоиться о сведениях отдела обслуживания клиентов?
Во-первых, эти сведения предоставляют возможности для улучшения пользовательского опыта, потому что обращение в службу поддержки в основном свидетельствует о неудачном пользовательском опыте, а лучший пользовательский опыт вполне может быть тот, при котором вам вообще не нужно обращаться в службу поддержки.
Во-первых, эти сведения предоставляют возможности для улучшения пользовательского опыта, потому что обращение в службу поддержки в основном свидетельствует о неудачном пользовательском опыте, а лучший пользовательский опыт вполне может быть тот, при котором вам вообще не нужно обращаться в службу поддержки.
Наша команда начала с анализа данных отдела обслуживания клиентов, которыми располагала наша компания, потому что мы хотели понять, с какими основными проблемами сталкивались наши клиенты. А также потому, что мы UX-исследователи, и как UX-исследователи мы любим наблюдать за поведением. Поэтому, анализируя карточки, мы в основном наблюдаем за действиями клиентов ретроспективно. Поскольку все их действия в них отслеживаются, мы можем получить доступ ко всем взаимодействиям клиентов со службой поддержки. Например, это могут быть электронные письма или сообщения, которые они отправили или получили, сводки телефонных звонков или, возможно, действия, которые клиенты или служба поддержки выполнили.
Мы договорились с заинтересованными сторонами начать анализ с карточек, которые имели теги, чтобы ограничить нашу область изучения (под тегом я имею в виду оплату). Мы сделали это, чтобы выбрать образец для исследования, но позже решили не зацикливаться на тегах, а просмотреть все карточки, которые были у клиента со службой поддержки на протяжении данной операции, чтобы понять полный контекст их опыта: что произошло до проблемы с оплатой и что произошло после нее.
Мы также хотели заранее подумать о продукции и результатах. Мы определили некоторые переменные, которые, по нашему мнению, было бы уместно отслеживать, чтобы лучше понять опыт клиента. Мы черпали вдохновение из анализа задач, схем дизайна услуг и других методов картирования опыта. Я очень рекомендую почитать книгу справа («Путь клиента» Джим Кальбах). Переменные, которые мы выбрали, были ориентированы на клиентов, их цели, контакты и точки соприкосновения со службой поддержки. Но помимо этого, мы также хотели понять всю «экосистему»: кто был вовлечен в проблему клиента и как развивалась каждая из них. С помощью этих переменных мы создали набор данных, потому что хотели систематизировать и отслеживать эти обширные данные о разговорах и взаимодействиях людей. В дальнейшем мы хотели их стандартизировать, когда думали о создании своего рода масштабного потока данных от службы поддержки к техническому отделу и отделу управления продуктом.
Мы также хотели заранее подумать о продукции и результатах. Мы определили некоторые переменные, которые, по нашему мнению, было бы уместно отслеживать, чтобы лучше понять опыт клиента. Мы черпали вдохновение из анализа задач, схем дизайна услуг и других методов картирования опыта. Я очень рекомендую почитать книгу справа («Путь клиента» Джим Кальбах). Переменные, которые мы выбрали, были ориентированы на клиентов, их цели, контакты и точки соприкосновения со службой поддержки. Но помимо этого, мы также хотели понять всю «экосистему»: кто был вовлечен в проблему клиента и как развивалась каждая из них. С помощью этих переменных мы создали набор данных, потому что хотели систематизировать и отслеживать эти обширные данные о разговорах и взаимодействиях людей. В дальнейшем мы хотели их стандартизировать, когда думали о создании своего рода масштабного потока данных от службы поддержки к техническому отделу и отделу управления продуктом.
Как следует подготовившись, мы приступили к «добыче золота» и погрузились в данные. Но когда мы начали читать и классифицировать данные из карточек, мы заметили своеобразное явление, которое не совсем соответствовало нашим целям, но привлекло внимание. Помните мою историю про обращение в службу поддержки авиакомпании? А что, если каждое из этих взаимодействий со службой поддержки было бы такой карточкой? Хотя, как по мне, все это больше похоже на одно и то же обращение клиента. Я попросила возврат, позже мне пришлось попросить снова, через некоторое время мне пришлось спросить о его статусе. С моей точки зрения, как клиента, проблема абсолютно не решена, потому что я все еще жду возврат.
Мы начали задаваться вопросом: что же такое на самом деле карточка? Их часто приравнивают к проблемам клиентов, но так ли это на самом деле? Мы также начали задаваться вопросами: что на самом деле является проблемой клиента, когда она возникает и когда считается решенной, и как мы можем ее определить и измерить. Считается ли началом решения проблемы момент, когда клиент обращается в службу поддержки? Считается ли повтор моей просьбы новой проблемой? Как мы можем постоянно измерять и отслеживать момент, когда возникает новая проблема? Но также как мы можем определить, когда проблема клиента считается решенной? Когда служба поддержки ответила или, может быть, когда они сказали, что вернут деньги? Или, может быть, проблема считается решенной, когда они действительно подтвердят, что вернули мне средства, или, может быть, даже когда я получу возмещение на банковский счет? Все эти варианты означали бы разные определения и измерения.
У моей исследовательской группы было полно подобных вопросов, и наши проекты начали развиваться совершенно в другом направлении. Несмотря на то, что нас об этом не просили, мы решили проследить за данными и изучить карточки в сравнении с проблемой клиентов. Мы начали отслеживать новые переменные, чтобы понаблюдать за их масштабом, а также начали создавать классификацию контактов клиентов, измеряя их проблемы: когда они могут начаться и когда они могут считаться решенными.
У моей исследовательской группы было полно подобных вопросов, и наши проекты начали развиваться совершенно в другом направлении. Несмотря на то, что нас об этом не просили, мы решили проследить за данными и изучить карточки в сравнении с проблемой клиентов. Мы начали отслеживать новые переменные, чтобы понаблюдать за их масштабом, а также начали создавать классификацию контактов клиентов, измеряя их проблемы: когда они могут начаться и когда они могут считаться решенными.
В скором времени мы могли бы начать вести статистику, сравнивая единицу карточки с определенной единицей измерения проблемы клиентов, чтобы узнать, есть ли между ними расхождения. Например, мы могли бы сравнить три карточки с одной проблемой клиента и узнать, сколько из них, по сравнению с проблемами клиентов, было решено.
Хотя мы и не узнали того, к чему стремились изначально, наш обходной путь позволил выявить кое-что еще. Существующая система обработки заявок и показатели были больше ориентированы на измерение опыта операций службы поддержки, а не на опыт клиента. Таким образом, карточки больше измеряли наши внутренние процессы, а не опыт клиентов. Вы можете подумать: ну и что, неужели это серьезная проблема? Что ж, именно здесь нам, исследователям, следует объяснить к каким последствиям для компании это приведет.
Хотя мы и не узнали того, к чему стремились изначально, наш обходной путь позволил выявить кое-что еще. Существующая система обработки заявок и показатели были больше ориентированы на измерение опыта операций службы поддержки, а не на опыт клиента. Таким образом, карточки больше измеряли наши внутренние процессы, а не опыт клиентов. Вы можете подумать: ну и что, неужели это серьезная проблема? Что ж, именно здесь нам, исследователям, следует объяснить к каким последствиям для компании это приведет.
Во-первых, показатели или КПЭ, основанные на полученной заявке, могут измерять не совсем то, что должны. Например, если компания пытается достичь определенного периода времени для решения проблемы клиента, скажем, один или два дня, может быть сложно заявить о прогрессе в достижении этой цели, если мы не будем постоянно измерять момент, когда проблема клиента считается решенной.
Во-вторых, анализ данных и решения, которые мы принимаем на их основе, могут быть ошибочными. Если мы не будем постоянно измерять проблемы клиентов, будет сложно ответить даже на простой вопрос, например, какие проблемы клиентов требуют больше работы агента и, следовательно, являются более затратными для компании?
Наконец, логика системы может иметь недостатки. Например, мы хотим отправить клиентам опрос, чтобы узнать, насколько хорошо служба поддержки справилась с их проблемой. Если решенная карточка не всегда означает результат для клиента, то мы можем отправить опрос слишком рано, и это может повлиять на то, как клиенты оценят услугу. Тогда что же нам делать?
Важно отметить, что карточка – это не единица измерения действий клиента, а хранилище данных. Оно может быть открыто, закрыто или решено в любой момент по усмотрению определенного человека или организации. Если мы нацелены на постоянное измерение пользовательского опыта, нам необходимо создать понятный алгоритм для заявок. Мы можем сделать это, только понимая, определяя, классифицируя и отслеживая опыт клиентов.
Наконец, логика системы может иметь недостатки. Например, мы хотим отправить клиентам опрос, чтобы узнать, насколько хорошо служба поддержки справилась с их проблемой. Если решенная карточка не всегда означает результат для клиента, то мы можем отправить опрос слишком рано, и это может повлиять на то, как клиенты оценят услугу. Тогда что же нам делать?
Важно отметить, что карточка – это не единица измерения действий клиента, а хранилище данных. Оно может быть открыто, закрыто или решено в любой момент по усмотрению определенного человека или организации. Если мы нацелены на постоянное измерение пользовательского опыта, нам необходимо создать понятный алгоритм для заявок. Мы можем сделать это, только понимая, определяя, классифицируя и отслеживая опыт клиентов.
Помните набор данных с переменными, о которых я говорила ранее? Оказалось, что некоторые переменные, которые мы отслеживали в наборе данных, были весьма полезны для определения системы измерения клиентского опыта. В этой системе мы предложили несколько идей.
Во-первых, мы предложили сосредоточиться на единицах измерения, ориентированных на клиента. Взаимодействие с клиентом (атомарная единица) является базовой единицей измерения, а проблема клиента – это хранилище данных, ориентированный на клиента.
Во-вторых, мы предложили определение проблемы клиента, когда она возникает и когда считается решенной, а также какие переменные необходимы для ее структурированного отслеживания в системе, чтобы можно было ее постоянно измерять. Потому что только определений недостаточно.
Во-вторых, мы предложили определение проблемы клиента, когда она возникает и когда считается решенной, а также какие переменные необходимы для ее структурированного отслеживания в системе, чтобы можно было ее постоянно измерять. Потому что только определений недостаточно.
В-третьих, пытаясь описать весь опыт клиента, мы предложили перейти от системы с одним тегом карточки, вроде оплаты, к системе с несколькими тегами или переменными, которые можно отслеживать в разных точках. Мы разработали классификацию для каждой из этих переменных, что означало, что ее можно было отследить до структурированных данных в системе.
Наконец, мы предложили способы концентрации и измерения усилий клиентов. Это важно, поскольку усилия клиентов могут сыграть определенную роль в их удовлетворенности и лояльности. Хочу напомнить, что усилия клиента – это работа, которую он должен выполнить, чтобы решить свою проблему.
Что же мы делали дальше? Наша команда, очевидно, хотела поделиться своими открытиями с заинтересованными сторонами. Мы сменили приоритеты первоначальных целей исследования и вместо них решили рассказать об обнаруженном явлении и его масштабах, его последствиях для компании, а также показать новую предлагаемую структуру клиентского опыта. Мы начали ходить от одной двери к другой, делясь этой историей с различными заинтересованными сторонами, исследователями данных, продакт-менеджерами и дизайнерами. В основном мы получали положительные реакции, выражающие готовность перейти на предложенные клиентоориентированные определения и измерения. Глядя на многочисленную поддержку данного явления и его последствия, продолжить исследование было весьма убедительным аргументом. Но в то время как поддержка увеличивалась, то, о чем мы просили, требовало больших вложений ресурсов. Нам нужно было изменить способ отслеживания данных, показатели, внутренние процессы, и только высшее руководство могло принять окончательное решение. Пришло время встретиться с руководством заинтересованных сторон.
Мы совершенствуем нашу историю и надеемся получить поддержку. Но нам говорят, что система обработки заявок отлично подходят для данных операций. С точки зрения внутренних процессов и эффективности, в чем же выгода для компании от перехода на эту новую систему? Заинтересованные стороны понимали проблему и ее последствия, но для них этого было недостаточно, чтобы оправдать высокие затраты компании из-за перехода на клиентоориентированную систему. Тогда наша исследовательская группа поняла основную ошибку данной идеи. Мы думали, что предоставили веские аргументы и доказательства существующей проблемы, разъяснили последствия перехода и даже разработали пути решения, но мы совершенно забыли, какая была основная цель, а также о том, что действительно заботило руководство заинтересованных сторон. Это было создание потока данных от службы поддержки к техническому отделу и отделу управления продуктом. Они заботились о том, чтобы понять проблемы клиентов, их основные причины и предотвратить их возникновение. Они заботились о снижении нагрузки на службу поддержки и затратах компании. И тут мы, просим их увеличить расходы на исследования в области обслуживания клиентов и даже не можем достичь ни одной из поставленных задач. Хотя мы и выявили проблему и разъяснили ее влияние, мы не предъявили ту самую ценность, которая перевешивала бы затраты на переход к новой системе.
Наконец, мы предложили способы концентрации и измерения усилий клиентов. Это важно, поскольку усилия клиентов могут сыграть определенную роль в их удовлетворенности и лояльности. Хочу напомнить, что усилия клиента – это работа, которую он должен выполнить, чтобы решить свою проблему.
Что же мы делали дальше? Наша команда, очевидно, хотела поделиться своими открытиями с заинтересованными сторонами. Мы сменили приоритеты первоначальных целей исследования и вместо них решили рассказать об обнаруженном явлении и его масштабах, его последствиях для компании, а также показать новую предлагаемую структуру клиентского опыта. Мы начали ходить от одной двери к другой, делясь этой историей с различными заинтересованными сторонами, исследователями данных, продакт-менеджерами и дизайнерами. В основном мы получали положительные реакции, выражающие готовность перейти на предложенные клиентоориентированные определения и измерения. Глядя на многочисленную поддержку данного явления и его последствия, продолжить исследование было весьма убедительным аргументом. Но в то время как поддержка увеличивалась, то, о чем мы просили, требовало больших вложений ресурсов. Нам нужно было изменить способ отслеживания данных, показатели, внутренние процессы, и только высшее руководство могло принять окончательное решение. Пришло время встретиться с руководством заинтересованных сторон.
Мы совершенствуем нашу историю и надеемся получить поддержку. Но нам говорят, что система обработки заявок отлично подходят для данных операций. С точки зрения внутренних процессов и эффективности, в чем же выгода для компании от перехода на эту новую систему? Заинтересованные стороны понимали проблему и ее последствия, но для них этого было недостаточно, чтобы оправдать высокие затраты компании из-за перехода на клиентоориентированную систему. Тогда наша исследовательская группа поняла основную ошибку данной идеи. Мы думали, что предоставили веские аргументы и доказательства существующей проблемы, разъяснили последствия перехода и даже разработали пути решения, но мы совершенно забыли, какая была основная цель, а также о том, что действительно заботило руководство заинтересованных сторон. Это было создание потока данных от службы поддержки к техническому отделу и отделу управления продуктом. Они заботились о том, чтобы понять проблемы клиентов, их основные причины и предотвратить их возникновение. Они заботились о снижении нагрузки на службу поддержки и затратах компании. И тут мы, просим их увеличить расходы на исследования в области обслуживания клиентов и даже не можем достичь ни одной из поставленных задач. Хотя мы и выявили проблему и разъяснили ее влияние, мы не предъявили ту самую ценность, которая перевешивала бы затраты на переход к новой системе.
Мы осознали, что для получения поддержки от руководства заинтересованных сторон, нам нужно сделать шаг назад и сосредоточиться на первоначальных целях исследования. Вместо того, чтобы фокусироваться на проблеме с заявками, мы должны заострить свое внимание на ценности, которую может принести клиентоориентированное измерение, какие новые знания могут получить заинтересованные стороны, и как эти знания помогут достичь бизнес-целей, которые действительно их волновали.
Мы вернулись к «добыче золота», чтобы начать анализировать данные о проблемах клиентов. Основываясь на нашей системе, мы уже определили, какие проблемы возникали у клиентов, но нам все еще не хватало их первопричин, поэтому мы хотели выяснить, как мы можем добраться до этих первопричин и рекомендаций о том, как предотвратить проблемы клиентов. Когда мы думали о том, как же определить, когда проблема клиента считается решенной, мы заметили, что клиенты не всегда могут получить то, о чем просят службу поддержки. Они могут не достичь своих целей. Например, служба поддержки может согласиться вернуть деньги одному клиенту, а другому отказать. Почему? Возможно, потому что второй клиент не имел права на возврат средств, поскольку пропустил свой рейс. Это заставило нас задуматься: как же мы можем узнать, имеет ли клиент право на возврат? Благодаря этому вопросу моя исследовательская группа захотела лучше понять работу агентов службы поддержки. Как они это определяют? Мы начали наблюдать за несколькими агентами службы поддержки и задавать им многочисленные вопросы. В результате этого исследования нам удалось определить несколько новых переменных, которые представляли работу, выполняемую агентами, и, объединив эти переменные с уже полученными нами ранее, мы создали модель первопричин проблем клиентов.
Мы определили, что существует шесть первопричин, которые могут объяснить все возникающие проблемы клиентов в контексте нашей компании. Мы, по сути, создали своего рода формулу, по которой можно автоматически определить первопричину, отслеживая определенные данные. Мы разработали рекомендации о том, как устранить эти первопричины, чтобы предотвратить возникновение проблемы. К сожалению, я не могу раскрыть вам все детали нашей модели из соображений конфиденциальности, но хочу дать вам о ней некоторое представление. Например, если клиент обращается в службу поддержки с просьбой о возврате средств, когда он пропустил свой рейс, основная причина этой проблемы кроется в несоответствующих ожиданиях. Клиент ожидает получить возврат, когда по нашим правилам он не может его получить. Чтобы предотвратить возникновение данной проблемы, нужно сосредоточиться на корректировке ожиданий клиентов. Например, мы можем отправить клиенту электронное письмо, информирующее его о пропущенном рейсе и подчеркивающее, что возврат средств будет невозможен. В качестве альтернативы, мы, как компания, также можем прислушаться к ожиданиям клиента и на их основе скорректировать наши правила. В таком случае, если человек пропустил рейс, мы сможем предложить компенсацию или что-то подобное. Наконец, если нам не удастся предотвратить возникновение проблемы у клиента, мы можем, по крайней мере, рассмотреть способы снижения нагрузки на службу поддержки. Например, мы можем создать интеллектуальную систему маршрутизации, в которой данный тип проблемы не будет направляться агенту службы поддержки, а вместо этого будет перенаправлен в раздел самообслуживания, где клиенту объяснят, почему он не имеет права на возврат. Это всего лишь один пример первопричины и рекомендации по ее предотвращению.
Мы определили, что существует шесть первопричин, которые могут объяснить все возникающие проблемы клиентов в контексте нашей компании. Мы, по сути, создали своего рода формулу, по которой можно автоматически определить первопричину, отслеживая определенные данные. Мы разработали рекомендации о том, как устранить эти первопричины, чтобы предотвратить возникновение проблемы. К сожалению, я не могу раскрыть вам все детали нашей модели из соображений конфиденциальности, но хочу дать вам о ней некоторое представление. Например, если клиент обращается в службу поддержки с просьбой о возврате средств, когда он пропустил свой рейс, основная причина этой проблемы кроется в несоответствующих ожиданиях. Клиент ожидает получить возврат, когда по нашим правилам он не может его получить. Чтобы предотвратить возникновение данной проблемы, нужно сосредоточиться на корректировке ожиданий клиентов. Например, мы можем отправить клиенту электронное письмо, информирующее его о пропущенном рейсе и подчеркивающее, что возврат средств будет невозможен. В качестве альтернативы, мы, как компания, также можем прислушаться к ожиданиям клиента и на их основе скорректировать наши правила. В таком случае, если человек пропустил рейс, мы сможем предложить компенсацию или что-то подобное. Наконец, если нам не удастся предотвратить возникновение проблемы у клиента, мы можем, по крайней мере, рассмотреть способы снижения нагрузки на службу поддержки. Например, мы можем создать интеллектуальную систему маршрутизации, в которой данный тип проблемы не будет направляться агенту службы поддержки, а вместо этого будет перенаправлен в раздел самообслуживания, где клиенту объяснят, почему он не имеет права на возврат. Это всего лишь один пример первопричины и рекомендации по ее предотвращению.
Теперь, когда мы создали эту модель и у нас появилось представление о первопричинах возникновения проблем у клиентов и их предотвращении, наша команда, наконец, смогла выполнить то, что обещала. Пришло время для еще одной встречи с руководством заинтересованных сторон. На этот раз мы изменили нашу историю, чтобы сосредоточиться на демонстрации ценности потока данных. Мы не только продемонстрировали, с какими проблемами сталкивались клиенты, но также разбили их по первопричинам и количественно оценили возможность их предотвращения. Мы показали, как созданная нами клиентоориентированная структура позволила получить новые знания. И на этот раз мы предложили перейти на нашу систему измерений не для того, чтобы быть более клиентоориентированными или иметь лучшие КПЭ, а потому, что это позволило достичь поставленных задач, создать поток данных, предотвратить проблемы клиентов и, в конечном итоге, снизить затраты компании на службу поддержки.
Новая история сработала. Нас спросили, что нам потребуется для воплощения данной системы. Мы очень скромно попросили предоставить дополнительные ресурсы для тестирования нашей структуры, а также чтобы убедиться, что наша классификация надежна и применима в любой ситуации в данном контексте. Мы попросили и о финансовой поддержке для создания этой системы измерения. Однако мы ничего не получили на этой встрече, невозможно добиться всего сразу. Тем не менее, через некоторое время компания официально признала проблему с уже существующими измерениями и создала команду, которая будет работать над внедрением новых клиентоориентированных измерений. Наша исследовательская группа получила место в этой команде. Далее мы продолжили совершенствовать систему измерения клиентского опыта и уже созданные нами классификации до тех пор, пока они не стали достаточно надежными. Мы также сотрудничали с командой внедрения, чтобы определить новые требования к системе обработки заявок, и работали с исследователями и аналитиками данных, чтобы количественно оценить данное явление и приобрести дополнительное сотрудничество. Но то, что произошло дальше, – уже совершенно другая история.
Так что же можно вынести из этой истории?
Во-первых, следуйте за данными и смотрите, куда они вас приведут. Иногда отклонение от первоначальной цели стоит того. Хотя и есть риск невыполнения цели, благодаря этому вы можете получить новые знания и возможности.
Во-вторых, не забывайте, что очень простые вещи и общепринятые показатели могут оказаться не такими уж логичными, как только вы начнете их изучать. Не принимайте их как должное.
В-третьих, объясните, какие последствия ждут компанию. Количественная оценка тех или иных последствий иногда может быть мощным инструментом для убеждения руководства заинтересованных сторон.
В-четвертых, создавайте структуры или модели данных. Определите соответствующие концепции, установите их взаимосвязь, и создайте для них базовую структуру. В долгосрочной перспективе это поможет вам накапливать знания и позже опираться на них при исследовании.
В-пятых, продемонстрируйте ценность вашего исследования, помогая заинтересованным сторонам достичь их целей. Выясните, что их волнует, и на этой основе скорректируйте свою историю. Если вы просите о чем-то у заинтересованных сторон, покажите, что они могут от этого получить и как это может помочь им достичь целей. Если вы не сможете этого сделать, то, по крайней мере, в реалиях UX, это может привести к тому, что ваш проект и идеи будут отложены далеко и надолго.
Во-первых, следуйте за данными и смотрите, куда они вас приведут. Иногда отклонение от первоначальной цели стоит того. Хотя и есть риск невыполнения цели, благодаря этому вы можете получить новые знания и возможности.
Во-вторых, не забывайте, что очень простые вещи и общепринятые показатели могут оказаться не такими уж логичными, как только вы начнете их изучать. Не принимайте их как должное.
В-третьих, объясните, какие последствия ждут компанию. Количественная оценка тех или иных последствий иногда может быть мощным инструментом для убеждения руководства заинтересованных сторон.
В-четвертых, создавайте структуры или модели данных. Определите соответствующие концепции, установите их взаимосвязь, и создайте для них базовую структуру. В долгосрочной перспективе это поможет вам накапливать знания и позже опираться на них при исследовании.
В-пятых, продемонстрируйте ценность вашего исследования, помогая заинтересованным сторонам достичь их целей. Выясните, что их волнует, и на этой основе скорректируйте свою историю. Если вы просите о чем-то у заинтересованных сторон, покажите, что они могут от этого получить и как это может помочь им достичь целей. Если вы не сможете этого сделать, то, по крайней мере, в реалиях UX, это может привести к тому, что ваш проект и идеи будут отложены далеко и надолго.
И, наконец, не бойтесь расширять границы. Выходите за рамки традиционных исследований и включите исследование в области обслуживания клиентов в свою практику. Выходите за рамки ожидаемого. Этот проект не совсем соответствует описанию работы UX-исследователя. Было ли это вообще UX-исследование? Но как исследователи мы можем помочь в создании определений и измерений, мы можем помочь создать классификацию данных, поскольку все это требует понимания человеческого поведения и опыта. Компания не всегда знает, что ей нужно, и руководство может не знать о потенциале исследований или других проектов, над которыми вы работаете. Вам самим нужно прокладывать себе путь. И самое главное, сосредоточьтесь на клиентах, а не на заявках! Спасибо!
Модератор: Отличная концовка, прекрасная презентация. На самом деле, это была действительно потрясающая информация. Большое спасибо. У нас есть один вопрос от аудитории. Каков наилучший способ сбора и обработки количественных данных? Как их преобразовать в понятную информацию или набор данных? Можете порекомендовать конкретные приложения или сервисы?
Анна Ефименко: Прошу прощения, вы сказали качественные или количественные?
Модератор: Количественные, да.
Анна Ефименко: У нас несколько вопросов, поэтому мне нужно хорошенько их обдумать. Начнем с первого.
Модератор: Я могу повторить первый вопрос.
Анна Ефименко: Спасибо.
Модератор: Каков наилучший способ сбора и обработки количественных данных?
Анна Ефименко: Должна сказать, что есть люди, специализирующиеся в определенных областях. Поэтому, если в вашей организации есть исследователь или аналитик данных, обратитесь к нему, я думаю, он сможет лучше ответить на данный вопрос. Я отношу себя к исследователям, использующим смешанные методы, но моя сильная сторона заключается в качественных исследованиях, поэтому я часто сотрудничаю с исследователями и аналитиками данных, чтобы попытаться понять, как мы можем объединить наши точки зрения. Конечно, я также работаю и с количественными данными, но я бы посоветовала обратиться к специалистам, чтобы получить корректный ответ на данный вопрос. Но лично я считаю, что все начинается с определения предмета вашего изучения, ваших целей и результата, которого вы хотите достичь. Так, например, если вы пытаетесь использовать данные службы поддержки, чтобы лучше понять какую-то информацию о ваших клиентах, у вас возникнут некоторые вопросы по типу: на каком этапе пути объем работы в службе поддержки возрастает? Таким образом, вам нужно определить предмет изучения, и прежде всего просмотреть, какие данные уже доступны, как они структурированы и насколько легко их обобщить.
Процесс очистки и реструктуризации данных очень трудоемкий и я думаю, многое зависит от инфраструктуры данных и сервисов, которые использует ваша компания. Поэтому немного сложно рекомендовать конкретный сервис. В нашем случае мы в основном использовали Excel (наш набор данных был действительно очень простым). Своего рода старая школа, поскольку мы не имели дело, скажем, с миллионами данных. Наша компания отслеживала данные, естественно, в наших собственных наборах данных, а мы создали своего рода их качественный набор. Несмотря на то, что у нас была довольно большая выборка, в итоге мы проанализировали около 3 000 заявок, чтобы получить количественную оценку. В каком-то смысле анализ стал количественным, однако мы использовали Excel, и было довольно легко структурировать каждую переменную, отслеживать ее, иметь заранее определенное значение, а затем легко запускать любые статистические сводки или анализы, которые мы хотели. Конечно же, если нам нужен был более глубокий анализ, то мы сотрудничали с аналитиками данных, которые использовали наш набор данных и соединяли его с уже имеющимся. Мы сохраняли уникальные идентификаторы, связанные с клиентами, так что на основе этого мы всегда могли связать данные, которые мы создали, и отследить их в нашем наборе данных с теми, которые компания уже отслеживала, чтобы провести дополнительный анализ. Я не уверена, смогла ли ответить на ваш вопрос. Дайте мне знать.
Модератор: Я надеюсь, что вы ответили на данный вопрос. Это был полный ответ или нам следует ответить и на оставшиеся три вопроса? Можете порекомендовать конкретные приложения или сервисы?
Анна Ефименко: Как я уже говорила, в моем случае я использую Excel или Google Sheets, но последним пользуюсь уже больше как UX-исследователь. Если вы работаете с большим набором количественных данных, вы, вероятно, работаете с языками программирования и инфраструктурой данных, которые использует ваша компания, поэтому в данном случае я бы не рекомендовала упомянутые ранее сервисы. Все действительно зависит от вашей компании.
Модератор: Большое спасибо за ответ. Тот же пользователь что-то печатает, но думаю, это просто благодарность за ответ. У нас пока больше нет вопросов, поэтому хочу задать один от себя. Возможно, вы можете порекомендовать какую-нибудь литературу, статьи в интернете, твиттер-аккаунты или любые другие источники информации по данной теме для тех, кто хочет глубже ее изучить?
Анна Ефименко: Я не сижу в Твиттере. Я имею ввиду, что он у меня есть, но я редко туда захожу. Я думаю, рекомендация зависит от того, какой аспект вас интересует и что вы хотите изучить. Кажется, у меня был слайд с предложенной литературой. В любом случае, все зависит от данных вашей компании. Конечно, если вы подойдете ко мне пообщаться, я охотно поделюсь с вами нашими открытиями, выявленными проблемами, классификациями и первопричинами, но возможно, у вас в компании совершенно другая структура работы в отделе обслуживания клиентов и совершенно другие задачи. Поэтому то, что делала я, возможно, не сильно вам поможет, однако, может вас вдохновить, но я все же считаю, что вам следует изучить то, чем занимается ваша компания, что ее волнует, какие цели она преследует. Взгляните на данные из службы поддержки, изучите, что это за данные, как их отслеживают и отслеживают ли вообще, если нет, то отправляйтесь прямиком в службу поддержки и наблюдайте за их работой.
Это своего рода отправная точка, но литература, что я представила на слайде, – это книга по картированию опыта («Путь клиента» Джим Калбах). Мне она очень нравится. В ней много разных подходов. Книга может заставить вас задуматься о том, как визуализировать вещи, но для нас это было еще не столько о визуализации, сколько о различных понятиях или переменных, которые вы сможете найти в каждом аспекте и с разной точки зрения. Я очень рекомендую данную книгу.
В какой-то момент наша команда обратилась к научной литературе, к сожалению, я не смогу сказать вам точное название ресурсов, однако мы изучили достаточно литературы, чтобы понять поведение агентов службы поддержки и то, как оно связано с показателями, которыми располагает компания. Это оказалось весьма полезно, кроме того, мы узнали из научной литературы, что существуют определенные формы поведения агентов службы поддержки, поскольку организационные показатели их к этому и побуждают. Для нас это было довольно интересно, но я не уверена, насколько данный способ подойдет в вашей ситуации.
Как правило, на данный момент существует не так много информации или ресурсов об исследованиях в области обслуживания клиентов. Это все еще довольно новая тема, и многие компании еще не осознали ценность информации, которую может предложить служба поддержки. Обычно служба поддержки – совершенно другой отдел. Если это другой отдел, то он обособлен от остальных, и сотрудники не общаются между собой, а данные находятся в другой инфраструктуре. Задумайтесь об этом, попробуйте обратиться к кому-нибудь из службы поддержки, попробуйте узнать, получите ли вы оттуда какую-либо ценную информацию, прежде чем обращаться к внешним ресурсам и тому подобному. Я уверена, что через 10 лет будет гораздо больше литературы, посвященной исследованиям в области обслуживания клиентов.
Также мы занимались более традиционными UX-исследованиями и исследованиями в области обслуживания клиентов, мы проводили юзабилити-тесты и опросы, проверяли поток данных службы поддержки, способы самообслуживания, приложения для обмена сообщениями и даже то, как клиенты решают проблемы. Это еще один доступный вариант для каждого. Возможно, ваша компания запускает новый продукт, и каким-то образом вы видите, что этот продукт порождает возникновение большого объема работы для отдела обслуживания клиентов. Возможно, вы не из отдела обслуживания клиентов, вы из технического или UX-отдела, но этот объем данных уже должен вызывать вопросы о происходящем. Обычно технический отдел и отдел управления продуктом не заботятся о подобном, поскольку обслуживание клиентов не входит в их компетенцию, они не получат за это надбавку. Но если бы это действительно оплачивалось, например, как много пользы приносит ваш продукт, сколько проблем он создает для компании и насколько он затратен, то я полагаю, все бы заботились об этом гораздо больше, чем сейчас.
Модератор: На самом деле приятно слышать, что эта тема довольно новая, поскольку сегодня у нас много разговоров об UX-исследованиях и обо всем, что с ними связано. Было интересно послушать. Я бы сказала, что в основном ваше исследование содержит больше практики и меньше теории. Посмотрим, что будет дальше. Последний вопрос. Аудитория просит вас поделиться своими контактами в Facebook, LinkedIn и группой в Telegram. Если можете, то просто отправьте их мне.
Анна Ефименко: Конечно, я обязательно поделюсь. Не стесняйтесь писать мне в LinkedIn. Facebook я использую очень редко, поэтому пишите мне в LinkedIn на русском, на английском, на румынском, на любом языке. Там доступны разные языки. Буду рада познакомиться с вами, поболтать на эту или другие темы, UX-исследования, все что угодно. До встречи!
Анна Ефименко: Прошу прощения, вы сказали качественные или количественные?
Модератор: Количественные, да.
Анна Ефименко: У нас несколько вопросов, поэтому мне нужно хорошенько их обдумать. Начнем с первого.
Модератор: Я могу повторить первый вопрос.
Анна Ефименко: Спасибо.
Модератор: Каков наилучший способ сбора и обработки количественных данных?
Анна Ефименко: Должна сказать, что есть люди, специализирующиеся в определенных областях. Поэтому, если в вашей организации есть исследователь или аналитик данных, обратитесь к нему, я думаю, он сможет лучше ответить на данный вопрос. Я отношу себя к исследователям, использующим смешанные методы, но моя сильная сторона заключается в качественных исследованиях, поэтому я часто сотрудничаю с исследователями и аналитиками данных, чтобы попытаться понять, как мы можем объединить наши точки зрения. Конечно, я также работаю и с количественными данными, но я бы посоветовала обратиться к специалистам, чтобы получить корректный ответ на данный вопрос. Но лично я считаю, что все начинается с определения предмета вашего изучения, ваших целей и результата, которого вы хотите достичь. Так, например, если вы пытаетесь использовать данные службы поддержки, чтобы лучше понять какую-то информацию о ваших клиентах, у вас возникнут некоторые вопросы по типу: на каком этапе пути объем работы в службе поддержки возрастает? Таким образом, вам нужно определить предмет изучения, и прежде всего просмотреть, какие данные уже доступны, как они структурированы и насколько легко их обобщить.
Процесс очистки и реструктуризации данных очень трудоемкий и я думаю, многое зависит от инфраструктуры данных и сервисов, которые использует ваша компания. Поэтому немного сложно рекомендовать конкретный сервис. В нашем случае мы в основном использовали Excel (наш набор данных был действительно очень простым). Своего рода старая школа, поскольку мы не имели дело, скажем, с миллионами данных. Наша компания отслеживала данные, естественно, в наших собственных наборах данных, а мы создали своего рода их качественный набор. Несмотря на то, что у нас была довольно большая выборка, в итоге мы проанализировали около 3 000 заявок, чтобы получить количественную оценку. В каком-то смысле анализ стал количественным, однако мы использовали Excel, и было довольно легко структурировать каждую переменную, отслеживать ее, иметь заранее определенное значение, а затем легко запускать любые статистические сводки или анализы, которые мы хотели. Конечно же, если нам нужен был более глубокий анализ, то мы сотрудничали с аналитиками данных, которые использовали наш набор данных и соединяли его с уже имеющимся. Мы сохраняли уникальные идентификаторы, связанные с клиентами, так что на основе этого мы всегда могли связать данные, которые мы создали, и отследить их в нашем наборе данных с теми, которые компания уже отслеживала, чтобы провести дополнительный анализ. Я не уверена, смогла ли ответить на ваш вопрос. Дайте мне знать.
Модератор: Я надеюсь, что вы ответили на данный вопрос. Это был полный ответ или нам следует ответить и на оставшиеся три вопроса? Можете порекомендовать конкретные приложения или сервисы?
Анна Ефименко: Как я уже говорила, в моем случае я использую Excel или Google Sheets, но последним пользуюсь уже больше как UX-исследователь. Если вы работаете с большим набором количественных данных, вы, вероятно, работаете с языками программирования и инфраструктурой данных, которые использует ваша компания, поэтому в данном случае я бы не рекомендовала упомянутые ранее сервисы. Все действительно зависит от вашей компании.
Модератор: Большое спасибо за ответ. Тот же пользователь что-то печатает, но думаю, это просто благодарность за ответ. У нас пока больше нет вопросов, поэтому хочу задать один от себя. Возможно, вы можете порекомендовать какую-нибудь литературу, статьи в интернете, твиттер-аккаунты или любые другие источники информации по данной теме для тех, кто хочет глубже ее изучить?
Анна Ефименко: Я не сижу в Твиттере. Я имею ввиду, что он у меня есть, но я редко туда захожу. Я думаю, рекомендация зависит от того, какой аспект вас интересует и что вы хотите изучить. Кажется, у меня был слайд с предложенной литературой. В любом случае, все зависит от данных вашей компании. Конечно, если вы подойдете ко мне пообщаться, я охотно поделюсь с вами нашими открытиями, выявленными проблемами, классификациями и первопричинами, но возможно, у вас в компании совершенно другая структура работы в отделе обслуживания клиентов и совершенно другие задачи. Поэтому то, что делала я, возможно, не сильно вам поможет, однако, может вас вдохновить, но я все же считаю, что вам следует изучить то, чем занимается ваша компания, что ее волнует, какие цели она преследует. Взгляните на данные из службы поддержки, изучите, что это за данные, как их отслеживают и отслеживают ли вообще, если нет, то отправляйтесь прямиком в службу поддержки и наблюдайте за их работой.
Это своего рода отправная точка, но литература, что я представила на слайде, – это книга по картированию опыта («Путь клиента» Джим Калбах). Мне она очень нравится. В ней много разных подходов. Книга может заставить вас задуматься о том, как визуализировать вещи, но для нас это было еще не столько о визуализации, сколько о различных понятиях или переменных, которые вы сможете найти в каждом аспекте и с разной точки зрения. Я очень рекомендую данную книгу.
В какой-то момент наша команда обратилась к научной литературе, к сожалению, я не смогу сказать вам точное название ресурсов, однако мы изучили достаточно литературы, чтобы понять поведение агентов службы поддержки и то, как оно связано с показателями, которыми располагает компания. Это оказалось весьма полезно, кроме того, мы узнали из научной литературы, что существуют определенные формы поведения агентов службы поддержки, поскольку организационные показатели их к этому и побуждают. Для нас это было довольно интересно, но я не уверена, насколько данный способ подойдет в вашей ситуации.
Как правило, на данный момент существует не так много информации или ресурсов об исследованиях в области обслуживания клиентов. Это все еще довольно новая тема, и многие компании еще не осознали ценность информации, которую может предложить служба поддержки. Обычно служба поддержки – совершенно другой отдел. Если это другой отдел, то он обособлен от остальных, и сотрудники не общаются между собой, а данные находятся в другой инфраструктуре. Задумайтесь об этом, попробуйте обратиться к кому-нибудь из службы поддержки, попробуйте узнать, получите ли вы оттуда какую-либо ценную информацию, прежде чем обращаться к внешним ресурсам и тому подобному. Я уверена, что через 10 лет будет гораздо больше литературы, посвященной исследованиям в области обслуживания клиентов.
Также мы занимались более традиционными UX-исследованиями и исследованиями в области обслуживания клиентов, мы проводили юзабилити-тесты и опросы, проверяли поток данных службы поддержки, способы самообслуживания, приложения для обмена сообщениями и даже то, как клиенты решают проблемы. Это еще один доступный вариант для каждого. Возможно, ваша компания запускает новый продукт, и каким-то образом вы видите, что этот продукт порождает возникновение большого объема работы для отдела обслуживания клиентов. Возможно, вы не из отдела обслуживания клиентов, вы из технического или UX-отдела, но этот объем данных уже должен вызывать вопросы о происходящем. Обычно технический отдел и отдел управления продуктом не заботятся о подобном, поскольку обслуживание клиентов не входит в их компетенцию, они не получат за это надбавку. Но если бы это действительно оплачивалось, например, как много пользы приносит ваш продукт, сколько проблем он создает для компании и насколько он затратен, то я полагаю, все бы заботились об этом гораздо больше, чем сейчас.
Модератор: На самом деле приятно слышать, что эта тема довольно новая, поскольку сегодня у нас много разговоров об UX-исследованиях и обо всем, что с ними связано. Было интересно послушать. Я бы сказала, что в основном ваше исследование содержит больше практики и меньше теории. Посмотрим, что будет дальше. Последний вопрос. Аудитория просит вас поделиться своими контактами в Facebook, LinkedIn и группой в Telegram. Если можете, то просто отправьте их мне.
Анна Ефименко: Конечно, я обязательно поделюсь. Не стесняйтесь писать мне в LinkedIn. Facebook я использую очень редко, поэтому пишите мне в LinkedIn на русском, на английском, на румынском, на любом языке. Там доступны разные языки. Буду рада познакомиться с вами, поболтать на эту или другие темы, UX-исследования, все что угодно. До встречи!
Наши контакты
E-mail: info@mymonday.by
Error get alias