Фрагментация данных – следствие двух причин. Во-первых, разным людям, группам или отделам поручают работать с клиентами по различным каналам. Во-вторых, значительная часть программного обеспечения, используемого для управления традиционными закулисными каналами, не была предназначена для того, чтобы оперативно предоставлять данные в удобном формате при публичном взаимодействии с клиентами в интернете.
Первую проблему можно решить, если иметь единую специальную группу, которая будет заниматься всеми клиентами по всем каналам. Но в большинстве случаев на практике получается иначе: формируются специальные группы для работы с социальными сетями и отдельные команды, занимающиеся телефонными звонками, электронной почтой или и тем, и другим.
Работа легендарной службы поддержки клиентов компании KLM в социальных сетях обеспечивается командой, которая занимается запросами клиентов только в социальных сетях. С запросами по телефону и электронной почте работает совершенно другая группа. Как говорит Карлин Фогель-Мейер, возглавляющая службу поддержки KLM в социальных сетях: «Мы действительно считаем, что социальные сети отличаются от других каналов. Вы можете очень хорошо отвечать по телефону, но в соцсетях нужно уметь формулировать мысли короткими предложениями. В Twitter ваш ответ может состоять лишь из ограниченного числа символов, и, решая проблему клиента, вы должны уложиться в эти рамки. Это требует специальных навыков».
Совершенно верно. Если вы прекрасно «обнимаете ненавистников», общаясь с ними по телефону, это не значит, что вы точно так же сможете «обнимать их» в социальных сетях. Но стоит ли разрабатывать программу обслуживания клиентов таким образом, чтобы в результате данные оказывались неунифицированными, а потребители – недовольными? (Это не относится к компании KLM, в которой используется хорошая программа унификации данных.)
Вторую проблему (программное обеспечение, не настроенное на обработку всех новых каналов вместе со старыми) решить труднее, хотя такие компании, как Aspect, Salesforce, Parature, Thunderhead, HP и Clarabridge, прилагают все усилия для того, чтобы программы легко работали с данными из разных источников. Но это сложная проблема, связанная с самой структурой базы данных, где обязательно должна быть «главная» запись, которая идентифицирует каждого клиента. В современном мире, где имеются как закулисные каналы взаимодействия, так и публичные, назначать тот или иной канал главным – далеко не такой очевидный шаг, как раньше.
«Проблема заключается не в отсутствии данных – их-то мы собираем, – говорит Эстебан Кольский. – Но у нас нет общей модели данных или хранилища, где бы все они накапливались. Поэтому, если вы придете в Facebook, то я соберу ваши данные и помещу их в базу, но сотрудники, занимающиеся телефонными звонками, не смогут получить к ним доступ. И даже если им это удастся, они не поймут эти данные, потому что у них не тот формат, к которому они привыкли, или там будет информация, отличающаяся от имеющихся у них сведений. Подобное несоответствие вызвано отсутствием общей модели данных… Если вы посмотрите на то, как с данными работают программные платформы, то увидите, что там имеется своя модель – например, существует общий идентификационный номер клиента, есть общая проблема, есть поле общих решений и тому подобное. В старых же системах используются свои собственные способы управления данными. Если вы хотите перенести старые системы в современное облачное хранилище данных, вы должны настроить модель таким образом, чтобы она действовала в облачном хранилище».