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

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

Обзор

Мы @smallcase используем внутреннюю связь на наших платформах для обеспечения support функциональности. Интерком, вероятно, лучший инструмент на рынке с точки зрения функциональности, поддержки API и безопасности, но модальность ценообразования интеркома может быть проблемой.

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

Когда мы впервые интегрировали интерком (с самого начала), наши объемы и ежедневный активный пользователь были очень низкими, и нам пришлось заплатить несколько сотен или тысяч долларов за интерком. По мере того, как мы росли, наша пользовательская база достигла 6 миллионов пользователей.

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

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

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

В этом блоге мы увидим, как мы решили эту проблему и как мы сэкономили почти 50 тысяч долларов или больше в год.

Постановка задачи

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

  1. Пользователи регистрировались на интеркоме, как только они заходили на платформу, независимо от того, будут ли они использовать поддержку чата или нет, что приводило к увеличению числа зарегистрированных пользователей на интеркоме. Вот как мы использовали интерком, как указано в коде ниже.
const startIntercomAndRegisterUser = () => {
  window.Intercom('boot', {
  app_id: // app id here
  user_name: // user name here
  user_id: // user id here here
  // other intercom and user properties here
 });
}

Функция startIntercomAndRegisterUser была вызвана, как только пользователь зашел на платформу.

2. На нашей веб-брокерской платформе использовалось несколько рабочих пространств, например. для smallcases on zerodha мы использовали другое рабочее пространство, а для smallcases на angel мы использовали другое рабочее пространство, это было сделано изначально из-за некоторых устаревших причин, которые больше не были верны.

Решения

Решения вышеперечисленных проблем представляли собой многоэтапные решения и поэтапно развертывались для пользователей.

Решение проблемы 1

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

Первый подход → Мы подумали, что вместо того, чтобы загружать SDK заранее, когда платформа загружается, мы будем загружать его, когда пользователь пытается взаимодействовать с любой из Chat with Us кнопок. Это означает, что мы будем динамически загружать SDK из CDN всякий раз, когда пользователь нажимает любую кнопку Chat with us, если она еще не загружена.

Одна проблема с этим подходом заключалась в том, что виджет интеркома (показан на рисунке ниже) отображается только при успешной загрузке интеркома. Поэтому, если мы получим SDK по запросу, он не появится. Мы не хотим его удалять, потому что это важная часть нашего UX. Еще одна мысль заключалась в том, чтобы заменить этот виджет нашим собственным компонентом виджета и загружать интерком при нажатии на виджет. Сначала это казалось хорошим, но с этим подходом были проблемы

  • Поскольку пакет SDK внутренней связи будет получен из CDN, будет некоторая задержка для загрузки, загрузки и открытия пакета SDK. Поскольку SDK извлекается из CDN и поскольку это происходит по сети, время будет зависеть от того, насколько быстро был получен SDK.
  • Как поступить в случае, если SDK по какой-то причине не загружается? Мы можем перенаправить на почту, но тогда пользовательский интерфейс может ухудшиться по сравнению с тем, что мы имеем сейчас, потому что пользователю может показаться, что открытие почты заняло так много времени.

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

Было два метода, которые, как мы думали, могли решить нашу проблему, это были методы onShow и update.

  1. onShow - Согласно документации метод onShow будет вызываться, когда пользователю будет показана домашняя страница домофона (страница чата).
  2. update В соответствии с документацией этот метод используется для обновления пользовательских данных в интеркоме, и когда пользователь не найден, он создает нового пользователя.

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

Вы можете звонить в Intercom("обновление") без ограничения до 20 раз за 30 минут. После 20-го звонка вы будете ограничены, и квота в 20 вызовов будет сбрасываться каждые 30 минут. При перезагрузке страницы это состояние будет обновлено.

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

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

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

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

Решение было простым: использовать метод update для обновления свойств пользователя на внутренней связи, но вызывать этот метод только тогда, когда пользователь нажимает любую кнопку чата с нами / поддержки.

Мы использовали метод onShow, который будет вызываться интеркомом всякий раз, когда пользователь пытается открыть интерком, а метод onShow принимает обратный вызов, который будет вызываться, когда функция onShow вызывается интеркомом.

Мы передали метод Intercom(’update’) в качестве функции обратного вызова методу onShow, и это решило нашу проблему регистрации пользователей по внутренней связи только тогда, когда они демонстрируют намерение использовать варианты поддержки. Решение выглядело так

window.Intercom('onShow', () => {
   window.Intercom('update',{ 
     // user data here
   });
});

Этого решения было достаточно, чтобы перевести нас в облако 9, и одно это уменьшило количество активных пользователей на внутренней связи с 5 до 5000 пользователей и сэкономило нам 50 тысяч долларов.

Решение проблемы 2

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

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

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

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

Решение было простым: использовать метод update для обновления свойств пользователя на внутренней связи, но вызывать этот метод только тогда, когда пользователь нажимает любую кнопку чата с нами / поддержки.

Мы использовали метод onShow, который будет вызываться интеркомом всякий раз, когда пользователь пытается открыть интерком, а метод onShow принимает обратный вызов, который будет вызываться, когда функция onShow вызывается интеркомом.

Мы передали метод Intercom(’update’) в качестве функции обратного вызова методу onShow, и это решило нашу проблему регистрации пользователей по внутренней связи только тогда, когда они демонстрируют намерение использовать варианты поддержки. Решение выглядело так

Последние мысли

  • То, что сработало в нашу пользу, было нашей настройкой поддержки чата, так что поддержка живого чата (внутренняя связь) должна быть доступна только для вошедшего в систему пользователя, а для вышедших из системы пользователей мы просто открываем электронную почту. Поскольку мы разрешаем интерком только для пользователей, которые вошли в систему, мы легко смогли зарегистрировать их по запросу.
  • Решение, которое мы сделали для регистрации пользователей по запросу, не очень известное решение или шаблон, мы только что попробовали его, и оно работало для большинства сценариев, поэтому мы были им довольны. Вот почему мы называем это взломом.
  • Могут возникнуть некоторые проблемы: если метод обновления внутренней связи не работает, пользователь может не иметь возможности зарегистрироваться и получить доступ к чату, что может быть проблемой, но до сих пор не сталкивался с этой проблемой. Причина, по которой мы ничего не можем здесь сделать, заключается в том, что интерком не отправляет никаких обратных сообщений или сообщений о том, что пользователь успешно зарегистрировался, или окно чата не загружается из-за какой-либо проблемы. Таким образом, на данный момент для этого случая невозможна прямая или элегантная обработка.