Inventory Forecasting

What you asked for

Stop staff from noticing that something is running low. Instead:

Current stock → Expected consumption → Minimum required stock → Recommended order quantity

Driven by current inventory plus upcoming occupancy plus expected consumption, for amenities, toiletries, water, cleaning supplies and linens. Purchasing stays human-approved.

This is the most tractable module in the handbook. The maths is a century old, borrowed wholesale from hotel housekeeping and standard inventory theory. The only genuinely new part is wiring it to your booking calendar.

The one insight that makes it work

Consumption is driven by turnovers, not by occupancy. A seven-night stay consumes roughly one set of linens and one set of welcome amenities; seven one-night stays consume seven of each. Any forecast built on occupancy percentage will systematically under-order in high-churn periods and over-order in long-stay periods.

So model two drivers per item:

• Per-turnover consumption — linens, towels, welcome amenities, bathroom consumables replaced between guests, cleaning chemicals.
• Per-guest-night consumption — water, coffee, tea, toilet paper, shampoo in bulk dispensers.

Most items are a blend. Store both coefficients and let the data settle them.

The formulas

Use these exactly; they are the standard hospitality and APICS forms, and writing them down explicitly is what makes the forecast auditable.

Consumption per occupied room (CPOR) — your baseline coefficient, learned from history:

CPOR = total consumption of item over period ÷ occupied room-nights in same period
CPTO = total consumption of item over period ÷ turnovers in same period

Forecast consumption — from the booking calendar:

Forecast = (CPTO × forecast turnovers) + (CPOR × forecast occupied room-nights)

Par level — the standard hospitality target stock:

Par level = average daily usage × days between deliveries (lead time) + safety stock

Linen par specifically — the industry rule is 3–5 par: one set on the bed, one in the wash or in transit, one on the shelf as buffer. Three is the floor; go to four or five where laundry turnaround is slow or off-site, or standards are high.

Linen par = (occupied rooms × sets per room × laundry turnaround days) + safety stock

Reorder point — the trigger:

ROP = (average daily usage × lead time in days) + safety stock

Safety stock — statistical form, where Z is the service-level factor (1.65 ≈ 95%), σd the standard deviation of daily demand:

Safety stock = Z × σd × √(lead time)

Or, when both demand and lead time vary — which is your Bali situation:

Safety stock = Z × √[(lead time × σd²) + (average daily usage² × σLT²)]

And the practical version, usable before you have variance data:

Safety stock = (max daily usage × max lead time) − (avg daily usage × avg lead time)

Recommended order quantity — what the screen actually shows:

Order qty = max(0, par level − (on hand + on order) + forecast consumption over lead time)

Round up to supplier case size. Show the rounding.

Why Japan and Bali need different numbers

This is the single most important operational nuance in this chapter, and it is a parameter, not a special case: lead time and lead-time variance differ by an order of magnitude between your two regions.

Domestic Japanese restock of hotel-grade consumables is fast and predictable — often next-day, with reliable suppliers and Amazon Business as a fallback. Bali imports of specific hotel-grade supplies can run weeks, with meaningful variance around customs and shipping.

Consequences, all of which fall out of the formulas above rather than needing bespoke logic:

• Safety stock in Bali will be several times Japan's for the same item and consumption rate, because both lead time and σLT are larger.
• Local-substitute sourcing is a real lever in Bali, and worth modelling: a locally available item with a two-day lead time may beat a preferred imported item on total cost once you price the working capital tied up in safety stock.
• Order cadence should differ by region, not be forced onto one weekly cycle.

Store lead_time_days and lead_time_variance per supplier-item-location, never as a global constant.

How it should be built

Data model

Five tables and it is done:

• items — SKU, category, unit, case size, per-turnover and per-guest-night coefficients.
• locations — a storage location, which may be a unit, a building, or a regional store. Multi-echelon matters: at scale you will hold a regional buffer and push to units.
• stock_levels — item × location × quantity on hand, plus counted_at.
• movements — every deduction, delivery, transfer and adjustment, append-only. This is the source of truth; stock_levels is a cached projection of it.
• purchase_orders — supplier, items, quantities, expected arrival, status.

