Ошибки стартапов: Как мы потеряли четверть месячной прибыли за одну ночь

Раз в неделю в рубрике «Medium по-русски» ЦП публикует перевод популярного материала с блог-платформы Medium. В свежем выпуске — один из самых обсуждаемых материалов месяца, рассказ сотрудницы стартапа по разработке клиента для Google Drive, Insync, Ноэль Пико о том, к чему могут привести самые мелкие неполадки, если вовремя не обратить на них внимание.

В прошлом месяце один из наших разработчиков заметил, что почтовый сервер занимает 75% дискового пространства. Мы решили это проверить, так как знали, что в рабочем состоянии такого быть не должно. В итоге мы обнаружили некоторое количество ошибок, которые к этому и привели.

Чтобы исправить это, мы набросали скрипт для удаления повреждённых почтовых файлов, так как какие-либо попытки их открытия не увенчались успехом. После запуска скрипта, мы перезагрузили и сам почтовый сервер. Спустя пару часов мы стали получать огромное количество писем и твитов: на каждый наш ответ приходилось десять вопросов от пользователей. Как оказалось, наши письма не доходили до пользователей три месяца, и теперь мы внезапно стали забивать их почтовые ящики.

@insynchq no worries, it happens.

— Matt Durr (@onedurr) September 12, 2014

Надо отметить, что пользователи отнеслись к такому неожиданному спаму с нашей стороны спокойно и с пониманием.

Решилась ли наша проблема? Не совсем.

***

Отмотаем пленку на пару месяцев назад.

Мы заметили три необычных детали:

• Конверсия с пробной на платную подписку упала сразу на 40%;
• Уведомления внутри самого продукта, которые мы отправляли вовремя, до наших пользователей совсем не доходили;
  
• Количество ответов на нашу рассылку упало на 75% — людям не на что было отвечать (хотя мы об этом еще не знали).

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

У нас была куча собранной информации. Где-то всё пошло не так — мы это чувствовали. Но у нас не получалось найти корень всех проблем (спустя три месяца это обернулось для нас сумасшедшей рассылкой писем с извинениями), который оказался гораздо менее заметным, чем мы думали — наш почтовый робот перестал работать.

Письмо с извинениями от 12 сентября

Такие вещи вредят маленьким стартапам — думать, что большие проблемы требуют аналогичных решений.

Являлась ли наша проблема серьёзной? Да, являлась.

Цифры говорят сами за себя: потерять 25% месячной прибыли много для всех без исключения.

Была ли истинная причина проблемы столь большой? Точно нет. Всё это время мы искали решение не там, где его нужно было искать.

***

Говорят, что профилактика лучше любого лечения, но никто не прислушивается к этому совету до тех пор, пока самого не клюнет в одно место. До недавних пор мы еще сами не понимали, что нам стоит что-то проверять. Теперь мы знаем, что стартапам нужно делать такие вещи, как:

• Тщательно мониторить работу почтового робота;
• Фиксировать все процессы;
• Коммуникации и изучение абсолютно всех сбоев — не важно, насколько маленькими они кажутся.

Мониторинг

Сейчас мы пользуемся сервисом Datadog для слежения за работой почтовой службы.

Мы поставили индивидуальные уведомления, высылаемые по достижению почтовым роботом критических отметок, и назначили несколько сотрудников для работы с почтой.

Это важно в том случае, если очередь исходящих писем превысила заданный размер, или если количество почты, назначенной для отправки в определённый период, также падает ниже заданного уровня — в обоих случаях мы тут же узнаём об этом.

Как видите, нам пришлось полностью заняться решением возникшей проблемы — это не рационально потраченное время, ведь были лучшие способы для самой обычной профилактики.

Фиксирование процессов

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

Мы знали три факта о нашей почте:

• Она посылает письма по заданной необходимости;
• Очередь из исходящих писем на сервере на должна расти слишком быстро, если существующие или новые задачи всё еще находятся на исполнении;
• С того момента, когда каждый сотрудник компании имел отдельный доступ к почте, каждое её падение предполагало, что кто-то не делает свою работу.

Нам нужно было обратить всё своё внимание на то, чтобы перечисленное не происходило. Но на фоне катастрофического падения выручки эпизод с поломкой почты не казался нам таким уж важным — потеря денег давила на нас сильнее.

Но не тут-то было. По факту же оказалось, что критическая поломка нашей почты отрезала нас от клиентов. Этот парень ( почтовый робот — прим. пер.) был в ответе за то, чтобы знать, хотят ли пользователи перейти с пробной подписки на платную. Он также должен был уведомлять людей о том, что мы получили их оплату, или что оплаченный период вот-вот закончится.

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

Коммуникации

Мы уже знали, что наш почтовый робот отвечает за рассылку уведомлений с форума и приветственных писем новым пользователям. Некоторые члены команды заметили, что уведомления не отсылались. Мы также получали меньше ответов на приветственные письма.

Если бы хоть кто-нибудь из нас обсудил эти моменты друг с другом, то, скорее всего, мы могли бы понять всё раньше. Мы упустили этот момент, как было отмечено выше, потому что думали, что с почтой не могло случиться ничего серьёзного. Сейчас мы говорим друг с другом обо всём, что может вызвать у нас хоть малейшие сомнения относительно работоспособности продукта.

Мы решили, что лучше быть уверенными, что всё работает.

***

Несмотря на все те отслеживающие системы, что мы установили теперь, это не отменяет необходимости сделать еще больше работы, чтобы «обнулить» последствия. Когда у вас есть такая цель, как сделать вашу компанию прибыльной, вы не имеете права беспечно надеяться (как это сделали мы) на то, что всё будет идти как по маслу — этого не произойдёт.

К работе надо изначально подходить с таким отношением — но действительно исполнение всей работы отличается от теории, а то, что кажется простым, оказывается самым сложным.

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

Мы же поняли, что вещи, сперва кажущиеся крохотными, могут оказать сильное влияние на все последующие этапы деятельности. Это был тяжелый и очень дорогой урок.