Реалізація управління розкладом спеціалістів на сайті
Стоматологічна клініка з 15 лікарями витрачає 10 годин на тиждень на ручне узгодження розкладу. Перерви, відпустки, раптові блокування — кожен запит потребує дзвінка адміністратору. Excel-таблиця втрачає актуальність за годину. Щоб уникнути хаосу, потрібна система з оновленням у реальному часі, яка враховує всі винятки. Рішення — гнучкий модуль управління розкладом. Він використовує трирівневу модель доступності.
Ми інтегруємо такий модуль у веб-додатки будь-якого масштабу. Наша команда розробляє кастомні розклади більше 5 років, реалізовано 40+ проєктів для медичних та сервісних платформ. Система автоматично опрацьовує конфлікти слотів, сповіщає клієнтів про зміни та синхронізується із зовнішніми календарями. Це скорочує ручні операції на 80% та виключає подвійні бронювання. Трирівнева модель в 3 рази швидше опрацьовує зміни, ніж пласка структура, знижує операційні витрати на 30–50%. Середня річна економія для клініки з 10 спеціалістами — 500 000 рублів.
Як влаштоване управління розкладом спеціалістів?
Управління розкладом спеціалістів потребує гнучкої системи, адаптованої під будь-яку бізнес-логіку. Розклад будується з трьох шарів, кожен наступний перекриває попередній:
- Базовий шаблон — стандартний годинник за днями тижня: Пн–Пт 09:00–18:00, слот 60 хв, перерва 0 хв; Сб 10:00–14:00, слот 30 хв; Нд вихідний.
- Перевизначення дат — конкретна дата працює інакше: вихідний (свято), скорочений день, відпустка.
- Блокування — закриті інтервали всередині робочого дня: обід, нарада.
Управління розкладом спеціалістів: інтерфейс та API
Спеціаліст керує розкладом через особистий кабінет. Ключові операції:
| Дія | Як реалізується |
|---|---|
| Задати базовий годинник | Форма по днях тижня з полями start/end/slot |
| Закрити дату | Клік на дату в календарі → модальне вікно → тип: вихідний/відпустка |
| Відкрити неробочу дату | Той самий модал, тип: custom hours |
| Додати блокування | Drag на часовій шкалі або форма з датою та часом |
| Подивитись записи | Тижневий calendar view з бронями |
Як реалізувати гнучкий розклад без дублювання коду?
Розділіть шаблон, перевизначення та блокування. Кожен шар зберігається окремо та застосовується в рантаймі. Так зміни зводяться до додавання запису в таблицю overrides або blocks. Приклад API:
GET /api/specialists/{id}/schedule?date=2025-04-15
→ { slots: [...], overrides: [...], blocks: [...] }
GET /api/specialists/{id}/available-slots?from=2025-04-15&to=2025-04-21
→ { "2025-04-15": [{ start, end }], ... }
POST /api/specialists/{id}/overrides
{ override_date: "2025-05-01", type: "day_off" }
POST /api/specialists/{id}/blocks
{ starts_at: "2025-04-16T14:00", ends_at: "2025-04-16T15:00", reason: "Нарада" }
DELETE /api/specialists/{id}/overrides/{override_id}
DELETE /api/specialists/{id}/blocks/{block_id}
PATCH /api/specialists/{id}/schedule/{weekday}
{ start_time: "10:00", end_time: "18:00", slot_duration: 45 }
Для масових змін (відпустка на 2 тижні) використовується один запис з діапазоном date_from та date_until. При генерації слотів діапазони розгортаються в коді. Економія часу адміністратора досягає 40 годин на місяць.
Чому автоматичне вирішення конфліктів бронювання критичне?
Зазначимо: коли спеціаліст закриває дату з бронями, система автоматично:
- Знаходить всі активні броні на закритий період.
- Надсилає клієнтам листа з вибаченнями та пропозицією вибрати інший час.
- Переводить броні в статус
needs_reschedule. - Повідомляє адміністратора.
Приклад логіки на Python:
def close_date(specialist_id: int, date: date, reason: str):
affected_bookings = get_bookings_for_date(specialist_id, date)
with db.transaction():
create_override(specialist_id, date, 'day_off', reason=reason)
for booking in affected_bookings:
update_booking_status(booking.id, 'needs_reschedule')
send_reschedule_request_email(booking, specialist_id, reason)
notify_admin(specialist_id, booking, 'date_closed')
Такий підхід виключає ручний обдзвін та повторні броні. Зниження витрат на обробку конфліктів — до 40%.
Приклад з практики: стоматолог раптово захворів — закриває календар на 3 дні. Система знаходить 15 активних броней, надсилає пацієнтам листи з кнопкою «Вибрати інший час» та повідомляє адміністратора. За годину 12 пацієнтів перезаписались до іншого лікаря, 3 обрали очікування. Ручний обдзвін зайняв би 2 години.
Автоматичні свята
При створенні розкладу увімкніть опцію «закривати державні свята автоматично». Список свят завантажується через API (наприклад, Calendarific) або зберігається в таблиці налаштувань із щорічним оновленням. Налаштування виконується один раз при розгортанні.
Експорт у зовнішні календарі
Спеціаліст може синхронізувати розклад з Google Calendar або Outlook через iCalendar (RFC 5545)-фід:
GET /api/specialists/{id}/calendar.ics?token={private_token}
URL додається в Google Calendar як підписка — оновлюється кожні 15 хвилин автоматично.
Що входить у роботу
| Етап | Результат |
|---|---|
| Аналіз | Опис поточної схеми розкладу та інтеграцій |
| Проектування | Модель даних (таблиці overrides, blocks, public_holidays) |
| Розробка | API, інтерфейс управління, сповіщення, iCal-експорт |
| Тестування | Перевірка граничних випадків (перетин слотів, перехід через північ) |
| Документація | Інструкція для адміністратора та спеціаліста |
| Навчання | Онлайн-сесія для ключових користувачів |
| Підтримка | 1 місяць гарантійного супроводу після запуску |
Досвід та гарантії
Ми займаємося розробкою кастомних розкладів більше 5 років, реалізували 40+ модулів для медичних та сервісних платформ. Наші рішення гарантують стабільну роботу при навантаженні до 10 000 запитів на день на один ендпоінт розкладу. На відміну від саморобних рішень, наша система на 40% знижує кількість помилок бронювання.
Терміни реалізації
Базова версія (шаблон, блокування, API, проста адмінка) — 5–7 робочих днів. Розширена (відпустки, автопраздники, сповіщення, iCal, рольовий доступ) — 9–12 робочих днів. Точна оцінка — після аудиту вашого проєкту.
Зв'яжіться з нами — оцінимо проєкт за 1 день. Замовте впровадження під ключ: обговоримо деталі та підготуємо комерційну пропозицію.