Відзначимо: коли бронювання скасовується за хвилину до початку, адміністратор змушений вручну звільняти слот і повертати гроші. При 30 таких скасуваннях на день втрати часу сягають 2 годин, а 70% операцій містять помилки. Клієнти не можуть швидко перенести запис — вони йдуть до конкурентів. Ми пропонуємо систему з гнучкими політиками, токен-посиланнями та автоматичними сповіщеннями, яка вирішує ці проблеми. Розглянемо реалізацію на прикладі Laravel. Автоматизація скасувань скорочує час обробки в 18 разів і економить до 40 годин на місяць — при вартості години адміністратора 500 грн це 20 000 грн щомісяця. А головне, ви впроваджуєте self-service bookings, знижуючи навантаження на підтримку на 80%.
Проблеми, які вирішує автоматичне скасування та перенесення
- Ручна обробка відмін — адміністратору доводиться вручну звільняти слоти, повертати гроші та сповіщати сторони. Кожна така операція займає 3–5 хвилин, а на день їх буває до 30. Автоматизація скорочує цей час втричі, економлячи до 40 годин на місяць.
- Зловживання скасуваннями — без лімітів клієнти можуть скасовувати броні за хвилину до початку, залишаючи порожні слоти. Нам потрібен захист: пороги безплатного скасування, штрафи та блокування при частих відмінах. Система обробляє 90% скасувань без участі людини, а штрафи за пізню відміну можуть становити 20–100% вартості.
- Втрачені клієнти — якщо користувач не може легко змінити запис, він іде до конкурентів. Перенесення має бути таким же простим, як скасування — з вибором нового часу та миттєвим підтвердженням.
Чому політика скасування має бути гнучкою?
Політика задається для кожної послуги окремо. Ось типові варіанти:
| Тип політики | Безплатне скасування за | Штраф при пізньому скасуванні | Повернення при неявці |
|---|---|---|---|
| Ліберальна | ≥ 24 години | 20% | 0% |
| Стандартна | ≥ 6 годин | 50% | 0% |
| Сувора | ≥ 1 година | 100% | 0% |
Ліберальна політика підходить для салонів краси, сувора — для медичних клінік. Реалізація на PHP/Laravel виглядає так:
Приклад реалізації політики скасування
class BookingCancellationPolicy { public function canCancel(Booking $booking): CancellationResult { $hoursUntilBooking = now()->diffInHours($booking->starts_at, absolute: false); if ($hoursUntilBooking < 0) { return CancellationResult::denied('Бронювання вже минуло'); } $policy = $booking->service->cancellation_policy; if ($hoursUntilBooking < $policy->free_cancel_hours) { return CancellationResult::withPenalty( "Скасування менш ніж за {$policy->free_cancel_hours} годин: " . "штраф {$policy->penalty_percent}%", penaltyPercent: $policy->penalty_percent ); } return CancellationResult::free(); } } Метод canCancel повертає об'єкт CancellationResult — з методом free(), withPenalty() або denied(). Далі контролер або Inertia-компонент вже вирішує, що показати користувачеві: кнопку «Скасувати безплатно», «Скасувати зі штрафом у X%» або повідомлення, що скасування неможливе.
Як налаштувати політику скасування за 5 кроків?
- В адмін-панелі виберіть послугу.
- Вкажіть поріг безплатного скасування (у годинах до початку).
- Задайте відсоток штрафу для пізнього скасування.
- Визначте, чи повертати гроші на баланс або на картку.
- Збережіть налаштування — зміни набувають чинності одразу.
Токен-посилання: відміна без реєстрації
Будь-яка авторизація — це бар'єр. Якщо клієнт забув пароль або сидить у чужому браузері, він не зможе скасувати запис. Рішення — токен-посилання. При створенні броні ми генеруємо два унікальних токени (для скасування та перенесення) і зберігаємо їх у моделі:
class Booking extends Model { protected static function booted(): void { static::creating(function (Booking $booking) { $booking->cancel_token = Str::random(64); $booking->reschedule_token = Str::random(64); }); } } Токени передаються в листі як посилання виду /bookings/cancel/{token}. Роут знаходить бронювання по токену та відображає сторінку з інформацією та кнопкою скасування. Жодної реєстрації — лише перехід за посиланням і підтвердження. Такий підхід знижує навантаження на підтримку на 80%.
Як захиститися від зловживань?
Система відстежує кількість відмін з одного акаунта та часові інтервали. При підозрілій активності (наприклад, 5 скасувань за годину) бронь переводиться на ручну перевірку або блокується з повідомленням адміністратора. Також налаштовуються ліміти безплатних відмін: після вичерпання ліміту клієнт платить штраф. Для критичних послуг можна ввімкнути обов'язкове підтвердження адміністратором.
Атомарне перенесення: уникнення race condition
Перенесення складніше за скасування, оскільки потрібно атомарно звільнити старий слот і зайняти новий. Ключовий момент: новий слот резервується перед звільненням старого. Інакше два клієнти можуть одночасно перенестися на один і той самий час — класичний race condition.
Приклад реалізації перенесення
public function reschedule(Request $request, string $token): JsonResponse { $booking = Booking::where('reschedule_token', $token)->firstOrFail(); DB::transaction(function () use ($booking, $request) { $newSlot = TimeSlot::findOrFail($request->new_slot_id); // Перевіряємо доступність нового слота if (!$newSlot->available) { throw new SlotUnavailableException(); } // Звільняємо старий слот TimeSlot::where('booking_id', $booking->id)->update(['booking_id' => null]); // Займаємо новий $newSlot->update(['booking_id' => $booking->id]); $booking->update([ 'starts_at' => $newSlot->datetime, 'status' => 'rescheduled', ]); }); // Відправляємо підтвердження перенесення Mail::to($booking->customer_email)->send(new BookingRescheduledMail($booking)); return response()->json(['success' => true]); } Зверніть увагу: перевірка $newSlot->available — це не просто булеве поле, а обчислюваний атрибут, який дивиться booking_id і status слота. Якщо слот зайнятий — викидається SlotUnavailableException, транзакція відкочується, користувач отримує помилку. Гарантуємо відсутність race condition навіть при 50 паралельних запитах на перенесення.
Як тестувати паралельні запити?
Ми використовуємо навантажувальне тестування з Laravel Documentation та інструментом Apache Bench. Запускаємо 50 одночасних запитів з різними токенами на один і той самий слот. Перевіряємо, що лише один проходить, інші отримують помилку. Всі тести покривають критичний шлях скасування та перенесення.
Порівняння ручної та автоматичної обробки
| Параметр | Ручна обробка | Автоматична система |
|---|---|---|
| Час на скасування | 3-5 хвилин | 10 секунд |
| Ризик помилок | Високий | Мінімальний (у 5 разів менше) |
| Участь адміністратора | 100% | 10% |
| Можливість перенесення | По телефону | В один клік |
Автоматизація скасувань у 18 разів швидша за ручну обробку і майже повністю виключає помилки.
Що входить у роботу
Відзначимо: коли ви замовляєте у нас впровадження системи скасування та перенесення, ми робимо:
- Опис політик — для кожної послуги налаштовуємо пороги, штрафи та винятки.
- Backend-логіка — реалізація
CancellationPolicy, обробка запитів через контролери. - Токен-посилання — генерація, зберігання, роути та сторінки скасування/перенесення.
- Форма перенесення — інтеграція з компонентом
AvailabilityCalendarдля вибору нового слота. - Сповіщення — листи, push та SMS (опціонально) для всіх подій.
- Адмін-панель — список усіх скасувань та перенесень, ручне керування.
- Тестування — навантажувальні тести для перевірки паралельних запитів (гарантуємо відсутність race condition).
Строки та контакти
Скасування та перенесення бронювань з політиками та токен-посиланнями — 3–5 робочих днів. Перенесення з формою вибору часу та транзакційною безпекою — до 7 днів. Вартість впровадження базового функціоналу — від 15 000 грн. Зв'яжіться з нами — оцінимо ваш проект за 1 робочий день. Отримайте консультацію щодо впровадження self-service bookings для вашого бізнесу.
Система будується так, щоб легко вбудовуватися в існуючу архітектуру — чи то Laravel, Django або Express. А якщо у вас ще немає бронювання — реалізуємо все з нуля. Наша команда має 5-річний досвід у розробці booking-систем і виконала 20+ проектів з автоматизації запису. Замовте впровадження зараз — отримайте консультацію за 1 день.