Интеграции программы для проката велосипедов: что окупается

Интеграции решают проблемы; они и создают новые

Прокат работает на нескольких системах: инструмент бронирования, платёжный провайдер, бухгалтерия, возможно, касса в магазине, почта, сайт, замок или GPS-трекер. Их соединение кажется очевидной выгодой и часто ею является. Но каждое соединение — ещё и новый способ, которым две системы могут противоречить друг другу, а расхождение между системой бронирования и бухгалтерией — плохой способ обнаружить возврат.

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

Типичные интеграции

Сначала решите, что является источником истины

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

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

Платежи

Связь с платежами — та, которой большинство прокатов не может избежать. На что обратить внимание:

• Какие провайдеры поддерживаются и можно ли использовать собственный аккаунт? На странице цен bikerental указано, что обработка платежей остаётся на Вашем собственном аккаунте Stripe; для работы из России стоит отдельно уточнить доступность выбранных платёжных провайдеров.
• Кто держит средства и как быстро приходят выплаты?
• Поддерживаются ли блокировки средств на карте для залогов и как обрабатывается истечение срока? См. залог и блокировка средств в прокате велосипедов.
• Оформляются ли возвраты и частичные возвраты из системы бронирования и видны ли в брони?
• Показаны ли платёжные комиссии отдельно от платы за программу?

Бухгалтерия

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

Касса магазина

Если Вы и продаёте, и ремонтируете велосипеды, рядом с системой проката может работать касса. Решите, что делится — обычно клиенты, иногда остатки и платежи, — а что нет. Более подробное объяснение — в тексте касса веломагазина или программа для проката.

Ваш сайт

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

Замки, GPS и телематика

В парках e-bike устройства, сообщающие местоположение, аккумулятор или статус, всё привлекательнее. Вопрос в том, куда идут их данные и меняют ли они то, что Вы можете сделать. Они полезны, если питают карточки велосипедов, предупреждают о проблемах и не добавляют ещё одну панель, которую никто не открывает. Модель данных bikerental уже имеет место для одометра, аккумулятора и идентичности устройства, так что устройства можно добавить позже без перестройки карточки парка.

API и вебхуки

API позволяет читать и записывать данные из собственных инструментов; вебхуки отправляют события, такие как новая бронь или возвращённый велосипед, в другие системы. Они мощны и являются обязательством: кто-то должен построить и поддерживать то, что от них зависит. Используйте их для конкретной потребности, как собственный отчёт или автоматизация, а не потому, что они есть. В bikerental API и вебхуки относятся к плану Growth и выше; см. цены.

Что идёт не так

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

По каждой интеграции спросите: что будет, когда она упадёт, и откуда я об этом узнаю?

Вопросы поставщикам

1. Интеграция нативная или это коннектор третьей стороны?
2. Она работает в одну сторону или в обе и что запускает синхронизацию?
3. Что происходит, когда синхронизация не удаётся? Получу ли я уведомление?
4. Какие поля общие и какая система побеждает в конфликте?
5. Есть ли дополнительная плата?
6. Можете ли Вы показать мне, что это работает?

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