Nobody Should Manage a Night Cap by Hand

Nobody Should Manage a Night Cap by Hand

Suppose you do the responsible thing. Your city caps letting at ninety nights a year, you know it, and you decide to stay under.

Here is the job you have just taken on. Once a month, open the calendar. Count the nights already let, and the nights still open. Work out where that lands you by December. If it lands you over, decide which nights to close. Go and close them. Remember that a booking cancelled last week has given you a night back, and that the new iCal feed you connected has quietly added nights you did not count. Then do it again next month. Then do it for the second property. Then do it every year, forever.

Nobody does this. Not because hosts are careless, but because the task has the worst possible shape: it is dull, it is monthly, it has no deadline, and getting it wrong produces no signal at all. You do not find out you are over. You find out eleven months later, or when somebody official asks.

The failure mode is doing nothing

Most admin fails loudly. An unpaid invoice chases you. A double booking produces an angry guest. A night cap does neither. The calendar keeps selling, the money keeps arriving, and the number keeps climbing — and the only evidence that anything is wrong is a figure nobody is looking at.

That is the case for automating it, and it is a narrower case than “automate everything”. The counting should be automatic because counting is arithmetic and you will not do it. Whether to close inventory is a revenue decision, and revenue decisions should not happen behind your back.

So the honest version of “set it once” is two different promises:

  • The count, the forecast and the warning are automatic. Always on, no opt-in needed.
  • Closing nights is opt-in, per property, with guardrails you set. Off by default, and it tells you what it proposes before it does anything.

What automatic closing has to get right

Handing over the calendar is a real risk, so the controls matter more than the feature. Four of them do the work.

A protected horizon

The automation must never touch the next stretch of your calendar. Those are the weeks with enquiries in flight, deposits taken and guests mid-decision — exactly the nights where an unexpected block does damage. You set how far ahead is untouchable, and nothing inside it is ever closed automatically.

This is also what makes the whole thing safe to switch on in the first place. The worst case is a mistake months away, with months to notice it.

A cap per run

It runs weekly and may close only so many nights each time. That is a brake on error, not a limitation: if the forecast moves for a bad reason — a feed hiccup, a batch of cancellations misread — you get a small wrong block you can see and undo, rather than a quarter of your year gone in one pass.

A target, not a cliff edge

You do not aim at the limit. You aim at a percentage of it, and the automation works toward that. Arriving at exactly ninety of ninety in October leaves you no room for a booking you actually want, and no room for the count to move. Sitting at eighty-five with a fortnight spare is a position you can still make decisions from.

Blocks you can take back

Every night the automation closes is tagged as its own, shown as its own, and removable by you in one action. If it has closed a week you want back, you take it back and the next run respects that. An automatic block that cannot be undone is not automation, it is a lock.

Cheapest first, in runs

When it does close nights, it closes the ones you were least likely to sell well — the year ranked against your own seasonal rates, working upward from the bottom — and it takes them out in contiguous ranges rather than scattering single days through the shoulder season. A lone closed Tuesday in May does not just cost you that Tuesday; it creates a one-night gap that no minimum stay will let anyone book.

Your rates are the starting point. Once a year or more of your bookings is in Airflow, the ranking also weighs how often each month has actually sold, so a cheap month that always fills is kept open ahead of a dearer one that never does.

That ranking is the interesting half of this, and it has its own article: Which Nights Should You Give Up?

The honest part

It closes more than a quiet host strictly needs. Where a rule counts nights let rather than nights offered — London, Amsterdam, Paris — planning has to treat every open night as a night that might sell. The guarantee it gives you is “even if everything sold, you stay under”, which is a strong guarantee and a conservative one. If your winter rarely fills, it will close nights you would never have let anyway. That trade is the reason it is opt-in rather than on by default, and the reason the protected horizon and the target are yours to set rather than ours.

It is only as good as the calendars it can see. A channel that is not connected is a channel whose bookings are invisible, and a count built on half your bookings is an undercount. If you take anything from this article, take that one: connect every feed before you trust the number, not after.

It never tells you that you are compliant. It will tell you that you are at 75% of the threshold you set, that you are forecast to cross it on a particular date, and which nights it would close to stop that. Compliance is a legal conclusion about your circumstances, and a measurement tool has no business claiming it. What you get is the number and the working — which is what an inspector actually asks for, as we covered in What to Show an Inspector.

Where it earns its keep: more than one property

For a single listing, a diligent host with a reminder in their phone can keep up. The case gets much stronger at three.

Three properties under a night cap is three separate counts, three forecasts, three sets of nights to rank, three calendars to close — and the limits may differ, because the rule usually attaches to the property rather than to you. That is no longer a monthly chore, it is a standing job. Automated, it is a portfolio summary you glance at: which properties are comfortable, which are tightening, and which have already had nights closed on your behalf this week.

The same logic runs through most of what we automate — see the automation and workflows page for the rest of it, and Let Owners Block Their Own Dates for the other half of who gets to close a night.

What to do this week

  1. Create an account — start free; a card is needed at sign-up.
  2. Connect every calendar you let through, not just the busiest one. An incomplete feed is the single biggest cause of a wrong count.
  3. Turn on the letting limit for each property and pick your city’s rule from the list.
  4. Leave automatic closing off for a month. Watch what it would have proposed, check it against your own judgement, and switch it on when the proposals stop surprising you.

That last step is not a disclaimer. It is how you should adopt any automation that touches inventory: let it be right in public for a while before you let it act.

Checked 2026-10-02: London’s cap is 90 nights per calendar year under section 25 of the Greater London Council (General Powers) Act 1973, as amended by section 44 of the Deregulation Act 2015, with a further condition on council-tax liability — see the Greater London Authority’s guidance and GOV.UK. Limits change, and some cities are tightening them; check your own before relying on any article’s number.

Start free →


Related: Which Nights Should You Give Up?, A Night Cap Is an Accounting Problem, Not a Calendar Problem, and London’s 90 Nights: How to Count Them Before the Council Does.