Product Fail о том, как превратить воду в rocket science. Кейс SPRINKLE Water из Бангкока

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

В Таиланде выяснилось, что это сложнее, чем наши ML-пайплайны в Blask

Кейс о сервисе доставки воды Sprinkle. Формально — нормальной конторе с классной рекламой, и брендом как надо. На практике — энциклопедией продуктовой боли

Сюжет такой. Я переезжаю из одного кондо в другой, спустя год, как закончился контракт. У меня на руках две депозитных бутылки на 19 литров. Хочу базу — нормальную подписку по 2 бутылки в неделю, карта уже привязана к личному кабинету — снимайте мои деньги и привозите воду. Вместо этого я попадаю в ад с купонами.

К слову, Trial Set там выглядит так: 2 депозитных бутылки + 5 e-купонов. Один купон = одна бутылка (это написано у них же на сайте, всё честно)

И тут начинается комедия:
- сначала саппорт пишет, что 5 купонов волшебным образом превратились в 3 бутылки воды
- потом в этом же чате все 5 купонов израсходованы, баланс — 0
- потом your remaining coupons are still available for use — то есть, какие-то оставшиеся купоны внезапно ещё доступны, хотя только что было 0
- всё это время мой базовый запрос ребята, обновите адрес X на Y системно игнорится
- почти каждый заход заканчивается фразой chat agent has left the conversation, когда проблема ещё не решена, но попытка продать мне новый пакет купонов уже случилась

То есть, я пришёл за водой, а попал в казино, где вместо фишек купоны, а вместо крупье — лайн-бот (это местный мессенджер такой) с заевшим скриптом

А в чём продуктовый фейл-то? Если разложить без эмоций, то что тут не так:
1. Биллинг из 2005 года. Купоны решают задачи бухгалтерии, но убивают UX. У клиента в голове модель подписки на N бутылок в месяц, а система живёт в модели предоплаченных токенов + депозита железа (если так можно назвать бутылки)
2. Саппорт как фаерволл, а не как сервис. Скрипты заточены не на решение кейса, а на то, чтобы объяснить, что всё списано правильно (даже если это не так), а потом продать новый набор купонов. Поменять адрес по просьбе клиента? Использовать логику? Не, не слышали
3. Нет single source of truth для клиента. Сегодня 0 купонов, завтра remaining coupons, послезавтра опять 0. Это не просто неудобно, это разрушает доверие к системе как таковой
4. Паталогическая неготовность сказать “да, тут у нас косяк”. И вот тут начинается самое интересное — культурный слой, и пост ниже будет об этом

Немного инсайта про Бангкок, Таиланд и kreng jai

Если посмотреть не только на SPRINKLE, а на тайскую культуру в целом, картинка становится понятнее. В Таиланде есть прекрасный термин kreng jai — это такая смесь из не хочу доставлять неудобства, не хочу никого поставить в неловкое положение и лучше промолчу, чем создам конфликт

Добавим сюда
- saving face - нельзя терять лицо, нельзя прямолинейно признать ошибку, или ткнуть начальство / компанию носом в кривую систему
- высокую дистанцию власти (power distance) и избегание конфликта: подчинённые не спорят, не эскалируют, цепляются за скрипты как за спасительную тростинку, чтобы не брать ответственность

На выходе, мы получаем идеально предсказуемое поведение саппорта: лучше отправить три противоречивых шаблонных сообщения, чем честно сказать “слушай, у нас тут хаос с купонами и адресами, давай разберёмся”. Лучше аккуратно закрыть чат фразой agent has left the conversation, чем признать, что вопрос не решён. Ну и третье — лучше продать новый набор купонов, чем осмелиться поставить под сомнение старый процесс

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

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

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

А мы в Бласке живём без kreng jai — у нас маленькая, но очень требовательная эхо-камера. Здесь можно и нужно называть вещи своими именами. И если вода по подписке ощущается как рокет саенс, значит где-то по дороге продуктовый мозг реально отвалился

В следующий раз, если будете проектировать тарифы, биллинг и сапорт - вспомните Sprinkle и задайте себе один простой вопрос: клиент в этой системе - человек, или просто кошелёк с купонами? Если второе — добро пожаловать в коллекцию Product Fails

🇪🇺 Blask номинирован на European iGaming Awards 2025

Нас включили в шорт-лист категории Innovation of the Year. В этой номинации отмечают компании, которые двигают индустрию вперед.

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

Спасибо всем, кто участвует в развитии Blask и поддерживает продукт ❤️