Stop-Sell Needs a Reason
The red row on a channel manager’s screen should not leave only one message: closed.
Stop-sell is not just removing a room type from channels. Closure reason, affected scope, reopening condition, owner, and expiry decide whether supplier operations, revenue, and support can act from the same list.
At 10:20 a.m., a channel manager pulls the stop-sell list onto a second monitor. Three hotels, seven room types, a column of red switches. Someone in the group chat says, “Close it first so we do not sell the wrong thing.” Revenue asks whether this is a rate error, inventory anomaly, or unconfirmed contract term. Supplier operations sees only one state: closed.
Closing a room type is a fast action. The trouble is that fast actions leave slow questions behind. Closing because of oversell risk is not the same as closing because tax rules are unclear. Reopening automatically after hotel confirmation is not the same as requiring a manual release. If the list only says closed, everyone downstream has to guess: should quotes keep moving, can another channel sell it, and can support mention a recovery time?
The tradeoff sits backstage, but it shapes the sellable list. Make the reason too broad and stop-sell becomes a black box. Make it too detailed and channel teams drown in internal wording. A useful stop-sell record pins down a few plain things: affected scope, reason category, trigger source, reopening condition, expiry, and who is allowed to change it. Miss one, and the red status starts growing its own folklore.
For HotelByte, stop-sell should behave like a traceable operating decision, not a silent switch. Then suppliers know where evidence is missing, revenue knows where not to release price, and support knows which promise should stay unsaid. A room type may be temporarily unsellable. The explanation should not be taken offline with it.