Эпизод № 50: Как создавать отношения один на один в масштабе

Маркетологи могут многому научиться из управления программным кодом. Действительно. В нашем первом выпуске 2021 года мы рассмотрим, как использовать проверенные концепции DevOps, чтобы автоматизировать реальные взаимоотношения с нашими клиентами 1:1. Все дело в масштабе и автоматизации — с индивидуальным подходом.

Все выпуски подкаста

Перейти сейчас

СТЕНОК ПОДКАСТА

Что ж, с Новым годом. На дворе 2021 год, и, о боже, ожидания высоки. Итак, 2021 год, давление продолжается. Я предполагаю, что 2021 год не будет сильно отличаться от 2020 года, потребуется время, чтобы проработать все, что нам нужно сделать, и будет много экономических проблем. Поэтому я не уверен, что через год 2021 год будет таким же ярким, но 2022 год будет потрясающим.

В любом случае, давайте немного поговорим о DevOps. Хм, DevOps, что такое DevOps? Итак, DevOps — это набор практик, объединяющий разработку программного обеспечения и ИТ-операции. Он направлен на сокращение жизненного цикла разработки программного обеспечения и обеспечение непрерывной поставки высококачественного программного обеспечения. Это его формальное определение. Это очень хорошо сочетается с гибкой разработкой программного обеспечения. А некоторые аспекты DevOps исходят из гибкой методологии, зародившейся в 90-х годах.

Так почему же я сегодня говорю о DevOps? Ну, это опыт CXM. И, как обычно, я Град Конн, главный исполнительный директор Sprinklr, и опыт — это новый бренд. И действительно, что такое клиентский опыт? И как у вас это получается. И я хочу поговорить об одном аспекте клиентского опыта, который меня больше всего волнует. Это, я думаю, самая сложная вещь для доставки. И я хочу провести аналогию с DevOps и тем, как развивается этот мир.

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

И поэтому они разработали набор очень интересных внутренних инструментов. И что это позволило им сделать, так это то, что они получили возможность, по сути, непрерывно интегрировать новый код, а затем непрерывно доставлять и постоянно развертывать этот новый код. Их часто называют CICD. И это эти комбинированные практики. И инструменты, которые они разработали для этого, были внутренними. Так что вы не можете просто зайти на Facebook и сказать: «Эй, можно мне воспользоваться вашим инструментом CICD?» Это то, что является собственностью и является источником значительного конкурентного преимущества для Facebook. Если кто-то помнит Friendster, то Friendster был Facebook еще до Facebook. Неудача Friendster заключалась в том, что Friendster не мог оставаться на месте, не мог оставаться на ногах, постоянно падал вниз. Итак, я был пользователем Friendster, но быстро ушел, потому что каждый раз, когда я пытался войти, серверы были заняты или он зависал.

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

Теперь есть набор инструментов, которые помогают в этом пространстве. И там куча разных фирм. Общие классы инструментов — это автоматизация доставки программного обеспечения и управление доставкой программного обеспечения. Если вы маркетолог и вам интересно, что случилось с Градом, а я ничего не понимаю из того, что он сегодня говорит, подумайте об автоматизации доставки программного обеспечения как об автоматизации маркетинга. Думайте об управлении доставкой программного обеспечения как о CRM, верно? Таким образом, управление доставкой программного обеспечения похоже на CRM-систему и помогает вам оптимизировать команды и рабочие процессы. Это позволяет вам объединять межфункциональные команды, чтобы максимизировать ценность того, что вы пытаетесь сделать. Кроме того, автоматизация доставки программного обеспечения позволяет автоматизировать и координировать работу всех различных групп, которым необходимо поставлять программное обеспечение. Потому что у вас есть тест, у вас есть код, у вас есть общие службы, команды и т. д., и все они работают вместе.

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

Ну, как мы собираемся это сделать? Как я уже говорил, я не могу просто зайти на Facebook и сказать: «Эй, могу я одолжить вашу систему CICD». Таким образом, ряд фирм начинает расти, это относительно новая отрасль, которые, по сути, создают те типы инструментов, которые используются компаниями, которые были пионерами DevOps. И они позволяют компаниям делать это самостоятельно. Итак, есть несколько довольно интересных тематических исследований, особенно из банков, банки, очевидно, должны все время не спать. И они постоянно поставляют очень качественное и очень важное программное обеспечение, потому что это ваши деньги. И у них есть тысячи разработчиков, которые делают это по всему миру, они должны это координировать. Так что такая система координации действительно впечатляет, действительно захватывающая, в совершенно новом будущем для кода.

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

И одна из вещей, которые очень интересны в работе в Sprinklr, заключается в том, что Sprinklr находится на переднем крае этой системы управления качеством обслуживания клиентов. И я бы сказал, что это один из способов думать об этом, и если вы думаете о некоторых инструментах, о которых я говорил немного ранее в DevOps, они говорят об автоматизации доставки программного обеспечения. Подумайте об автоматизации взаимодействия с клиентами, потому что единственный способ, которым вы сможете ежедневно взаимодействовать с клиентами один на один, — это автоматизировать этот процесс. Потому что вы не можете просто заставить людей делать это туда и обратно.

Недавно я провел интересный тест. Я был в Твиттере. Одна из моих любимых платформ. И мне предстоит разговор с крупным автопроизводителем. И поэтому, просто чтобы посмотреть, как все справляются с современными каналами, я сделал очень простой твит. И я просто сказал: «Привет, я думаю о покупке внедорожника до конца 2020 года. Что бы вы порекомендовали друзьям?» А затем я упомянул несколько разных брендов, около 10. Что меня поразило, так это то, что мне ответили только три из этих брендов. Один был немного дерзким, и мне пришлось с ним взаимодействовать. А тут две были вроде вот ссылки на то, что мы считаем уместным. Но очень интересно во всех этих случаях то, что это было именно так. Я получил ссылку, больше ничего не произошло. У меня никогда не было никакого продолжения. Я конкретно сказал конец 2020 года. Никто не сказал Что ты купил, ты еще думаешь, вот договор, хочешь сделать тест-драйв. Там ничего не было. Это было одно и сделано. Таким образом, это отсутствие настоящего настоящего участия означало, что я начал принимать собственные решения.

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

Довольно интересно, 2021 год будет действительно захватывающим. С нетерпением жду целую кучу действительно отличных шоу. В эту пятницу к нам приедет гость, Пол Херман, бывший сотрудник Nike и нынешний руководитель отдела маркетинга Sprinklr. Так что мы собираемся весело поговорить с ним. И мы поговорим о нашем обычном попурри из тем. Итак, на сегодня все. Увидимся в следующий раз.