Telegram работает. Но мы всё равно начали перенос

Telegram нас не блокировали. Боты работали. Клиенты не жаловались.

И всё же мы начали перенос части инфраструктуры на другую платформу.

Не из-за паники. Из-за расчёта.

Меня все также зовут Кирилл, работаю в команде Leancore, и за последние годы мы всё чаще видим одну и ту же проблему: бизнес выстраивает процессы вокруг одной платформы - пока она работает стабильно.

А потом начинает считать убытки.

Снова B2B, снова продукт, где Telegram - не просто канал коммуникации (тут не сильно важно какая сфера, все равно все не могу Вам рассказать :) ), а часть инфраструктуры:

- 12 000 активных пользователей;

- около 70% всей коммуникации проходит через ботов;

- ~6 млн ₽ оборота в месяц завязано на этом канале.

Telegram для нас - это онбординг, уведомления, взаимодействие с клиентами и часть воронки.

Долгое время всё работало стабильно. И именно это стало проблемой.

За последний год мы начали замечать:

- периодические задержки сообщений;

- нестабильность работы API;

- рост жалоб «не дошло»;

- сигналы о возможных ограничениях.

Это не катастрофа.Это постепенная потеря предсказуемости.А для B2B предсказуемость - важнее скорости.В какой-то момент мы задали себе простой вопрос:

Если завтра Telegram станет нестабильным на 3-5 дней, сколько это будет стоить бизнесу?

Ответ оказался неприятным.

Telegram для нас был не просто каналом.Он стал частью продуктовой логики.

Через него проходили:

- онбординг;

- ключевые уведомления;

- часть core-сценариев.

И здесь появляется важный момент.

Когда сторонняя платформа встроена в продукт, ВЫ зависите не только от её стабильности - вы зависите от её решений.

Если сообщение не дошло,пользователь винит не Telegram.

Он винит вас. (!)

Любая нестабильность API бьёт по вашим обещаниям клиентам.

И это уже не «техническая мелочь»,а вопрос доверия.

Когда core-сценарии завязаны на одной среде, любые её изменения автоматически становятся вашими ограничениями (!).

Это не маркетинговый риск. Это архитектурная зависимость...

Мы разделили:

- бизнес-логику;

- интерфейс;

- транспорт доставки.

Telegram остался интерфейсом,но перестал быть ядром.

Это стоило денег. Но это убрало продуктовый долг, который мог стать критическим.

Если 70% коммуникации завязано на одной платформе, любой сбой — это:

- остановка онбординга;

- потеря лидов;

- задержка операций;

- нагрузка на поддержку.

Даже несколько дней нестабильности - это миллионы рублей косвенных потерь.

И главное - мы никак не можем повлиять на этот риск.

Платформа - не наш актив. Это внешний фактор.

Мы не «убежали» из Telegram.

Мы начали диверсификацию:

- спроектировали мультиплатформенную архитектуру;

- отделили бизнес-логику от интерфейса;

- начали разработку версии под MAX (да-да тот самый);

- заложили возможность быстрого переключения.

MAX в этой истории - не «спасение» и не реклама. Это просто ещё одна точка инфраструктуры.

Telegram остался. Но он перестал быть единственной точкой входа.

Проблема не в Telegram. Проблема в зависимости.

Если 60–80% процессов бизнеса завязаны на одной платформе - это инфраструктурный риск.

И такие риски дешевле закрывать тогда, когда «всё работает», а не когда уже поздно.