At 9:20 on the morning of October 14th, the controller for a beachfront property group opened the month's Microsoft invoice and counted 412 seats. Payroll had 46 people on it. The last seasonal crew had been thanked and sent home on September 28th, and three of them had already texted the general manager asking whether their email still worked, because it did.

The invoice was not a mistake. It was arithmetic that had been set in motion on March 3rd and that nobody had been assigned to reverse.

"We will just drop them in October"

That sentence is said in every seasonal market, in March, in good faith, and it is the load-bearing assumption of the whole staffing plan.

It deserves more respect than it usually gets, because it describes how nearly every subscription a person deals with in their own life behaves. Cancel the streaming service, the charge stops. Reduce a seat count, the bill drops. And it was closer to true under older cloud licensing programs, where mid-term seat reductions were routine. The instinct is not stupid. It is a reasonable generalization from every other subscription anyone has ever managed.

It is also, under Microsoft's current commerce terms, wrong in a specific and expensive way.

What an annual term actually commits you to

Microsoft's own partner documentation is unambiguous on the mechanics, and they are worth reading rather than paraphrasing from memory:

  • You can increase seats mid-term at any time, with no restriction. Adding is always easy. This is the half of the rule everyone knows, and it is why March goes so smoothly.
  • You can decrease seats only within seven days of when those licenses were added. That window applies whether the licenses were added at initial purchase, at renewal, or mid-term. After seven days the reduction is blocked outright — Partner Center returns an error — until the next renewal window opens.
  • Cancellation with a prorated refund is available only in the first seven days of a term. Microsoft documents this as 168 hours from provisioning. After that, the subscription is billed for the full term regardless of whether anyone signs in.
  • The cancellation window does not reopen until the subscription itself renews. It is not an annual allowance you can spend whenever you like.

Run that against the calendar. Seats added on March 3rd to an annual-term subscription had a reduction window that closed on March 10th, roughly three weeks before the first seasonal hire finished onboarding. Everything after that bills to the subscription's anniversary. If the anniversary is in March, you pay for the empty seats through the winter — every month of the off-season, at full rate, for people who left in September.

There is one more trap in the renewal mechanics that catches people who did plan ahead. You can schedule a seat reduction to take effect at renewal, but it requires the subscription to be active with auto-renew on — and Microsoft documents that saved scheduled changes are deleted if you subsequently cancel the subscription, turn off auto-renew, change the quantity, upgrade the SKU, or convert a trial mid-term. Which means the manager who scheduled an October reduction back in April, and then added four seats in July because someone quit, quietly erased it.

Monthly at a premium, or annual at a discount — choose it deliberately

The alternative exists and it is not a secret. Monthly-term subscriptions can be reduced during each month's modification window. They carry roughly a twenty percent premium per seat over the annual term, and an annual commitment paid in monthly installments carries a smaller premium of about five percent for new orders and renewals placed on or after April 1, 2025.

That is the whole trade, and it is a genuine trade rather than a trick. Annual is cheaper per seat and rigid. Monthly is more expensive per seat and flexible. Neither is the right answer for the whole company.

The right answer is two subscriptions:

  • Put your baseline on the annual term. The baseline is not your average headcount and it is not your winter headcount. It is the number of seats that were licensed in every single month over the last twenty-four — the floor, not the mean. Pull the actual numbers rather than estimating; the floor is almost always higher than people guess, because a handful of shoulder-season roles never actually left.
  • Put the seasonal swing on the monthly term. You pay the premium only on the seats that swing. On a 40-to-400 pattern, paying twenty percent more for 360 seats during seven months beats paying full rate for 360 seats during twelve.

Do this arithmetic in January, on paper, before the first March hire. It is a twenty-minute exercise that decides five figures.

The identities outlive the season too

Offboarding one person is a checklist. Offboarding 354 people across nine days in October is a schedule, and a schedule only exists if somebody wrote a date down in March.

What happens when nobody does is not dramatic. The accounts simply stay enabled. They stop being watched, because nobody is looking at sign-in logs for a seasonal cashier in November. They keep whatever passwords were set during a rushed onboarding week, which in a 10x hiring push means a meaningful number were set to a shared pattern. They remain valid targets for credential stuffing for as long as they exist, and they keep counting against a license total you are already paying for.

Disabling and deleting are different operations with different consequences, and both matter:

  • Blocking sign-in and removing a license are two separate actions. Disabling an account stops the person from logging in. It does not detach the license. If you disable 354 accounts and stop there, the October invoice looks exactly the same.
  • A deleted account is recoverable for 30 days, then it is not. Microsoft documents that after 30 days permanent deletion begins automatically and cannot be halted, and that a permanently deleted user cannot be restored by anyone, including Microsoft support. Worth knowing in the other direction too: restoring a deleted user restores the licenses that were assigned at deletion even if none are available, which can put you temporarily over your purchased count.
  • The OneDrive has its own clock. By default a deleted user's OneDrive is retained for 30 days — configurable anywhere from 30 to 3,650 days — after which it moves to the site collection recycle bin for 93 days and is then permanently deleted. Separately, an unlicensed account's content is archived on its 93rd unlicensed day. If a seasonal supervisor kept the season's schedules and incident notes in their OneDrive, that content has a deletion date whether or not anyone chose it.
  • Convert the mailbox before you delete the user. A shared mailbox needs no license up to 50 GB. Past that, or if you need in-place archiving or litigation hold, it needs Exchange Online Plan 2. Note the failure mode at the limit: the mailbox can receive for a while, then can no longer send, then stops receiving and senders start getting non-delivery reports. Sign-in on shared mailboxes should stay blocked.

