Отсутствует система для рассыли ключей доступа к курсу. Ожидается несколько сотен клиентов, до старта 4 часа. Риск провала запуска курса.
Автоматизировать рассылку в кротчайшие сроки.
У заказчика есть сайт на тильде, с ним интегрирована внутренняя CRM-система. Для рассылок уже имеется unisender, но он используется только для массовых рассылок.
Для защиты курсов и хранения ключей используется infoprotector.
Из технической команды - один человек, который ведет тильду.
Ограничение на первичное время решения - 4 часа.
Необходимо за час изучить возможность интеграции в CRM-систему тильды, api unisender для рассылки, и возможность автоматизированной выгрузки из infoprotector, и в дальнейшем построить на их основе решение с его дальнейшей доработкой.
В результате было выявлено, что у CRM тильды нет открытого api. Можно бы было по аналогии с парсерами попробовать перехватить трафик через fiddler, и провести реверс api, тем не менее в таком случае это дало бы менее стабильную систему, на поддержание которой заказчику потребовалось бы больше ресурсов.
Оказалось, что у infoprotector отсутствует удобный функционал для автоматической выгрузки ключей. Тем не менее поскольку она происходит разово, то можно провести выгрузку через txt-файл, и интегрировать его таким образом в систему, что также дает возможность ручного редактирования на первых этапах отладки.
Было выявлено, что у тильды есть интеграции с unisender, в БД которого можно по запросу высылать всю необходимую информацию о клиенте по рассылке, и далее хранить её локально на сервере, с которого осуществляется оркестрация рассылки.
Тем не менее, из-за ограничений по времени и необходимости дополнительной отладки такой системы для первой рассылки было выбрано более простое решение.
В рамках первой рассылки происходила ручная выгрузка всех БД из CRM-системы тильды, и далее по порядку по этим системам распределялись ключи из txt-файлов infoprotector. Система была достаточно простая в плане комбинаторики, локальное тестирование не выявило ошибок, первая рассылка была проведена успешно, все получили свои ключи.
Для каждой рассылки было необходимо проводить выгрузку трех файлов из CRM тильды, с их дальнейшим переименованием и заменой, что, как минимум, допускает возможность человеческой ошибки, как максимум - не является автоматизированной системой и решает в полной мере боли заказчика. Тем не менее, в моменте риски были закрыты, и можно было переходить на разработку полноценной системы в спокойном темпе.
Ранее придуманный план на основе интеграции с unisender оказался оптимален с точки зрения имеющихся у заказчика ресурсов: формы тильды с ним легко интегрируются, при этом у заказчика уже имеется опыт взаимодействия с сервисом.
Также осуществение интеграции БД через unisender без дополнительных интеграций с внешними crm позволило сократить интеграционную цепочку сервисов, что сделало её более устойчивой и удобной в плане мониторинга.
Результат - довольно простая цепочка обшения: Форма тильды -> бд unisender + локальные БД из CRM -> локальная бд сервера -> скрипт распределения ключей -> рассылка unisender -> почта пользователя
При этом была сохранена возможность ручного добавления, а локальные БД позволили создать преемственность и облегчить переход от временного решения на полноценное.
Таким образом была создана полностью автоматизированная система, полное решение заняло 2 дня.
Но затем вскрылась другая маленькая боль - ручное добавление все еще имело проблемы, описанные во временном решении - неавтоматизировано, и есть риск человеческой ошибки. для исправления чего были созданы формы в закрытом ЛК тильды для ручного добавления в сам unisender, таким образом цепочка интеграций стала максимально прямой и удобной.
В дальнейшем потребовалось улучшение user-experience, так как не всем пользователям приходили письма через unisender, так как у некоторых автоматические рассылки были заблокированы почтовым сервисом.
В результате был создан бот в discord на основе python requests (без дополнительных библиотек, для поддержания уровня простоты системы и удобства деплоя), который проверяет по БД ключ, далее отправляет запрос в unisender, чтобы проверить, доступна ли почта, после чего начинает отработку по сценариям.
Принцип сценариев следующий:
Тем не менее, если после рекомендации перепроверить почту выясняется, что письма в ней нет, то у пользователя остается возможность обратиться в техподдержку к людям.
Для техподдержки был сделан бот в телегаме, в который выгружаются логи. По поиску в диалоге человек может найти лог с нужной почтой, и посмотреть в нём ключи пользователя.
Все боты хостятся на выделенном физическом сервере, который поддерживается Null One Research.
Таким образом все боли заказчика в данном кейсе были решены.
По всем вопросам можно обращаться в Телеграм.