Недавно ко мне обратились за консультацией коллеги из одной крупной финансовой компании со следующей задачей — организовать e-mail рассылку писем для потенциальных покупателей услуг компании, по готовой базе потенциальных подписчиков.
Как водится в корпоративном мире, для решения задачи было собрано совещание с участием представителей заинтересованных / задействованных подразделений и были выдвинуты следующие стартовые предложения:
- Подразделение оффлайн-продаж — использовать возможности корпоративной почты (Outlook).
- IT-подразделение — купить и установить софт для e-mail рассылок.
- Подразделение кросс-сейл — сейчас использовать SMS вместо e-mail и провести отдельный бизнес-анализ эффективности внедрения нового инструмента.
- Подразделение маркетинга и рекламы — тип инструмента не имеет особого значения, но он должен позволять формировать дизайн писем рассылки.
Учитывая, что собрание затянулось на добрый час, не трудно предположить, что дебаты развернулись не шуточные.
Каждое подразделение отстаивало свою точку зрения, основываясь на своей внутренней мотивации:
- для подразделения продаж важна простота и скорость организации процесса, а кроме того — быстрая возможность опробовать новый для них инструмент — проще говоря, провести пилот — и оценить его функциональность. Им некогда ждать, пока ИТ проведет анализ рынка, выберет подрядчика, проведет тендер, закупит и настроит необходимый софт.
Предложение подразделения кросс-сейла их не устраивало по двум другим причинам — во-первых, у них есть уже готовая база подписчиков и подписчики эти предоставили не телефон, а e-mail. Собрать эту базу по второму кругу конечно можно, но зачем? С другой стороны, стоимость отправки одного e-mail и стоимость отправки одной SMS с финансовой точки зрения разнятся капитально, а бюджет не резиновый. - для ИТ-подразделения ситуация иная — использовать сервера корпоративной почты для массовой отправки писем чревато попаданием в стоп-листы провайдеров, что проведет к массовым проблемам всего почтового сервиса. С другой стороны — учитывая жесткую структрированность софтверной части компании, наличие SLA под каждый продукт, актов приемки-передачи сервисов и прочих документальных моментов, брать на поддержку абы какой софт они по понятным причинам не хотели.
- для подразделения кросс-сейла — массовые e-mail рассылки являются новым инструментом, а отказываться от уже наработанной схемы работы и последующего анализа результатов всегда тяжело. С другой стороны, подразделение продаж требует быстрых и решительных действий, а отказывать “продавцам” как-то не принято.
- для подразделения маркетинга и рекламы — визуальная составляющая предложения играла (играет и будет играть — что закономерно) одну из ведущих скрипок в любом случае, поэтому если в технических вопросах они были готовы сохранять нейтралитет, то требование к гибкой визуализации письма — стало основополагающим.
Как вы понимаете, через час обсуждения, ситуация стала просто патовой — каждое из подразделений тянуло одеяло на себя, настаивая на своем выборе. И резоны каждой стороны можно было понять.
В таких ситуациях я предпочитаю для начала полностью выслушать предложения каждой стороны и только затем предлагать свои способы и варианты решения задачи. Ведь как бы там ни было, но у каждого подразделения есть свои KPI, на которых основываются выставленные требования, а значит нужно изыскать решение, которое устроит все стороны.
Таким образом, выслушав позицию каждой стороны, я сформулировал следующие пункты задачи:
- необходим инструмент для e-mail рассылок, позволяющий осуществлять массовую рассылку без привлечения внутренних системных ресурсов (общая постановка);
- процесс должен быть запущен в максимально сжатые сроки и с минимальным количеством согласований, т.к. мы знаем, что база подписчиков имеет тенденцию устаревать на 5-10% в течение месяца (- продажники);
- на первом этапе фактические финансовые затраты должны или отсутствовать вообще или быть минимальны для ускорения процесса запуска “пилота” — проще говоря, если понадобится оплатить услуги, то это необходимо сделать без тендера (- продажники и маркетинг);
- исходя из п.2., допускаются возможные ограничения по количеству отправляемых писем/количеству получателей (- продажники согласились, что чудес не бывает);
- исходя из п.2, установка отдельного софта — не приветствуется по причине сложности согласований с подразделением ИТ-безопасности. Соответственно, требуется веб-сервис (- ИТ и Безопасность).
- однако, в дальнейшем, необходима возможность использования именно отдельного приложения по причине внутренних требований компании ( — ИТ);
- веб-сервис (и будущее приложение) должны обладать гибкими возможностями не только e-mail рассылок, но также и последующего анализа рекламной кампании, а кроме того, быть связанными с инструментами веб-аналитики (- обязательное дополнение).
В рамках этой статьи я не буду приводить подготовленную для коллег сравнительную таблицу анализа лидеров сервисов e-mail рассылок, поскольку актуальность этих данных будет равна “только сегодня” — каждый сервис постоянно дорабатывает свои возможности.
Вместо этого я покажу вам тот чеклист, по которому выбирался будущий сервис-партнер. В нем я постарался максимально подробно указать причины необходимости использования того или иного функционала.
Забегая вперед отмечу, что по результатам анализа, нами был выбран e-mail сервис ePochta, как максимально полностью удовлетворяющий всем поставленным требованиям, в частности — как имеющий в своем арсенале помимо веб-сервиса еще и отдельный софт для рассылки. Методология выбора — в таблице ниже.
Чеклист функций сервиса e-mail рассылок
|
Требуемый функционал Описание функционала, причины необходимости использования |
||
| Количество рассылок должно быть неограниченным и они должны сохраняться на серверах |  |
|
| Каждый раз загружать одну и ту же базу подписчиков под каждую следующую рассылку — это крайне неудобно, плюс — требуется сохранение всей статистики по рассылкам. | ||
| Загрузка баз подписчиков в стандартных форматах, которые обслуживаются Microsoft Office — *.xls,*. xlsx,*. txt,*. csv. | |
|
| Учитывая, что копания пользуется только лицензионным программным обеспечением, а закупать отдельный софт для какой-то особой конвертации баз подписчиков не имеет логического и финансового смысла. Эти же форматы поддерживает и внутренняя CRM компании. | ||
| Поддержка разных адресов отправителя | |
|
| В компании существовала определенная процедура обработки маркетинговых и продающих активностей, которая предписывала обслуживание обращений клиентов при массовых кампаниях — общим Колл-центром, а при локальных кампаниях — отдельными региональными офисами, соответственно, необходимо было использовать разные адреса отправителей. | ||
| Персонализированное обращения в письмах и использование своих переменных | |
|
| Как показала практика, этот пункт необходимо воспринимать как обязательный к исполнению закон e-mail маркетинга. Подписчики очень не любят письма, адресованные “уважаемому пользователю наших чудесных услуг”, абсолютно правильно считая, что компания должна знать своих клиентов “в лицо”. Использование дополнительных переменных (шорткодов) в письмах позволит нам максимально персонализировать наше сообщение, добавив максимум “точек соприкосновения”. |
||
| Поддержка HTML-кода в письмах | |
|
| Времена только текстовых писем (plain text) уже давно прошли и все почтовые сервисы и программы нормально поддерживают использование графики, фонов и элементов верстки, а значит мы должны использовать всю мощь графического маркетинга в наших сообщениях. | ||
| Наличие готовых шаблонов писем и возможность создавать/загружать собственные шаблоны | |
|
| Если мы планируем обычную информационную рассылку (сообщения, уведомления и тд.), то не имеет особого смысла вкладываться в разработку индивидуального шаблона — можно использовать и готовый. Однако под отдельные рекламные кампании нам в обязательном порядке нужен брендированный шаблон писем, выполненный в отдельной стилистике проводимой кампании, причем шаблонов может быть много. | ||
| Планировщик рассылок | |
|
| Во-первых, время отправки рассылок может быть разным и не всегда это будут рабочие часы, и просто некому будет нажать “отправить”, а с другой стороны — при подготовке большого количества рассылок с разными предложениями, нам необходим инструмент для планирования графика их выхода — не в календарике же числа кружками обводить. Кроме того, мы планируем проводить рассылку поздравлений с памятными датами, а в этом случае без планировщика просто никак. | ||
| Отдельные ссылки для отписки от рассылки | |
|
| Мы не собираемся заниматься спамом и пользователь в обязательном порядке должен иметь возможность отписаться от нашей рассылки — пусть даже он и дал ранее согласие на получение. Отдельные ссылки нам нужны исходя из того, что адрес подписчика может участвовать в разных кампаниях и не факт, что он хочет удалить свой e-mail из всех типов рассылки — возможно ему не нравится только одна — к примеру, он хочет продолжать получать информационные письма, но не хочет — рекламные. |
||
| Отдельные страницы для отписки и блокировка (не удаление) адреса получателя из базы подписчиков | |
|
| Учитывая, что тип рассылок у нас может быть разный, а значит и причины отписки у получателя могут быть разные — соответственно, нам понадобятся разные страницы для создания разных сообщений и обращений к пользователю для его удержания. При этом, мы должны понимать — по какой причине отписался данный конкретный подписчик и иметь возможность составления статистики о причинах отписки. |
||
| Техническая статистика рассылок | |
|
Работать по принципу сисадминов из старого анекдота про стрельбище — “у нас пуля из ствола вышла — проблемы на вашей стороне” — не только бессмысленно, но и экономически небезопасно. Отправив рассылку, мы должны как минимум знать:
|
||
| Предварительная проверка e-mail адресов на существование |
в рамках ePochta Verifier |
в рамках ePochta Verifier |
| Перед запуском рассылки, мы должны проверить нашу базу подписчиков на валидность — проще говоря, удостовериться, что имеющийся у нас адрес фактически существует. Иначе какой смысл отправлять письма на заведомо несуществующие адреса? | ||
| Маркетинговая статистика рассылок и инструменты анализа | |
|
Мало просто знать, что письмо было доставлено получателю — необходимо понимать, какие действия он совершал при прочтении нашего письма. Соответственно, нам понадобится:
|
||
| Приложение для операционных систем, связанное с сервисом |
|
|
| Мы изначально определились, что веб-сервис будет использоваться на этапе “пилота”, а в дальнейшем нам понадобится отдельное приложение. Однако важен существенный момент — все наши наработки в рамках веб-сервиса (рассылки, статистика, базы подписчиков) должны автоматически подгрузиться в приложение — без необходимости лишней траты времени на дополнительную настройку. | ||
| Наличие бесплатного тестового периода | |
|
| Мы понимаем, что ни один сервис плохо о себе не напишет. Поэтому оставим в стороне красочные картинки и красивые стилистические обороты копирайтеров и перед тем как сказать финальное “да”, мы обязаны провести “боевое” тестирование сервиса не только на тестовой, но и реальной базе подписчиков. | ||
| Наличие гибкой тарифной политики | |
|
| Самый оптимальный вариант оплаты — за количество получателей с возможностью быстрой смены тарифного плана. | ||
| Онлайн-поддержка / Live Chat | |
|
| Этот аспект очень важен, т.к. в случае возникновения любых непредвиденных ситуаций в процессе работы с сервисом, мы должны быть уверены, что ответ от службы поддержки будет получен практически в реальном времени, а не тогда, когда рассылка уже должна была 3 часа как быть отправлена. | ||
И хотя в рамках данной задачи пока что не рассматривалась необходимость интеграции сервиса рассылки e-mail с уже существующей внутренней системной инфраструктурой компании (и потому его нет в чеклисте), необходимо обратить внимание на один крайне важный пункт, который обязательно должен быть реализован у компании-партнера и уже готов у ePochta — почтовый шлюз и его API. Гарантированное наличие такого сервиса позволит не задаваться вопросами о возможности интеграции в тот момент, когда в подобной взаимосвязи возникнет необходимость.
А какие опции в данный чеклист добавили бы Вы?