Problem
Booking and operations cannot live separately
A pet resort must coordinate real capacity, customer and dog data, arrivals, departures, add-on services, documents and deposit state. A booking form alone is not enough.
EMPV / Project03
Booking and operations on one platform
Operations platform for a pet facility
A booking is not simply a date on a calendar.
Every booking consumes real capacity and carries customer, animal, document, deposit, add-on service and stay-related work. If those facts live in separate modules, staff must continuously reconcile them.
What we changedWe designed booking and operations as one system.
System
One domain from request to stay
Booking, customer area and back office share the same data. Staff see current guests, arrivals, departures and tasks; customers access their profile and bookings without duplicate identities.
01 / The core
Booking is the beginning, not the end.
Accommodation availability, booking lifecycle, dog data, grooming, agreements, payments and daily operations are treated as parts of the same product.
02 / The customer
One identity even when staff created the record first.
If staff already created the customer, dog and bookings, online activation recovers that identity instead of creating a duplicate. The account remains connected to existing history.
03 / Operations
Staff work from what is actually present and expected.
The system separates accommodation availability from the daily operations view and handles arrivals, departures, grooming, documents and confirmation state tied to the deposit.
04 / Architecture
Web product with domain rules enforced server-side.
Laravel, dedicated platform components, an admin surface and myPOS integration form the technical core. Exposed APIs remain limited to flows the product actually needs.