Комплексная техническая поддержка для клиентов Braze

Одной из первых встреч, на которых я присутствовал этим летом в качестве стажера Braze, было обсуждение программного обеспечения под названием Mavenlink. Члены группы Braze Integrations and Onboarding начали использовать Mavenlink для отслеживания времени и задач, необходимых для интеграции нового клиента в их платформу. Во время этой встречи команда описала несколько первых трудностей, с которыми они столкнулись при использовании Mavenlink. Общим отзывом было то, сколько времени ушло на настройку списка задач в соответствии с конкретным планом интеграции клиента. Учитывая, насколько занята команда адаптации в Braze, мне сразу стало ясно, что Mavenlink будет работать только в том случае, если мы сможем исключить большую часть, если не все, ручного ввода, требуемого пользователем.

Чтобы получить полное представление о технической адаптации, необходимой для клиента, и о том, где Mavenlink вступит в игру, я побеседовал с несколькими членами команды Braze. Они объяснили основные этапы процесса:

  1. Вручную просмотрите информацию от клиента о том, какие платформы SDK, каналы обмена сообщениями и другие функции Braze они хотели использовать для обмена сообщениями с клиентами.
  2. Просмотрите основной список задач, хранящийся в Google Таблицах, со ссылками на ресурсы, которые потребуются клиенту для выполнения соответствующих задач.
  3. Составьте длинное подробное электронное письмо с изложением задач, необходимых для полной технической интеграции с продуктом Braze, для отправки клиенту.

Это казалось очень трудоемким, и добавление 30 минут к часу ввода задач в Mavenlink было явно невозможным.

План игры

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

Чтобы понять, какие задачи потребуются для интеграции клиентов, я работал с командой адаптации клиентов, чтобы проанализировать ресурсы, которые они используют для адаптации клиентов в масштабе. Это был первый раз, когда я увидел главный список задач, или «библию задач», которая представляла собой огромную таблицу Google со списком всех задач, с которыми клиент может столкнуться.

Используя этот список задач, мы работали в обратном направлении, чтобы определить, какие вопросы нам нужно задать, чтобы решить, что представить клиенту. Мы хотели, чтобы количество вопросов было как можно меньше. В конце дня мы подготовили краткий опрос с помощью инструмента опроса GetFeedback. Клиенты получат опрос при входе в Braze, а результаты будут зарегистрированы в экземпляре Braze Salesforce.

На данный момент у меня был примерный список сервисов, которые я буду использовать для процесса автоматизации:

  • GetFeedback для опроса клиентов по технической интеграции, чтобы узнать, что клиент хотел сделать с Braze
  • Таблицы Google для основного списка задач с прикрепленным скриптом Google Apps для создания задач в Mavenlink.
  • Google Slides с прикрепленным скриптом Google Apps для создания индивидуальной презентации для клиента в качестве замены электронной почты с оценкой задачи.

Соединяем это вместе

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

Первым препятствием, с которым я столкнулся, было получение данных от Salesforce с использованием исходящего веб-перехватчика. Веб-перехватчик Salesforce бесконечно отправлял полезные данные, потому что не получал подтверждения от моего сценария о получении полезных данных. Когда я закодировал подтверждение веб-перехватчика в своем сценарии, он окончательно отключил веб-перехватчик, а Salesforce прекратила отправку данных для последующих отправок опросов. Исправление, предложенное администратором Salesforce Braze, заключалось в том, чтобы использовать Zapier в качестве моста. Благодаря встроенному в Zapier подключению к Salesforce мне не нужно было беспокоиться о подтверждениях. Первые несколько цепочек в процессе автоматизации теперь были связаны и работали.

Следующим шагом было создание скрипта для создания клиентских задач. Я использовал редактор сценариев, встроенный в основной список задач Google Sheet. Он получал полезную нагрузку данных от веб-хука Zapier, но ничего не делал с данными. Я создал систему «тегов» для каждой задачи на листе, чтобы связать каждую задачу с конкретными ответами на вопросы опроса. Например, если клиент выбрал iOS в качестве платформы и mParticle для данных о клиенте, то я хотел бы сгенерировать задачу на листе под названием «Настройка и интеграция mParticle для iOS». Затем я провел много часов, просматривая документацию по API Mavenlink и тестируя методы в Postman, чтобы понять, как я буду создавать задачи. В конце концов, я использовал последовательность вызовов API для создания задач, а также их подзадач в Mavenlink, используя имена и теги, присутствующие в мастер-листе.

Здесь я столкнулся с десятками препятствий, в частности, с тем, что вы не можете регистрировать данные из скрипта Google Apps, который используется в качестве внешнего веб-приложения. Я нашел инструмент под названием BetterLog и создал отдельный лист для ведения журнала и отладки. В целом, программирование скрипта генерации задач заняло десятки часов, множество проб и ошибок и частые разговоры с членами команды Onboarding, чтобы убедиться, что задачи генерируются правильно. Но после завершения сценария генерации задачи клиент может отправить технический опрос GetFeedback по адаптации, результат опроса будет зарегистрирован в Salesforce как объект, Salesforce передаст данные объекта через веб-перехват в Zapier, Zapier перехватит полезные данные через веб-приложение к моему сценарию, мой сценарий будет анализировать основной список задач и, используя систему тегов, генерировать задачи в Mavenlink через вызовы API. Я приближался!

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

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

Уроки выучены

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

  • Построение и тестирование каждой цепи по отдельности имеет первостепенное значение. Мой менеджер посоветовал мне тщательно протестировать каждую часть, прежде чем переходить к следующей. Это сделало процесс сборки на всем протяжении, и особенно в конце, значительно более управляемым.
  • Очень важно постоянно общаться с людьми, с которыми вы работаете. Я часто обращался к членам команды адаптации, чтобы уточнить аспекты автоматизации, чтобы она больше соответствовала их ожиданиям.
  • Документация имеет решающее значение. Служба, которую я создал, вскоре была развернута по всему миру вместе с менеджерами Braze. Я был в восторге, но потом понял, что мне нужно убедиться, что все готово к производству. Как только я закончил записывать обучающие видеоролики, удалив сотни лишних строк кода, добавив поясняющие комментарии к своим сценариям и написав руководства для будущих модификаций процесса автоматизации, часы моей стажировки побили ноль.

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