The only version of this that survives a 10x swing is a deprovisioning date set at hire. Not a reminder, not a spreadsheet someone maintains — a date entered in the same ten minutes the account is created, tied to the seasonal end date on the offer, and enforced by something that runs whether or not anyone remembers.

POS offline mode has a number, and it is usually yours to set

Every point-of-sale vendor advertises offline mode. Very few publish where it ends, and the answer is not one number — it is several, most of which are configuration you own.

There are two distinct mechanisms, and conflating them is where the confusion starts. Offline EMV lets the chip and the terminal approve a transaction below a configured floor limit without contacting the issuer. Store-and-forward simply approves the payment with no verification at all, encrypts the card data locally, and transmits it when connectivity returns. The second one is what most small merchants are actually running.

The limits vary by processor, terminal, card scheme, and your own settings, but the shape is consistent. Adyen, which documents this more plainly than most, describes configurable chip and contactless floor limits for offline EMV, and for store-and-forward a maximum amount per transaction, a maximum number of offline transactions per terminal, and a maximum offline refund amount — with transactions exceeding those limits declined outright. Their liability language is equally plain: the merchant is fully liable for failed captures, chargebacks, and disputes on payments processed offline.

Square publishes a configurable per-transaction maximum between one dollar and fifty thousand, and two clocks: on a Square Reader or Stand you have 24 hours to keep accepting offline payments, and pending offline payments expire after 72 hours if the device has not reconnected and uploaded them. Square states the merchant is responsible for expired, declined, or disputed offline payments, and that it will not provide customer contact information to chase them. Notably, several tender types do not work offline at all — Afterpay, Cash App Pay, Square gift cards, Tap to Pay on iPhone and Android, and manually keyed cards.

Toast lets you configure a per-transaction dollar limit above which a manager approval is required, notes the limit excludes gratuity, recommends devices return online within three days and preferably 24 hours, and states plainly that the restaurant is responsible for declined, expired, or disputed offline payments.

Hour six of a busy Saturday

The circuit drops at 11:40 a.m. on the second Saturday in July. Nobody notices, because the terminals fall back to store-and-forward and keep printing receipts. The line moves.

By mid-afternoon three things are happening at once. Tap-to-pay and gift cards have already stopped working, which in a beach market is a real share of tenders and is the first thing a guest complains about. The offline transaction counter on each terminal is climbing toward whatever cap someone configured — or worse, toward whatever cap the terminal shipped with, because nobody configured one. And every approval taken since 11:40 is an unverified promise sitting encrypted on a device.

When the count or the cumulative amount cap is hit, terminals start declining, and they decline in the middle of a rush with a line out the door. When connectivity returns, the batch uploads and some of it comes back declined — insufficient funds, closed accounts, holds — for guests who ate, checked out, and drove back to Georgia. You have their receipt and no way to reach them.

Two numbers should be written on the back office wall before the season starts: the per-terminal offline cap, and the number of hours before pending offline payments expire. Both are configuration. Both have a default that somebody else picked.

The guest Wi-Fi fails on client count, not bandwidth

In February, 60 guests bring maybe 90 devices and the network is flawless. In July, 400 guests bring 900 — phones, watches, tablets, streaming sticks, a portable speaker, two work laptops. Bandwidth utilization may still look modest. The network falls over anyway.

The distinction that explains it is association capacity versus throughput. Meraki publishes theoretical maximums of 256 clients per radio on Wi-Fi 5 Wave 2, 512 per radio on Wi-Fi 6, and up to 1,536 clients per access point on Wi-Fi 6E and 7 — and states directly that these are theoretical, that interference from many clients transmitting simultaneously drives the real limit far lower, and that these are explicitly not numbers to design against. Airtime is the constraint, not the pipe. Every associated device consumes airtime whether or not it is doing anything useful, and a hundred idle phones beaconing on one radio degrade the experience of the twenty that are actually browsing.

What actually breaks first, in rough order: the DHCP scope runs out of addresses, so devices associate and then get nothing. Then airtime saturates and latency climbs while a speed test run standing next to the access point still returns a fine number, which is why the first four troubleshooting attempts go nowhere. Then per-AP client tables fill and devices start bouncing between radios. The symptom guests report is always the same three words — connected, no internet — and it never points at the real cause.

None of this is a knock on whoever sized the system, who most likely walked the property in February and measured coverage honestly. Coverage was never the variable. Device count per access point at peak occupancy was, and it is not something a February site survey can see.

The arithmetic to do in January

Four numbers, decided on purpose rather than discovered in October:

The seat floor across the last twenty-four months, and which subscription term each block of seats sits on. The deprovisioning date for every seasonal identity, entered the same day the account is created. The per-terminal offline transaction cap and expiry window, set rather than inherited. And peak device count per access point — devices, not guests, at roughly two and a half per head.

The season ends on a date everyone knows. The commitments do not.