Distinguish block, housekeeping state and category cap
Three tools answer three different operational questions.Use a room block when a specific room cannot physically or operationally be handed to a guest. It reduces category inventory and prevents new assignment.
Housekeeping states describe work on an otherwise usable room. Category caps reduce category sales without identifying a defective physical room.
Classify the event before creating a block. A housekeeping state describes cleaning progress or occupied-room service; it does not remove inventory. A physical room block is required when a concrete unit cannot be sold or used because of defect, maintenance, renovation, safety or a deliberate out-of-service period. A category-level sales cap or pricing restriction answers a different commercial question and must not be imitated by blocking arbitrary rooms. Confirm the observed condition, expected duration and whether a guest stay is affected. For a minor issue that does not prevent safe use, create the appropriate operational task instead of reducing inventory. For a sale-affecting defect, use Rooms and blocks so availability and Booking Engine react. The classification passes when the team can state what is unavailable, why, for which dates and which system must carry the truth without mixing status, block and commercial restriction.
| Situation | Tool | Effect |
|---|---|---|
| Room 204 has water damage | Room block, Repair | Specific room not sellable |
| Room 105 is cleaned after departure | Housekeeping state | Work state, no multi-day block |
| Sell only two of five doubles | Category cap | Sales reduced, no defect assignment |
| Stop selling a category on a date | Category closure | Category closed for sale |
Prepare exact rooms and period
A good block is as narrow and as long as truly necessary.Open Availability and Block rooms. Select exact room numbers using search, category or floor filters. Bulk selection is limited and must reflect the same real outage.
Set inclusive From and Until dates to the real outage. Optional release time documents an expectation but does not release the block automatically.
Prepare the narrowest accurate scope. Select the exact physical room or rooms, the first unusable date and the realistic last affected date, and name the person responsible for release. For a same-day repair, include the expected checkpoint without pretending the room is already available later. Bulk-select rooms only when they share the same cause, period and decision owner; otherwise create separate blocks. Review current and future bookings, arrival times, room features and alternatives before proceeding. A block on one of three category rooms removes one third of maximum physical inventory, so small properties must avoid broad precautionary periods without evidence. Do not block an entire category when only one unit is affected. Record the source of the estimate and next review time. The scope is ready when every selected room is truly affected, every date matches expected operational impact and management understands the sales capacity being removed.
Before selection
- Every room is truly affected.
- Start is the first unusable day.
- End matches realistic restoration.
- Bulk selection shares reason and period.
- An owner knows the release step.
Record an actionable reason and internal note
The reason classifies the case; the note explains this instance.Choose Cleaning only for non-availability beyond normal housekeeping; use Maintenance, Repair, Renovation, Owner use or Other according to the actual case.
Write the affected item, owner, review time and objective release criterion. Avoid sensitive personal data and vague notes such as “broken”.
Choose the real block reason and add an internal note that supports action. State the observed defect or planned work, exact location where useful, safety or guest impact, responsible team, next step and review time. “Broken” or “maintenance” alone is too vague for a later shift. Avoid blame, health speculation or unnecessary personal details; internal visibility is not permission to store an unprofessional narrative. Link the note to a real repair or management decision where that process exists. Do not use a misleading reason merely to obtain a preferred colour or report category. If the end date is uncertain, set a justified review window and keep active responsibility rather than guessing a distant date and forgetting the block. The reason and note pass when a colleague can decide whether the room remains unavailable, whom to contact and what evidence is required for release without calling the original author.
| Reason | Appropriate case | Do not use for |
|---|---|---|
| Cleaning | Exceptional sale-blocking cleaning | Normal departure clean |
| Maintenance | Planned technical work | Uninvestigated defect |
| Repair | Specific defect is repaired | Renovation project |
| Renovation | Longer construction outage | Short routine work |
| Owner use | Deliberate private use | Guest booking |
Resolve booking and block conflicts before saving
Readiness explains which room cannot yet be blocked and why.Once rooms and dates are complete, STRYK checks every room for active bookings, existing blocks and active master data.
Do not hide a real outage by simply removing a conflicted room. Resolve the booking or existing block in its proper workflow, then check again.
Wait for the STRYK availability check and resolve every conflict before saving. A booking conflict means the room has an affected stay and requires a guest-safe alternative or changed scope before it can leave inventory. An existing block may need extension or correction rather than a duplicate. A missing or inactive room record requires master-data repair. Compare exact dates because checkout and next arrival boundaries can look deceptively free. Do not cancel, move or shorten a guest stay solely to make the block form pass; use the authorised booking-change workflow and obtain approval. For each conflict, record owner and resolution, then rerun the check. Save only after STRYK confirms the block. If the action fails, the previous room inventory remains unchanged. The readiness gate passes only when all selected rooms are valid, conflicts are resolved at their source and the saved block cannot overlap an unexplained guest commitment.
| Type | Meaning | Resolution |
|---|---|---|
| Booking | Active stay overlaps | Resolve booking or dates |
| Block | Existing overlapping block | Review existing block, do not duplicate |
| Room missing | Room or category not active | Review master data and choose valid room |
Save the block and prove its calendar effect
Only visible inventory effect makes the form an effective block.Confirm only when every selected room is ready. The STRYK repeats conflict checks while saving so newly created bookings or blocks are not overwritten.
Then check Active blocks, calendar and controlled room selection. Blocks are always shown and reduce physically sellable category inventory.
Save the approved block once and prove the result in connected views. Reopen the active block list and verify room, period, reason, note and status. Open the occupancy calendar and confirm one block segment on the correct physical room without an overlapping active stay. Check room selection and category availability for an affected date: the blocked unit must not be offered, while unaffected rooms remain sellable. Use the Booking Engine draft or live-safe availability path appropriate to the property state and verify public inventory is reduced only where intended. Reload each view so evidence does not come from the form cache. If one layer disagrees, record the room, dates, expected and observed result and escalate; do not create a second block. The block is effective only when calendar, room inventory, PMS availability and Booking Engine share the same STRYK-backed outage.
Save and verify in four views
- 01Confirm readiness
All rooms show no conflict.
Action is enabled. - 02Save once
Confirm and await STRYK response.
Created blocks are visible. - 03Read calendar
Check block bar, reason and dates.
No overlapping stay. - 04Check inventory
Check room selection and category availability.
Blocked room is not sellable.
Understand availability and Booking Engine impact
The block affects physical inventory, not just calendar appearance.STRYK combines active rooms, bookings, room blocks, closures, caps and restrictions. A blocked physical room is excluded from room selection and in STRYK public availability.
Review the daily category effect, especially in small hotels. Caps may reduce inventory further but never increase it beyond physically sellable rooms.
Understand the inventory arithmetic for every affected date. Maximum category inventory comes from active physical rooms. Subtract room blocks and occupied or reserved segments according to the canonical availability rules, then apply any category caps and restrictions without double subtraction. Check at least one date inside, before and after the block. With three rooms and one blocked unit, maximum physical inventory becomes two before bookings; a result of zero or three signals a configuration or calculation problem. Verify multi-night searches because a stay is only available when a suitable unit exists across all nights. Do not compensate by manually increasing a cap or moving a booking without approval. Record the expected calculation and observed result in the test evidence. The impact check passes when PMS and Booking Engine return the same safe availability and the hotel can explain the count from rooms, blocks, bookings and restrictions.
| Measure | Example | Check |
|---|---|---|
| Active rooms | 3 double rooms | Master data active |
| Blocked | 1 room | Reason and dates overlap |
| Physically sellable before bookings | 2 rooms | Active minus blocked |
| After bookings and caps | 0 to 2 rooms | Never above physically sellable |
Release only after real verification
The planned end date prompts review; active release confirms reality.Open Active blocks and verify the work is complete. Technical completion does not automatically make a room ready; housekeeping and quality control may follow.
Release selected blocks and then recheck active blocks, calendar, room selection and category availability. Set housekeeping state to the real post-work condition.
Release the room only after the real cause is resolved and the required safety and quality checks have passed. The planned end date is a review prompt, not proof that repair succeeded. Confirm completed work, test the affected function, document approval and remove or close the active block through the product. Then decide the real housekeeping follow-up: a repaired room may still require cleaning and inspection before Ready. Reopen the block list, calendar, room selection, category availability and Booking Engine availability for dates after release. The unit should return exactly once, without a stale block or premature Ready state. If repair is incomplete, extend the block with an updated reason, owner and review time rather than silently allowing it to expire. The release is complete when the room is technically usable, operational state is truthful, inventory is restored and reception can safely assign the next guest.
| Control | Possible state | Next step |
|---|---|---|
| Repair complete | Room dirty after work | Release block, schedule housekeeping |
| Cleaning complete | Quality check pending | Do not mark ready yet |
| Inspection complete | Vacant, clean and usable | Set Ready |
Release is complete when …
- The real block reason is resolved.
- Required safety and quality checks are complete.
- Block is no longer active.
- Calendar and room selection release it correctly.
- Category availability was rechecked.
- Housekeeping state reflects the real next condition.
