Acknowledgement: Shared by Peter Bamuhigire, techguypeter.com, +256 784 464178.
Use When
- A proposal concerns accommodation, dining, events, catering or hospitality software.
Do Not Use When
- The work is generic strategy with no hospitality operating model; use the core proposal route.
Required Inputs
| Artefact | Source | Required? | If absent |
|---|---|---|---|
| Format, location, capacity, guests, buyer decision and evaluation criteria | Client/tender pack | Yes | Stop and issue a qualified evidence request. |
| Operating, financial, technical and proof evidence | Client/authorised records | Conditional | Mark affected claims NOT_ASSESSED. |
Workflow
- Classify the hospitality format and buyer decision.
- Map guest promise to operations, evidence, risks, acceptance and price.
- Route finance, requirements, website, social and engineering dependencies.
- Reconcile scope, work plan, team, schedule, assumptions and commercial terms.
- Run red-team, anti-slop and release checks; stop on unsupported material claims and recover by narrowing scope or requesting evidence.
Outputs
| Artefact | Consumer | Acceptance condition |
|---|---|---|
| Hospitality proposal route and evidence checklist | Proposal lead and evaluator | Fit, method, proof, owner, risk, acceptance, handoff and price logic are explicit. |
Evidence Produced
| Evidence | Consumer | Acceptance condition |
|---|---|---|
| Claim, requirement, source, oracle and owner map | Reviewer and delivery team | Material claims are sourced or labelled; missing evidence is visible. |
Capability and Permission Boundaries
Read/search and authorised drafting are required. Publication, pricing commitment, client communication and production changes require separate approval.
Degraded Mode
Fallback: return the narrowest qualified proposal outline and an evidence-request list when brief, proof, finance, currentness or reviewer inputs are missing.
Decision Rules
| Condition | Action | Risk avoided |
|---|---|---|
| Core hospitality evidence is available | Build an outcome-to-operation proposal | Generic promises |
| A material benchmark or claim is missing | Qualify or withhold it | Fabricated precision |
| Money, tax, inventory or payment is in scope | Route to finance doctrine | Uncontrolled financial commitments |
Quality Standards
Specific, evaluator-readable, evidence-backed, operationally achievable, finance-reconciled, risk-aware and handoff-ready.
Use this vertical overlay with the proposal pipeline, sector routing, critical analysis, financial proposal, technical strategy, website proposal, and anti-slop skills. It is a proposal method, not a substitute for a feasibility study, accountant, architect, food-safety professional, lawyer, or regulator.
Required inputs
- Property or outlet format, location, ownership/management model, capacity, service periods, and target guests.
- The buyer's ToR or decision, procurement rules, evaluation criteria, budget boundary, delivery dates, and approval authority.
- Verified operating facts: rooms, seats, outlets, event spaces, menus, systems, licences, staffing, suppliers, and available proof.
- Financial assumptions from the finance engine: revenue centres, cost centres, capex/opex, working capital, taxes, payment flows, and reconciliation owner.
If a material input is missing, label it NOT_ASSESSED or make a bounded,
explicit assumption. Never invent occupancy, ADR, covers, margins, reviews,
certifications, client logos, or operating results.
Hospitality proposal spine
- Decision and fit: define the property/outlet problem, desired outcome, guests, operating constraints, and why this response is credible.
- Experience and operating model: connect guest promise to front office, housekeeping, kitchen, service, events, maintenance, safety, and management ownership. Show hand-offs and failure recovery, not only activities.
- Commercial logic: separate room nights, F&B, events/banquets, ancillary services, channel costs, direct demand, and partner commissions. Reconcile the financial envelope with the finance doctrine.
- Delivery method: use a staged discovery, design, configuration/build, migration, training, pilot, cutover, hypercare, and review plan. Give one accountable delivery owner and named client owners.
- Evidence and acceptance: map each promise to proof, an acceptance oracle, a test or inspection, and an owner. Mark live-property, browser/device, integration, and UAT evidence separately.
- Risk and continuity: cover seasonality, staffing, food safety, guest privacy, payments, tax/fiscal obligations, supplier failure, outages, double-booking/over-selling, event safety, and recovery.
Hospitality-specific proof blocks
Include only blocks supported by the brief or evidence pack:
- room/reservation availability and no-double-booking controls;
- arrival, stay, folio, room-charge, checkout, refunds, and night-audit flow;
- housekeeping readiness, maintenance/out-of-order, and service requests;
- restaurant order-to-cash, KOT/KDS, recipe/BOM, waste, stock, and day close;
- event enquiry-to-contract-to-function-sheet-to-debrief controls;
- accounting, payment, tax, audit, privacy, access, and reconciliation design;
- training, adoption, support, operating runbook, and measurable handover.
Decision rules
- Sell an outcome and controlled operating change, not a feature catalogue.
- Treat hotel and restaurant as connected but separately reconciled revenue centres; do not hide cross-posted charges or shared inventory.
- Prefer a small, auditable first release over speculative AI pricing, robots, metaverse, biometric identification, or a broad channel-manager promise.
- Explain deferred scope and the evidence required to unlock it.
- Separate technical and financial envelopes where the solicitation requires it.
- For websites and AI/search claims, use verified, entity-rich, truthful content; never promise ranking, AI citation, training-data inclusion, or review volume.
Acceptance checklist
- Every deliverable requirement has a response, evidence, owner, and oracle.
- Methodology includes normal, failure, concurrency, approval, and recovery paths for the relevant hotel/restaurant workflows.
- Price and schedule reflect integrations, migration, training, support, testing, and client dependencies.
- Claims are source-backed or explicitly labelled assumption/inference.
- Risks include guest safety, food safety, privacy, cash/payment, tax, seasonality, staffing, and operational continuity.
- Final red-team checks evaluator compliance, achievability, anti-slop, commercial arithmetic, and unsupported hospitality claims.
Handoff
Route plan economics to business-plan-skills, requirements and
acceptance to chwezi-sdlc-documentation, implementation to
chwezi-dev-engine, finance to
chwezi-accounting-doctrine, website work to
website-skills, and social work to
social-media-skills.
Anti-patterns
- Generic “luxury hospitality” prose without a defined guest or buyer outcome. Fix: replace it with a scored, evidence-backed value proposition.
- Unsupported occupancy, ADR, covers, margin, certification or review claims. Fix: cite, qualify or remove them.
- Feature catalogue without operating ownership. Fix: map it to a workflow, owner, dependency, test and handover.
- Treating a demo screen as production proof. Fix: require integration, failure, security, reconciliation and UAT evidence.
- Selling AI, channel or payment capability before controls are ready. Fix: phase it behind explicit release gates.
Worked example
For a hotel PMS proposal, lead with fewer booking/folio errors and faster room readiness, then show the reservation, check-in, housekeeping, night-audit and reconciliation method, evidence to be produced, client dependencies, training, support and price drivers. Keep OTA synchronisation as a gated option unless the provider contract and core inventory evidence are available.