У цьому посібнику
Інтеграції вирішують проблеми; вони й створюють нові
Прокат працює на кількох системах: інструмент бронювання, платіжний провайдер, бухгалтерія, можливо, каса в магазині, пошта, сайт, замок чи GPS-локатор. Їх з’єднання здається очевидною вигодою й часто нею є. Але кожне з’єднання — ще й новий спосіб, яким дві системи можуть суперечити одна одній, а розбіжність між системою бронювання та бухгалтерією — поганий спосіб виявити повернення коштів.
Цей текст показує, які інтеграції окупаються, як вирішити, яка система є джерелом істини для якого типу даних, що йде не так і як оцінювати обіцянки постачальників.
Типові інтеграції
| Інтеграція | Що робить | Цінність | Ризик |
|---|---|---|---|
| Платіжний провайдер | Приймає платежі, преавторизації та повернення | Ключова | Комісії й блокування мають відповідати бронюванню |
| Бухгалтерія | Передає дохід і платежі до книг | Висока | Дубльовані або відсутні записи |
| Каса магазину | Ділить клієнтів, залишки чи продажі з касою магазину | Середня; залежить від Вашого бізнесу | Дві системи вважають себе власником клієнта |
| Сайт або віджет | Переносить бронювання на Ваш сайт | Висока | Застаріла доступність, якщо не наживо |
| Пошта й маркетинг | Надсилає підтвердження й кампанії | Середня | Згоди та дубльовані контакти |
| Замки, GPS, телематика | Зчитує локацію, акумулятор чи статус | Середня до високої для e-bike | Модель даних і вартість |
| API та вебхуки | З’єднання на замовлення | Висока за конкретної потреби | Тягар підтримки |
Спочатку вирішіть, що є джерелом істини
Для кожного типу інформації одна система має бути вирішальною. Інші з неї читають або отримують копію, але не редагують.
| Дані | Звичайне джерело істини |
|---|---|
| Доступність і бронювання | Система бронювання |
| Статус та історія окремих велосипедів | Система бронювання або парку |
| Особа клієнтів та вейвери | Система бронювання |
| Платежі, преавторизації й повернення | Платіжний провайдер, відображений у бронюванні |
| Бухгалтерський облік | Бухгалтерська програма |
| Залишки для продажу й ремонти в магазині | Каса або система майстерні |
Коли дві системи претендують на клієнта, виникають дублікати. Коли обидві можуть змінювати бронювання, виникають подвійні бронювання. Спершу вирішіть, потім з’єднуйте.
Платежі
Зв’язок із платежами — той, якого більшість прокатів не може уникнути. На що звернути увагу:
- Які провайдери підтримуються і чи можна використати власний акаунт? На сторінці цін bikerental зазначено, що обробка платежів залишається на Вашому власному акаунті Stripe.
- Хто тримає кошти й як швидко приходять виплати?
- Чи підтримуються преавторизації картки для застав і як обробляється закінчення терміну? Див. застава та преавторизація в прокаті велосипедів.
- Чи повернення й часткові повернення коштів оформлюються із системи бронювання й видимі в бронюванні?
- Чи платіжні комісії показано окремо від плати за програму?
Бухгалтерія
Ви не хочете вводити дохід двічі. Шукайте спосіб передавати дохід, платежі та повернення, зведено чи детально, до бухгалтерської програми або бухгалтеру, з чіткими правилами для ПДВ (якщо застосовується) і для застав, які зазвичай не є доходом. Якщо прямого з’єднання немає, достатньо регулярного структурованого експорту. Питання в тому, чи збігаються цифри, а не чи є на сторінці логотип.
Каса магазину
Якщо Ви й продаєте, і ремонтуєте велосипеди, поруч із системою прокату може працювати каса. Вирішіть, що ділиться — зазвичай клієнти, іноді залишки й платежі, — а що ні. Довше пояснення — у тексті каса веломагазину чи програма для прокату.
Ваш сайт
Віджет бронювання чи сторінка, розміщена на Вашому домені, має читати доступність наживо із системи бронювання, ніколи не копію. Перевірте: зробіть бронювання й подивіться, чи змінюється доступність за кілька секунд. На телефоні перевірте швидкість і завершення. Див. чек-лист системи бронювання.
Замки, GPS і телематика
У парках e-bike пристрої, що повідомляють локацію, акумулятор чи статус, дедалі привабливіші. Питання в тому, куди йдуть їхні дані і чи змінюють вони те, що Ви можете зробити. Вони корисні, якщо живлять картки велосипедів, попереджають про проблеми й не додають ще одну панель, яку ніхто не відкриває. Модель даних bikerental уже має місце для лічильника, акумулятора та ідентичності пристрою, тож пристрої можна додати пізніше без перебудови картки парку.
API та вебхуки
API дозволяє читати й записувати дані з власних інструментів; вебхуки надсилають події, як-от нове бронювання чи повернений велосипед, до інших систем. Вони потужні й є зобов’язанням: хтось має збудувати й підтримувати те, що від них залежить. Використовуйте їх для конкретної потреби, як-от власний звіт чи автоматизація, а не тому, що вони є. У bikerental API та вебхуки належать до плану Growth і вище; див. ціни.
Що йде не так
- Дубльовані клієнти, коли дві системи створюють картки однієї людини.
- Застаріла доступність, коли віджет чи канал читає запізнілу копію.
- Розбіжні повернення, коли повернення зроблено в одній системі, а в іншій не зафіксовано.
- Петлі синхронізації, у яких дві системи перезаписують одна одну.
- Тихі збої, коли інтеграція зупиняється і ніхто цього не помічає до закриття місяця.
Щодо кожної інтеграції запитайте: що буде, коли вона впаде, і звідки я про це дізнаюся?
Запитання до постачальників
- Інтеграція нативна чи це конектор третьої сторони?
- Вона працює в один бік чи в обидва і що запускає синхронізацію?
- Що відбувається, коли синхронізація не вдається? Чи отримаю я сповіщення?
- Які поля спільні й яка система перемагає в конфлікті?
- Чи є додаткова плата?
- Чи можете Ви показати мені, що це працює?
Якщо Ви порівнюєте продукти, рядки про інтеграції з посібника з вибору і порівняння найкращих програм можна додати до своєї таблиці оцінювання.
Поширені запитання
Які інтеграції потрібні прокату велосипедів?
Майже завжди платіжний провайдер, зазвичай бухгалтерія та віджет бронювання на сайті. Каса магазину, маркетингові інструменти, пристрої й API окупаються лише за конкретних потреб.
Що таке джерело істини?
Єдина система, що володіє певним типом даних, як-от доступність чи клієнти. Інші читають їх або отримують копії без редагування, що запобігає дублікатам і конфліктам.
Чи потрібен мені API?
Лише за конкретної потреби, як-от власний звіт чи автоматизація. API — це зобов’язання щось збудувати й підтримувати.