BluEclipse
☰
BluEclipse business infrastructure
A Booking Is a Promise About a Resource
On screen it is a calendar. Underneath it is a question about whether a room, a person and an hour can all be committed at once — and the honest answer changes depending on what is being booked.
- Category
- Scheduling and business infrastructure
- Core technologies
- TypeScript, database scheduling logic, responsive interfaces, availability management
- Built for
- Services, venues, people and resources
BluEclipse's Booking System manages availability, scheduling, conflicts and customer bookings across different kinds of business — coordinating time slots, capacity, resources and services rather than simply offering a list of free times.
A booking interface looks like a calendar, which makes it look like a solved problem. It is not the calendar that is difficult. Behind a customer tapping “2pm on Thursday” sits a set of questions that all have to agree:
- Is the time available?
- Is the relevant staff member available?
- Is the venue already booked?
- Does the service require preparation time?
- Can several customers book simultaneously?
- Is capacity limited?
- Does another booking overlap?
So the system is managing two things at once — time, and the resources that have to be free during it. Treating it as only the first is how you end up with two customers booked into one chair.
Only offer what can actually be honoured
Businesses define when their services and resources are available, and the system uses those rules to decide which slots are worth showing at all. That is the cheapest possible version of conflict handling: a time that cannot be fulfilled is never offered, so it never has to be declined.
What the rules cannot prevent is two people reaching for the same remaining slot. Before a booking is accepted, the relevant resource and time range are checked against existing commitments — across:
- Venues
- Service providers
- Equipment
- Appointment slots
- Staff
- Business capacity
Conflict detection has been part of BluEclipse's earlier scheduling work too, including venue and resource booking systems, which is where most of the awkward cases were first met.
A double booking is not a data problem. It is a customer standing in a room that is already occupied.
Different services, different rules
One service takes thirty minutes; another takes two hours. Some allow several simultaneous bookings; others need exclusive use of a resource. Some need preparation time before or cleanup after, which is time that is unavailable without being booked.
The architecture therefore treats booking rules as configuration rather than assuming every appointment behaves identically. Hard-coding one service's behaviour is what turns a booking system into a booking system for exactly one business.
A booking has a life
A reservation is not one state. It moves, and the application needs to understand where it is:
- Available
- Requested
- Confirmed
- Upcoming
- Completed
Not every booking takes that route — requested to cancelled is a perfectly ordinary path, and one the system has to handle as a first-class outcome rather than as a deletion. Keeping the state explicit lets the rest of the application behave differently for something confirmed, something upcoming and something already finished, instead of treating every row in the table as the same kind of thing.
Two audiences, one system
Customers want the simplest possible path to a time that works. Businesses want operational control over their schedule. Those are genuinely different products built on one set of data, so the system supports both perspectives: customers browse availability and create bookings, while businesses manage schedules, review what is coming, update bookings and control when they are available.
Both happen on phones more often than not. For the customer that means choosing a service, a date and a time without being handed a full calendar interface to navigate. For the business owner it means managing the day while away from a desk, which is where most of them are.
Part of the business, not a separate calendar
Within Vendorah, bookings are not an isolated calendar product bolted on beside everything else. They connect to:
- Services
- Customers
- Payments
- Business notifications
- Accounting
- Availability
- Order-like workflows
Service businesses usually end up running their scheduling across WhatsApp messages, a paper diary, a spreadsheet and a calendar app — four places, none of which knows what the others have promised. Moving scheduling into the same environment as the rest of the business is most of the value.
A booking is not a date and a time. It is a promise that the right resource will be free when the customer arrives, and the system exists to make that promise reliably.
Built by BluEclipse. Used across service and resource scheduling workflows.
For service businesses
If your diary lives in three places and your customers book through a fourth, the scheduling is the easy part to fix.
For technology clients
Availability rules, resource conflict detection and configurable scheduling logic built to sit inside a larger platform rather than beside it.