The pieces and their boundaries are settled before code.
Several institutions, one system, records kept apart.
One codebase, both stores: iOS and Android.
We take a running system over and improve it.
AI only where the problem actually calls for it.
Appointment booking system
A booked hour fills a resource, and the resource decides how many people fit. Whether a class or a package was sold, and what a cancellation turns into, sit on the same record. For a studio, salon, clinic or workshop, that record is what you are paying for when you buy a booking system, not the calendar it shows.
An appointment booking system writes a booked hour into one record with its ceiling, its unit and its cancellation rule. Those three are settled when the system is built, not when somebody books: how many people the hour holds, what unit is sold, and whether a cancellation returns the credit. At Pilatesco full hours lived in the calendar, remaining classes in a notebook and cancellations in a chat thread, until one record held them.
Bookings do not keep the same rhythm from one business to the next. An appointment in a clinic, a salon and a workshop neither runs the same length nor fills the same thing, yet most ready-made booking software is written for a single trade and sits awkwardly on the next. A business in that position is left with two options: reshape how it works to match the software, or carry every booking by hand between a calendar and a chat thread. We are building AlgoRandevu for that reason, and we are keeping the length of an appointment open inside the product so that the business, not the trade, sets it.
At Pilatesco the hour and the thing being sold lived apart. The studio sells packages, so a member never pays for a single class, yet how many classes were left was known to a notebook and what became of a cancelled class was known to a message thread. An hour also has a ceiling of its own: the instructor teaching it and the equipment on the floor decide how many people it can take, and nobody can write an open-ended list against it. So the system was not asked to keep a calendar; it was asked to say what a reservation does to the package a member bought. The Pilatesco case shows how that definition was written.
Reserving an hour and reporting a fault are not the same job, which is why the two do not share a form. At Diotek a survey appointment and a service call were built as separate flows from the start, and we explain why that split belongs at record level in keeping an appointment and a service request apart.
When the hour is one step of a plan, this page is half the answer. The dental clinic CRM is that kind of record: treatment does not end in one visit, and the series an appointment sits in follows a plan, which the CRM page and the dental clinic case take apart. The record is one and it has two ends: the ceiling, the unit sold and the cancellation rule at this end, the step of the plan at the other.
An appointment booking system is one of the narrower headings under enterprise software: how many institutions and screens share one system is answered there, and the rule of the booked hour here. The order is the same in your system. The ceiling, the unit sold and the cancellation rule are written first, and only then is an hour booked against them.
Six decisions that say what happens when an hour is booked:
At Pilatesco one question had three homes: whether an hour was full lived in the calendar, how many classes were left in a notebook, what a cancellation meant in a message. All three answers now come off one record.
Pilatesco members do not pay per class; they buy a package. So the system sells the package, and a booked hour comes out of it instead of being sold on its own.
At Pilatesco no hour takes an open-ended list of names. Its ceiling is set by who teaches it and what equipment is on the floor, and a full hour reads as full on the calendar.
Reserving an hour and reporting a fault are not the same job. At Diotek a survey appointment and a service call never share a form; the two were built as separate flows from the start.
Most booking software is shaped around one trade and is a poor fit for the next; an appointment in a clinic, a salon and a workshop does not run the same length. We are building AlgoRandevu so that length is set inside the product rather than by the trade.
In the dental clinic CRM treatment does not end in one visit, and an appointment belongs to a series that follows a plan. That record has two ends: the ceiling, the unit and the cancellation rule on this page, the step of the plan on the CRM page.
Every project goes through the same four stages: planning, architecture, modelling, development.
See our process
Our own product, still in development and not yet live. How long an appointment runs, what it is booked against and how bookings stack all differ by trade, so we are keeping those rules configurable inside the product instead of fixing them in code.
Instructor, equipment and time slot together decide how many people a class can take. Members buy packages, so each reservation draws a credit off a balance, while cancellations and no-shows post to it differently. An invoice arises at the sale; usage is read from the calendar.
Treatment is planned tooth by tooth and split into sessions spread over weeks. An appointment is a scheduled step of that plan rather than an empty slot, so changing the plan moves the calendar. Invoices and reports come off the same patient record.
We have no office, so we do not provide on-site support either. The work runs remotely and we scope it on that basis.
It may be. If your bookings are a calendar and a reminder, a ready-made tool is the right answer and we say so in the first conversation. The day it starts to pinch, the work drifts back to a calendar and a chat thread. AlgoRandevu is the product we are building so that a business is not stuck between bending to a tool and booking by hand. Put what a booking fills in your business into the quote form and we draw the line from there.
It carries both. Which one you sell is decided before the first sale, not customer by customer. If you sell packages, your sales screen sells the package and your customer books a class out of what they bought. Pilatesco members buy a package rather than paying per class, so the system sells that package and every class comes out of it. The studio case below shows how that sale was set up.
Start from the CRM page. The two pages hold the two ends of one record: the step of the plan lives there, the hour's ceiling, the unit sold and the cancellation rule live here, and your record is written at both ends. The dental clinic CRM keeps every appointment inside a series, because treatment there does not end in one visit. If you already have a plan, carry on from the clinic case below.
It does. The length of an appointment is not fixed to a trade inside the system; a clinic, a salon and a workshop do not book the same hour, and yours comes from your own work. AlgoRandevu, which we are still building, keeps appointment length configurable inside the product. Put your trade and how long one appointment runs into the quote form.
Only as many as the hour can hold. You do not set that number when a booking comes in; the ceiling is defined together with the hour, so nobody checks the day's list to decide. Pilatesco cannot write an unlimited number of people into one hour, and the ceiling comes from the instructor and the equipment in that hour. The studio case below shows where the ceiling comes from.
You do; the software only enforces what you wrote. Pilatesco treats a cancellation, a no-show and a completed class as separate movements on a member's package balance, and its rule fixes which of them hands the credit back. Once your rule is written the same way, whether a credit came back is no longer settled in a chat thread; it is read off the record. Put your rule into the quote form, and the studio case below shows it in use.
