Appearance
Getting an experience live
Page summary: Make an experience actually bookable by a guest.
Use this when: Use this when setting up, testing, or diagnosing why a published experience is not selling.
- The goal is not “published”; the goal is “guest can find a date, see the right price, and complete checkout.”
- A main photo, live rate, and active availability are required readiness checks.
- Partner visibility is a separate step from publishing.
A vendor has something to sell. This is everything between that and a guest being able to book it.
Draft. The steps and the screens come from the dev environment. The three readiness checks come from the code. The full path has not been walked end to end by one person in one sitting.
| Owner | product |
| Date checked | 5 August 2026 |
| Environment | dev |
What you end up with
An experience that a guest can find, choose a date for, and pay for — on the vendor's own booking page, and if the vendor wants, through a hotel partner as well.
Who is involved
The vendor, doing all the setting up. Delta, if help is needed. Nobody else until a guest arrives.
What has to be true first
The vendor has an account and a company set up, and has decided how they take money. Both live under Settings in the dashboard.
The steps
- Create the experience. Name, description, photos, where it is, how long it lasts.
- Add options. The choices a guest makes — number of people, a size, a time, a meal choice. One of them is marked as the pricing reference: the option that decides the price. In dev, real examples include number of people, ski length, shoe size, height, weight and whether meals are included.
- Add extras, if any. Each has its own price and its own capacity.
- Set a rate. What it costs, and the period the rate covers.
- Set when it runs, and how many can come. Choose one of four kinds of capacity — no limit, a limit on bookings, a limit on people, or every booking needs the vendor's approval. See When things are bookable.
- Set the policies — cancellation, refunds, payment timing.
- Choose how the booking page looks. Branding and appearance, under Settings.
- Publish it.
- Decide whether partners may sell it, one partner at a time. Publishing to your own page does not offer it to anyone else. See Who owns what across systems.
Before it can go live
Three checks, and these are exact — they are what the code actually looks for.
| What is needed | What counts | Where |
|---|---|---|
| A photo | At least one photo marked as the main image. Other photos do not count. | product photos |
| A rate | A rate that is not deleted, not stale, and whose end date is today or later. An expired rate fails. | rates |
| Availability | At least one active availability rule. | availability |
Confirmed in code. ems-backend/internal/product/repositories/impl/product.sql_repo.go:1066-1105
The rate check is the one that catches people. A rate whose end date has passed fails the check, even though the rate is still there and looks fine on screen. An experience that was live last season will quietly fail this at the start of the next one.
What state an experience can be in
Draft · Incomplete · Published · Unlisted · Inactive.
Only published experiences can be bought. In dev, the list shows a mixture of Draft and Unlisted, with the pricing reference displayed next to each.
Confirmed in dev, 5 August 2026. Confirmed in code — ems-apis/constants/product_status.go:5-11.
What separates incomplete from draft, and unlisted from inactive, is not established.
What should be true afterwards
| Where | What to expect |
|---|---|
| Vendor dashboard | The experience shows as published, with its options and extras counted |
| The vendor's booking page | It appears, with bookable dates and the right price |
| Checkout | The chosen options change the price; extras can be added |
| Partner screens | It appears only if that partner was given it explicitly |
| After a booking | It arrives in the booking list, marked with where it came from |
When it goes wrong
| What someone reports | Likely cause | Where to look |
|---|---|---|
| "I published it but guests cannot see it" | One of the three readiness checks is failing — most often an expired rate | Before it can go live, above |
| "It appears but there are no dates" | Every slot is full, or below the minimum party size, or there is no availability rule | a booking counts differently depending on the kind (AVL-002), a seat-limited slot hides itself once it cannot fit a minimum party (AVL-003) |
| "I can see dates but the guest cannot" | The dashboard shows every slot; the booking page filters them | the dashboard sees slots guests cannot (AVL-004) |
| "The price on the booking page is wrong" | The pricing reference option is not the one they think it is, or the rate period has changed | Step 2, and Prices and fees |
| "Tax looks wrong" | Tax is inside the price, not added on top | tax is inside the price (PRC-001) |
| "Our partner cannot see it" | Publishing to the vendor's own page does not offer it to partners. It has to be given to each one. | the vendor chooses what a partner may sell, experience by experience (OWN-004) |
| "Bookings arrive already confirmed and we wanted to approve them" | Approval is set per availability slot, not per experience | approval is decided per slot, and any one slot infects the booking (AVL-005) |
| "It let someone book a full slot" | Availability is not enforced when a booking is created | availability is not actually enforced when a booking is created (AVL-006) |
Open questions
- Nobody has walked this path end to end in one sitting; the steps are assembled from the screens and the code.
- Cut-off times, how far ahead people can book, and blackout dates are not covered — they have not been located yet.
- What "incomplete" means, and what puts an experience into it.