Getting stock counts without asking anyone to do inventory

The hard part of every inventory system is not the maths, it is the count. Three mechanisms, in order of preference:

1. Implicit deduction. When a turnover is marked done, deduct the standard kit for that unit type automatically. No one types anything. This gets you 80% accuracy for free and it is the reason the inventory module must live in the same spine as the task module.
2. Exception reporting in LINE. A rich-menu button: Stock request. Cleaner taps the item, taps a quantity, done — three taps in the app they already have open. Also the natural home for "used two extra towel sets, guest had a spill."
3. Periodic cycle counts. Not a full stocktake. Count a rotating subset — the ten highest-value or highest-variance items — monthly per location, via a LIFF screen with the expected number pre-filled so the counter is confirming rather than transcribing. Discrepancies feed a shrinkage rate per location, which is itself a management signal.

The recommendation screen

Exactly the shape you asked for, per item per location, sorted by urgency:

Bath towels — Bali · Canggu store

  On hand                                   84
  On order                                  0
  Forecast use (next 21 days)              132   ← 44 turnovers × 3.0
  Par level                                150   ← 21d lead time + safety 45
  ──────────────────────────────────────────────
  RECOMMENDED ORDER          180 (3 cases of 60)   [Approve] [Edit] [Snooze]

  Why: lead time 21d (σ 6d) · stockout risk 34% without order
  Last 3 orders: 120 @ Rp… (Mar) · 120 (Jan) · 180 (Nov)

Group approvals by supplier so one screen becomes one purchase order. The friction you are removing is not the ordering, it is the noticing — so the default state of this screen should be empty, and its appearing should mean something.

Alerts that earn their place

• Stockout risk above a threshold within the lead-time window. This is the only alert that should interrupt anyone.
• Anomalous consumption — an item running materially above its CPOR for a unit. Usually a leak, a theft, a miscount, or a genuine guest-behaviour change; all four are worth knowing.
• Dead stock — no movement in 90 days. Working capital sitting in a cupboard, and at 200 units it adds up.

Tools

Be honest about scale here. Google Sheets with these formulas is genuinely adequate below about 20 units, and there is no shame in starting there while the spine is being built — especially since you can feed it a PMS occupancy export.

Sortly and inFlow add barcode/QR scanning, low-stock alerts and multi-location tracking, which becomes real once you have several Bali villas plus Japanese properties with separate storage. Neither ingests an occupancy forecast, so you would still be computing the forecast yourself and feeding it in — meaning they buy you the counting UI, not the intelligence.

Hotel procurement modules (Oracle Materials Control, Adaco, or the built-in modules in large PMSs) do CPOR forecasting natively and properly, and are cost-prohibitive and operationally heavy for a distributed STR portfolio.

Recommendation: build this into the spine rather than buying, because it is small (five tables and eight formulas), because the value comes entirely from its connection to turnovers and the booking calendar which no standalone tool has, and because the same LINE channel and the same task app already exist by the time you get here. This is the cheapest module to build and the one with the clearest payback.

Effort and risk

Effort: low. Genuinely the smallest build here — a few tables, the formulas above, one approval screen and one LINE button. The work is in the coefficients, and those come from three months of data, not from engineering.

Risk: low, with one honest caveat. Inventory systems degrade when counts drift, and counts drift when nobody counts. The mitigation is architectural: implicit deduction from turnovers means the system stays roughly right without human effort, and cycle counts on a small rotating subset keep it honest. Do not build a system that requires a full monthly stocktake; it will be done twice and then never again.

Decisions for you

1. Standard kits per unit type. Someone has to write down what a turnover consumes. This is a two-hour job and it unblocks everything.
2. Where does stock live? Per-unit cupboards, per-building stores, or a regional store with distribution? This determines whether you need multi-echelon logic now or later.
3. Who approves purchase orders, and above what value? A yen/rupiah threshold for auto-approval of routine consumables would remove most of the remaining friction.
4. Suppliers and real lead times per region. Ask each supplier for their actual lead time and how often they miss it. That number, not the maths, determines your working capital.