Work out what a first version of no-show protection should be for Everwood: what a business can set, what a customer agrees to, and whether any of it needs us to start taking money from customers.
I framed it as a pricing question and researched deposits, prepayment and cards held on file. A cancellation in Everwood is stored as a change of state with no time and no actor attached, so the product cannot tell a late cancellation from an early one, or the customer's cancellation from the business's own.
You cannot enforce a rule you cannot prove was broken. Writing the rule down is the first half. Keeping enough of what happened to judge it is the half that looks like plumbing and gets skipped.
The Build
Nothing shipped from this research. There is no cancellation policy in Everwood, no deposit, no card held anywhere, no fee, and no setting a business can change to protect their time. The roadmap node this came from is at the idea stage and it is still at the idea stage.
The problem is the one every appointment business has. Somebody books a two hour slot on Saturday morning, and then they do not turn up. Nobody else could book that time because it was taken. The chair sits empty, the staff member is paid or is not paid, and the money for that morning does not exist.
I went into this expecting the question to be how much to charge and when. Flat deposit, percentage of the service, full prepayment, or a card kept on file and charged only if somebody misses. That is the shape the question takes everywhere I looked, and it is the shape my own research came back in.
I now think that question sits about two steps further along than we are.
The Problem
Here is what I found when I read our own booking code instead of the research.
Everwood already knows what a no-show is. A business can mark an appointment as one from their dashboard, and once marked, the appointment is closed. It cannot move on to anything else. That is a sensible design and it was built long before anybody asked for protection.
What happens next is nothing. The mark is a label. No fee, no message, no rule consulted, no record of a policy the customer agreed to, because there is no policy to agree to. The business gets a word on a screen that means their morning went badly.
Fine. Everyone knows that part is missing. Build Note #016 already found there is no cancellation rule anywhere in the product.
The part I did not expect is the cancellation itself.
When an appointment is cancelled in Everwood, what gets written down is that it is now cancelled. That is the whole record. Not when the cancellation happened. Not who did it. Not why.
Sit with that for a second, because it took me a while.
A customer who cancels on Tuesday for an appointment two weeks on Friday, and a customer who cancels at twenty to nine for a nine o'clock appointment, produce records that are identical. There is no field that separates them. Nothing anywhere in the product can look at a cancelled appointment and say whether the rules were followed, because the moment it happened was never kept.
Which means late cancellation is not a thing Everwood can currently recognise. It is a phrase from the research. In our data it does not exist.
The same gap swallows a second question, and this one is worse, because it is the case where getting it wrong is unfair to a person. If a business cancels an appointment, because a staff member is off sick or the day has to be rearranged, that is recorded exactly the same way as the customer cancelling. Same word. Same absence of a time. So any feature that counts cancellations against a customer would, on today's record, count the ones the business caused.
There is one more piece and it changes what a first version can even promise.
Everwood sends one automatic reminder. It goes out when the appointment is about half an hour away.
That is a good reminder for what it is, which is a nudge to somebody who is about to be late. It is not the reminder a cancellation policy needs. A business setting a rule that says give me a day's notice is relying on the customer being asked while a day's notice is still possible. Ours arrives long after that window has shut. On the day we ship a cutoff, the last thing we send a customer is a message that arrives too late to act on.
Assumption vs Reality
Protection is a payments feature and Everwood cannot do payments yet, so this node is blocked until we are ready to take money from customers. The smaller version people suggest, showing a policy and asking the customer to tick a box, is the consolation prize. Real protection is a deposit or a card on file, and everything short of that is a sign in the window that nobody reads.
The research made the payments half sound harder than I expected, which was useful, and then the part that changed my mind was not in the research at all. The half I was calling the consolation prize is not a weaker version of the deposit. It is the first half of the deposit. Think about what actually happens when a business charges somebody for missing an appointment and that person disagrees. The business does not win that argument by having taken a card. Everybody has taken a card. They win it, according to the account in my research, by producing what the customer agreed to, the time they agreed to it, and the record of when they cancelled. I have not verified those mechanics with a card network and I am not going to pretend I have. It does not change the direction, because the same three things are what you need to answer the customer directly, before anyone else is involved. Every one of those three is a record. Not one of them is money. So the order I had was backwards. I thought the policy work was what you do while waiting to build payments. The policy and the record are what makes a charge defensible once it exists, and we do not have them. There is a second reason the ordering matters, and it is about what we would be turning Everwood into. Taking a deposit is not a feature we add to booking. It makes us a business that holds other people's money and gives it back. Refunds when a business cancels. Refunds when an owner decides to be kind. Disputes that somebody has to answer within a deadline. Money sitting somewhere overnight. We have written none of this, ever, for anybody: there is no customer payment anywhere in Everwood, and the billing we run for businesses subscribing to us is still partly manual. This would not be an extension of something we do. It would be the first of it.
The Fix
What changed is the design, not the code. Four things I now believe.
The record comes first, and it is worth building on its own. Keep the moment a cancellation happened, who asked for it, and how much notice that left. That is a small piece of work and it is not a payments feature, and it would immediately let a business see something they cannot see today, which is how many of last month's cancellations landed inside a day of the appointment. Nobody is charged. The business finally knows whether they have a problem, which is the question I cannot answer for a single Everwood business right now.
Whose cancellation it was has to be part of the record from the first day, not added later. A business cancelling is not a lesser version of a customer cancelling, it is the opposite event, and it is the one case where every consequence in this feature has to be switched off. If that distinction is not in the record from the start, the first version of any fee, count, or reliability figure is silently wrong about the customers whose appointments we took away from them.
The policy has to be visible before it can be enforced, and the reminder has to arrive before the cutoff. Right now our confirmation email tells the customer to contact the business if they need to cancel, and says nothing about what the business expects, because the business has no way to tell us. Showing the rule at booking, in the confirmation, and on the appointment itself is most of the value of a policy, and it is available without charging anybody. The reminder is the other half. A cutoff nobody is warned about before it passes is a trap, and the warning we send today arrives after it.
Then, and only then, is the deposit question worth opening. Not because deposits are wrong. Because on the other side of the record we would be choosing between charging for something we can now prove, and charging for something we cannot.
I want to be straight about the strongest objection to all of this. An owner who is losing a morning a week does not want a better record of losing it, they want the money, and telling them the first release is a set of timestamps is a real answer to a problem they did not ask about. I think that is fair, and I still think the order holds, because the version where we take money first is the version where the first disputed charge has nothing behind it.
You cannot enforce a rule you cannot prove was broken. Build Note #016 ended on a nearby idea, that you cannot enforce a rule nobody has written down. This is the next one along and it is the one I keep missing. Writing the rule is not enough. The product also has to keep enough of what happened to tell whether the rule was kept, and that part looks like plumbing so it never makes it into the plan. It is worth naming why this hides so well. A status is a fact about the present: this appointment is cancelled. It is easy to store, it is what the screen needs, and it answers almost every question anybody asks day to day. The questions it cannot answer are the ones that arrive later, and they all sound the same. When did that happen. Who did it. Was that within the rules. By the time somebody asks, the answer is gone, and it was never deleted, it was simply never written. The general version. When a feature depends on judging whether something was acceptable, check whether the product keeps the event or only the outcome. If it keeps only the outcome, that is the first piece of work, and the feature everybody is discussing is the second.
For a salon owner, here is the honest position. Everwood cannot protect you from no-shows today. You can mark somebody as a no-show after the fact and that is where it ends: no fee, no deposit, no rule of yours that we show your customers, because there is nowhere for you to write one down. There is something smaller I did not expect to find, and it matters more than it sounds. If somebody cancels on you, we keep the fact that it was cancelled and not when. So we cannot tell you how many people cancelled last month with less than an hour's notice. You know it, because you lived it. Your booking system does not, and that means nothing I build on top of it can tell the difference between a customer who gave you a fortnight and one who left you standing at the door. That is why I am not starting with deposits. If I built a late cancellation fee on what we keep today, it would be charging people on a guess, and the first customer to argue with it would be right. What I would rather give you first is your rule, written where your customers see it before they book, and a record of who cancelled and when. That will not take money off anybody. It will tell you, for the first time, whether late cancellations are actually your problem or whether the ones that hurt are the people who never say anything at all. Those two problems have different answers and right now they look identical. If it turns out you need deposits, we will get there. I would rather be able to prove the thing before we charge for it.
Builder Notes
A research pass on no-show protection that turned into reading what our booking data keeps when an appointment is cancelled. Nothing was built. No policy, deposit, fee, or card capture exists.
Technical Note 1
Shipped today: an appointment can be marked as a no-show, and doing so closes it permanently. Nothing follows from the mark. It is a label on a screen with no rule, fee, or message attached.
Technical Note 2
Cancelling an appointment writes one thing, which is that the appointment is now cancelled. No time, no actor, no reason. I went looking for a stored cancellation time under every name I could think of and there is not one anywhere in the product.
Technical Note 3
That single absence is what makes the rest of this node unenforceable rather than impossible. Late cancellation, notice period, and reliability all describe a relationship between two moments, and we keep one of them.
Technical Note 4
Business-caused and customer-caused cancellations are the same record. This is the one I would fix first even if the rest of the node were dropped, because every possible consequence of a cancellation has to be switched off for the case where the business cancelled, and today nothing can tell them apart.
Technical Note 5
The only automatic reminder we send goes out when the appointment is roughly half an hour away, on a job that wakes up every quarter of an hour. It is a useful nudge and it is not a notice-period reminder. Any cutoff longer than about half an hour ships without a warning attached.
Technical Note 6
No cancellation policy exists in a business's booking settings. The only time rule anywhere is a minimum notice for making a new booking, which defaults to an hour, and it is a different rule pointed the other way.
Technical Note 7
Everwood takes no payment from customers, anywhere, in any flow. There is no payment library in the project at all. The billing code that exists is for businesses subscribing to us, and it still describes processor-managed subscriptions as a future state. Deposits would not be an extension of our payment handling. They would be the beginning of it.
Technical Note 8
From Square's own documentation, verified while writing an earlier note: a merchant-set cutoff selectable from one hour up to two weeks or switched off entirely, and a no-show fee charged as a flat amount per appointment, a flat amount per service, or a percentage of the service price. Useful mostly as proof that the cutoff is the load-bearing setting and the fee is a shape chosen afterwards.
Technical Note 9
Reported by merchants in my research and not verified: that cards captured for no-show fees decline when the fee is finally charged, and that owners want room to waive a fee for a regular without fighting the software. Reported by customers and not verified: that being asked for a card for a short or free appointment is where they give up, and that a charge appearing later than expected is what turns a policy into a complaint. No figures survived on either side.
Technical Note 10
Also reported and not verified, and worth checking properly before any deposit work: that refunding a deposit does not return the processing fee to the business. If that holds, every refund a kind owner issues costs them money, and it argues for the refund path being designed before the charging path.
Technical Note 11
Cut from the research and kept in the ledger: every no-show prevalence range, every cost and revenue figure, the checkout abandonment percentages, the dispute fees and win rates, the named card-network codes and compliance levels, and the grace period ranges attributed to individual platforms. Not one arrived with a source I could follow. The research is a good map of what these systems do and it produced no number I could stand behind.
Technical Note 12
Third time, and I am going to keep recording it: the research came back with a finished public article attached, written as though the feature exists. It describes policies, deposits and protection at Everwood in the present tense. It is well written and one copy and paste would have published it.
Before / After
- The hard part is deciding what to charge and when
- Protection is blocked until we can take payments
- Showing a policy is the weak version of a deposit
- The reminder we send is a solved piece of the system
- A cancellation is a booking that ended
- The hard part is being able to tell that a rule was broken
- Protection depends on a record we could write next week
- Showing a policy is the first half of taking a deposit
- The reminder we send arrives after any cutoff worth setting
- A cancellation is an event with a time, and we kept only the outcome
What I'd Do Differently
I would have looked at what we store before commissioning research on what to charge.
I sent out a question about pricing models and got back a careful comparison of pricing models. Every option in it, without exception, assumes the system underneath can say when a customer cancelled. Ours cannot, that is one afternoon's reading of our own code, and it invalidates the framing of the entire document rather than one section of it.
The general version. Research about what a product should do is only as good as the description of what it currently does, and I am the only one who can supply that half. When I skip it, what comes back is a correct answer to a question about somebody else's product.