Agent LabHackrLife
← All solutions
16 · Small accommodationSimulationAccommodation

Guest Extras

Offer useful extras before guests arrive.

Matches upcoming stays with available extras and creates both a purchase record and a fulfilment task. Each extra is checked against the stay and the property's capacity before it is offered, and fulfilment starts only from a verified payment event.

A real customer situation

A guest arriving in a few days could add a breakfast hamper or a late checkout. Late checkout is not possible when another guest arrives in the same room that day, and breakfast depends on hamper stock and 24 hours’ notice.

Where the owner wants to be

Guests are offered only extras the property can deliver, every paid extra has a receipt and exactly one task, and someone on staff has acknowledged responsibility for it.

What it handles

  • Checks each extra against stay dates, stock and room turnover, with the reason shown
  • Offers an alternative when the requested extra is unavailable
  • Runs a sample checkout and confirms the purchase only after a verified payment event
  • Creates one fulfilment task per payment, even if the event arrives twice
  • Escalates tasks that are not acknowledged in time

What it deliberately does not do

  • Never offers late checkout when the room has a same-day arrival
  • A failed payment produces no confirmed purchase and no task
  • The demo collects no card details and takes no payment

Interactive demo

Try it with sample data

No sign-up needed. Pick a scenario, change the inputs, then play the customer and the owner. The right-hand panel only shows what the workflow actually recorded.

Interactive simulation

Interactive simulation using sample reservations and a sample checkout. No card details are collected, no payment is taken and no staff task is created.

Choose a scenario

Two guests, two mornings, hampers in stock. Payment succeeds and the kitchen gets one task.

Breakfast hampers need 24 hours’ notice.

Customer side · Pre-arrival email to the guest

Press “Run scenario” to start. Every message and record here comes from sample data.

Workflow and harness

How Guest Extras runs

Reference schematic for the proposed workflow. Blue steps do the work, purple paths handle exceptions and returns, and amber checks are the harness controls that a step cannot pass without.

Overview — business stages

alternative optionretry or exitstaff escalationcheckcheckcheckUpcoming reservationMatch available extrasGuest selects optionVerify purchase eventCreate fulfilment taskConfirm deliveryresponsibilityUnavailable extraPayment failedNot acknowledgedStay and capacity rulesVerified paymentFulfilmentacknowledgement
Business stepException, return or stopHarness check Required check
Read the full flow as text
  1. Upcoming reservation (business step)
    Stay dates, room, guests. Output: Reservation context. Leads to: Match available extras.
  2. Match available extras (business step)
    Only eligible extras are offered. Output: Eligible extras with reasons; offer message. Leads to: Guest selects option; Unavailable extra.
  3. Guest selects option (business step)
    Catalogue price; sample checkout without card details. Output: Purchase awaiting payment. Leads to: Verify purchase event.
  4. Verify purchase event (business step)
    Purchase confirmed only on a verified event; deduplicated by event id. Output: Receipt and guest confirmation. Leads to: Create fulfilment task; Payment failed.
  5. Create fulfilment task (business step)
    One task per payment event. Output: Pending task assigned to staff. Leads to: Confirm delivery responsibility; Not acknowledged.
  6. Confirm delivery responsibility (business step)
    Named person accepts the task. Output: Acknowledged task.
  7. Unavailable extra (exception or return path)
    Explain why; offer an eligible alternative. Output: Alternative offer. Leads to: Match available extras (alternative option).
  8. Payment failed (exception or return path)
    No purchase, no task; retry or exit. Output: Unconfirmed purchase. Leads to: Guest selects option (retry or exit).
  9. Not acknowledged (exception or return path)
    Escalate to duty manager, then owner. Output: Escalated task. Leads to: Create fulfilment task (staff escalation).
  10. Stay and capacity rules (harness check)
    24 hours’ notice for breakfast; no late checkout with same-day arrival. Output: Eligible / excluded with reason. Leads to: Match available extras (required check).
  11. Verified payment (harness check)
    Event succeeded and matches the purchase. Output: Verified payment reference. Leads to: Verify purchase event (required check).
  12. Fulfilment acknowledgement (harness check)
    Task owner acknowledges before the stay. Output: Acknowledged by name. Leads to: Confirm delivery responsibility (required check).

Harness controls

  • Eligibility and availability rules per extra, with the reason recorded
  • Payment verification before any purchase is confirmed
  • Idempotent task creation keyed on the payment event
  • Fulfilment acknowledgement by a named staff member
  • Escalation timer for unacknowledged tasks

Systems and data

Production connects property bookings, extras inventory, a payment provider and the staff task system. The demo uses two sample reservations, a stock fixture, a simulated payment event and an outbox that holds guest messages.

Demo boundary

External calls, customer messages, payments and business writes use synthetic fixtures and an on-screen outbox. The demo shows only verified demo state. Custom production connections are a paid implementation deliverable.

What gets delivered

The records your business receives

Guest confirmation

A short note confirming the extra, the price and the receipt number, sent after the payment is verified.

Fulfilment task

Assigned to kitchen or housekeeping with room, date and extra; pending until acknowledged, then escalated if ignored.

Purchase record

Reservation, extra, price rule, payment reference and receipt, linked to the single task it created.

Custom deployment

Configured for your business during a paid implementation. Integrations are confirmed during discovery, never assumed.

Your business rules

  • Which extras you sell, their prices and notice periods
  • Stock limits and turnover rules per room
  • Who fulfils each extra and who is next in the escalation chain
  • Acknowledgement time before escalation

Systems we connect

Property booking systemExtras inventoryPayment providerStaff task system

Measurement

We measure completed business against a baseline, not messages sent. No results are promised before discovery.

Business results

  • Fulfilled extras contribution per stay
  • Fulfilment failure rate
  • Share of offered stays that add an extra

Operational reliability

  • Duplicate fulfilment tasks from repeated payment events (target: zero)
  • Late checkouts sold against a same-day arrival (target: zero)
  • Tasks acknowledged before escalation

Want this offering extras from your own booking system?

Book a call about Guest Extras. We start with discovery: your current process, volumes, systems and who handles exceptions. The proposal then defines the integrations, approvals and acceptance tests before anything goes live.