> ## Documentation Index
> Fetch the complete documentation index at: https://www.twicecommerce.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Build your first listings
> Take one listing from an empty form to something bookable for a real date, then repeat the pattern — variants, pricing, limits, and the collections customers browse.
Part of step 5 of the [launch path](/docs/guides/launch/overview), [Build your catalog](/docs/guides/launch/build-your-catalog). Inventory is what you own; the catalog is what a customer can buy. This is the pass that turns the first into the second.
Build **one** listing all the way through before you build twenty. A listing is finished across six tabs, and the ones people skip are invisible until a customer hits them. One listing done properly is a pattern you can repeat in minutes; twenty half-finished listings are twenty separate investigations.
The finish line for this step is not "the listing is saved". It is **a listing that shows correct availability for a real date**.
**Publishing and fulfilment are separate, and neither failure announces itself.** Setting **Status** to **Public** puts the listing on the storefront. It does not put stock behind it, and the two ways that goes wrong look nothing alike:
* **A rule that matches nothing** — the listing is visible, priced and permanently unbookable. The only sign is the rule's own live count, reading zero.
* **No rule at all** — the card reads *No stock items reserved or deducted when the listing is purchased* and availability is **unlimited**. Correct for a delivery fee or an insurance add-on; wrong for anything physical, because nothing is ever held and you will oversell it.
Read the match count on every listing that has a unit behind it, before you call it done.
**Price the default table, not just the seasonal one.** Every new listing is created with one undated table named **Default**, and that is the one that applies whenever no dated table does. Every further table you add requires a validity period, because a table with one cannot be a default — the admin says so outright: *Only price tables without validity period can be used as a default price tables for listings.*
So a listing whose only prices sit on a dated table has no price outside that window. That is the shape of most "the storefront shows no price" reports during a launch.
## The six passes over one listing
Open a listing from **Catalog → Listings**. The tabs are not a wizard — you can work them in any order — but this order gets you to bookable with the fewest revisits.
| Pass | Tab | What it decides | Skipping it means |
| ---- | -------------- | ------------------------------------------------------------------------------ | --------------------------------------------------------- |
| 1 | **General** | Title, internal name, description, media, category, tax rates, and **Status** | A listing customers cannot read, or an untaxed one |
| 2 | **Variants** | Whether one listing is offered in several forms, and what each form draws from | Near-identical listings a customer has to hunt through |
| 3 | **Pricing** | The price table, and which purchase types the listing offers | The listing has no price and cannot be bought |
| 4 | **Limits** | The shortest, longest and latest a booking can be | An unbounded booking, or a too-soon one you cannot fulfil |
| 5 | **Fulfilment** | Which stock items this listing reserves or deducts | Unlimited availability — you oversell what you own |
| 6 | **Publishing** | Sales channels, store locations, customer tags | Finished in the admin, absent from the storefront |
Leave **Status** on **Draft** for passes 1 to 5. Switching to **Public** is the last thing you do, not the first — a listing published half-built is a live listing that does not work.
Two more tabs matter later and not now: **Attributes** carries the catalog attributes you designed in step 3, and **Checkout settings** holds the fields a customer fills in at checkout. Neither blocks a booking.
## Variants: decide what actually differs
Every combination of your variant options becomes a variant, and the **Variants** tab keeps a running **Total variants** count. Three sizes and four colours is twelve variants — twelve things that can be individually priced, individually stocked, and individually wrong.
Before adding an option, decide which of three cases you are in:
| The variants differ in | Configure | Where |
| ---------------------- | ---------------------------------------- | ------------------------------------------------------------- |
| Name only | Nothing beyond the options | **Variants** tab — the options are for the customer's benefit |
| Stock | **Variant specific rules** | **Fulfilment** tab, layered on the base rule |
| Price | **Variant pricing**, overriding **Base** | **Variants** tab |
Most first listings need name-only variants, or none. Setting up per-variant stock and pricing you did not need is maintenance you carry for the life of the listing.
If the grid is mostly empty — you stock three of twelve combinations — those are separate listings, not variants. Publishing is per listing, so anything sold at only some locations has to be its own listing regardless.
## Pricing: one table, or a rate card shared across many
Prices live in **price tables**, not on the listing. On the **Pricing** tab, adding a table offers two things, and the choice is the one to make deliberately:
| | Create new standalone table | Connect existing price table |
| ------------------ | --------------------------- | --------------------------------------------------- |
| Belongs to | This listing alone | Every listing linked to it |
| Editing it changes | This listing | Every linked listing at once |
| Use for | A price nothing else shares | A rate card — one price for a whole class of things |
A shared table's purchase types and prices are edited on the table itself; on a linked listing they are read-only, marked *Controlled by the linked price table*. Before editing a shared table, open its **Linked listings** — *listings that are using this price table* — because a shared rate card is a shared consequence.
Inside a table, three sections decide what a customer can do with the listing. Each is a switch, and a section that is off is a purchase type the listing does not offer:
| Section | What it enables |
| ------------------ | ------------------------------------------------------ |
| **Purchase price** | A one-time purchase — the customer keeps it |
| **Booking price** | A booking for a duration — the customer brings it back |
| **Subscription** | A recurring plan |
Booking prices come in two shapes and they answer different questions. **Fixed price per duration** sells named periods — a day pass, a weekend rate. **Rate based** bills the duration actually booked, a day running 24 hours from pickup. On a fixed-duration price the unit dropdown offers each unit twice — **Day (Elapsed)** runs the full period from pickup, **Day (Started)** derives the return from the pickup day — and that suffix is a revenue decision, not a formatting one. [Price a listing](/docs/guides/catalog/price-a-listing) works it through with a real booking.
Turning **Booking price** on also brings out the **Booking deposit** card on the Pricing tab, which is hidden until at least one of the listing's tables offers bookings. The deposit belongs to the **listing**, not to the table it appears beside — one listing holds one deposit however many tables it carries.
## One SKU, a rental listing and a resale listing
Nothing in TWICE scopes a stock item to a single listing. A listing's **Fulfilment** rule matches stock — by SKU, by attribute, by name — and two listings whose rules match the same units share one pool. That is how the same thing is rented and sold without duplicating your inventory, and it is the thing a rental-only system cannot do.
Two ways to set it up, and they are not equivalent:
| | One listing, both purchase types | Two listings, one pool |
| ------------- | ----------------------------------------------------------------------- | -------------------------------------------------------------------------------- |
| How | Enable **Purchase price** and **Booking price** on the same price table | Two listings, each with a Fulfilment rule matching the same SKU |
| Customer sees | One page, a choice of how to acquire it | Two pages, each with its own copy, images and publishing |
| Prices | One table for both | A rate card for the rentals, a sale price for the resales |
| Good for | The same offer, two ways to pay for it | A rental fleet with a resale channel, where the two are merchandised differently |
Whichever you pick, one behaviour is worth knowing before it surprises you: **a sale takes the unit permanently, from the moment the order is committed.** A booking occupies its window and releases the unit afterwards; a sale occupies the unit from now on, and a future-dated sale still takes it immediately. So a unit sold on the resale listing leaves the rental listing's availability at once, which is correct — but it means selling out of your rental fleet is a thing that can happen quietly if both listings draw on the same pool with nothing separating them.
If you want a resale channel that cannot eat the fleet, separate the pools with an attribute — a *retired* or *for sale* flag on the stock item — and match each listing's rule on it. The [fleet to resale](/docs/guides/inventory/fleet-to-resale) guide covers moving units between them.
## Limits: what a customer is allowed to book
Four settings on the **Limits** tab — the shortest booking, the longest, the increment between them, and how late an order can be placed. They take a minute to fill in and are the difference between a fleet you control and one a customer can book for a year.
Two of them behave differently depending on how the listing is priced, and this catches people:
| | Fixed-duration pricing | Rate-based pricing |
| -------------------------- | ------------------------------------------------------- | -------------------------------------------------- |
| Minimum / maximum duration | Filters which price rows the storefront offers | Enforced by the server, at checkout |
| Duration increment | **Does nothing** — a fixed row carries its own duration | Constrains selectable durations to whole multiples |
| Order deadline | Applies | Applies |
None of the four constrains a sale — a sale has no duration and no start time. Set them anyway on anything you rent, and set the order deadline in particular: it is the only setting that stops a too-soon booking appearing on the storefront calendar at all. Full detail in [purchase and booking limits](/docs/guides/catalog/purchase-and-booking-limits).
## Collections: how customers find any of this
A collection groups listings so customers can browse them together. It is merchandising, not filing — a listing sits in several collections at once, and being in one changes nothing about the listing.
For a launch, build **manual** collections. A **smart** collection joins listings by their tags automatically, which is the better tool once tagging is a habit and a liability before then: inconsistent tags give you a collection that is quietly wrong rather than obviously empty. Smart collections match on tags only — not price, category, attribute or availability.
Build them around how people shop — by activity, by season, by who it is for — rather than mirroring your internal categories. A customer who has never seen your catalog should reach a representative item in two clicks.
## Publish, then check the real thing
**Open preview** renders the listing in a drawer inside the admin, with the booking action disabled. It is good for copy, images and pricing, and it will happily render a listing that is not published, not available at the location, or restricted to a customer tag you are not in.
**Open in storefront** opens the real page. That is the check that proves publishing worked, because a listing that failed to publish is simply not there.
Do the second, on a real date, before you move on to the next listing.
## Done when
* One listing is complete across all six tabs, and **Status** is **Public**.
* Its **Fulfilment** rule reports a non-zero **matches in inventory** count, and the units it matches are at the location you sell from.
* The undated **Default** price table is priced — not only a dated overlay — with **Purchase price**, **Booking price** or both switched on.
* Any shared rate card's **Linked listings** contains exactly the listings you meant to price.
* The listing opens in the storefront — not just in preview — and shows a price for a real date.
* It can be added to an order for that date, and doing so holds a unit.
* Booking limits are set on anything you rent, including an order deadline.
* The listings you have built are in at least one collection, and that collection opens on the storefront.
* You can build the second listing by repeating this, without looking anything up.
## Related articles
The launch step this guide belongs to.
The four decisions that make a listing sellable, tab by tab.
Options, per-variant stock, and per-variant pricing in full.
Price tables, Elapsed versus Started, and deposits.
The four Limits settings, and what each one does on each pricing model.
Writing the Fulfilment rule and checking what it matches.
Manual and smart collections, and where they surface.
The next step, once the catalog exists.