> ## Documentation Index > Fetch the complete documentation index at: https://docs.dmly.io/llms.txt > Use this file to discover all available pages before exploring further. # Offerings overview > The catalogue behind DMLY: Services are what you do, Products are what you sell, Plans are what you bundle them into. **Offerings** is your catalogue — the one place you describe what your business sells, so that bookings, invoices, orders and automations all price the same thing the same way. Open **Offerings** from the main menu and you get three tabs: **Services**, **Products** and **Plans**. DMLY describes it as "Manage your services, products and plans in one place", and that is all it is. There is no separate page per type. ## Which one is it? | Tab | Use it for | The short test | | ------------ | ------------------------------------------------------------------------------ | ----------------------------------------------------------- | | **Services** | What your business *does* — a cut and blow-dry, a consultation, a class | You sell **time**, and someone has to be free to deliver it | | **Products** | What your business *sells* — shampoo, supplements, a gift card | You sell a **thing**, and you might run out of it | | **Plans** | The bundle a client buys up front — a 10-session package, a monthly membership | You sell **access** to the two above, once or every month | Everything else in DMLY reads from these. A booking is made against a Service. An invoice line copies a Service, Product or Plan. A subscription is a Plan someone is on. ## The thing that surprises people first **Credits are one pot per client, not a per-service allowance.** You can build a Plan that reads "10 massage sessions", and DMLY will describe it that way. But when the client books, the credits come out of a single balance on their contact — there is no check that the credits were bought for *that* service. A client holding 10 credits from a massage package can spend them on any service that has a **Credit cost** above zero. Price your Plans knowing that. If two services should not draw on the same pot, do not sell them both against credits. ## Services — what you do A Service is more than a name and a price: it carries the **booking policy**. The duration, the buffers before and after, how much notice you need, how far ahead people can book, and — for a class — how many seats there are. Set those here once and every booking obeys them. Pick a **Service type** when you create one: | Service type | What it is | | --------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Appointment** | One client, one slot. The normal case. | | **Class** | A group session with a seat count, and an optional waitlist when it fills. | | **Add-on** | An extra sold alongside something else. DMLY's own hint: "Add-ons are extras clients can attach to a booking. They have no schedule or duration of their own." | An add-on is never bookable on its own and never appears on your public booking page. It exists to be added as a line on an order. **Show on public booking page** controls whether clients can find and book a service themselves. **Get booking link** gives you the link to share — the panel says "Share this link so clients can browse and book online", and offers **WhatsApp**, **SMS**, **Email** and **Copy**. WhatsApp first, as always. ### Payment mode A service's **Payment mode** is one of three: * **No payment required** — booking is free at the point of booking. * **Pay after the appointment** — the slot confirms immediately, then a payment link goes out. * **Pay before booking** — the slot is only held until the client pays online. It is not confirmed until the payment lands. **A payment mode does nothing unless the service also has a price above zero.** Setting **Pay before booking** on a service priced at 0 leaves it free — the mode is ignored. Set the price and the mode together, or you will hand out free slots. The mechanics of holds, links and gateways are on [Booking payments](/appointments/payments). Services are the same records the Appointments module books against — they moved into the Offerings catalogue rather than being duplicated. **Assigned staff**, **Weekly availability** and **Timezone** are on this form; each staff member's own **Working hours** are on Appointments → Staff. See [Services](/appointments/services) and [Staff and availability](/appointments/staff-and-availability). ## Products — what you sell Products are your own stocked goods. Create them with **New product**, give them a **SKU**, **Image**, **Price** and **Tax rate (%)**, and put them in a category. **Track stock** is off by default and opt-in per product. Turn it on and you get **Stock quantity** and a **Low stock threshold**, plus a **Low stock only** filter on the list. A product only counts as low when all three are true: tracking is on, a threshold is set, and the quantity has fallen to that threshold or below. Every stock change is written to a ledger rather than just overwritten, so the number always has a history behind it. Confirming an order decrements the stock of the products on it, once — re-confirming the same order will not decrement it twice. See [Orders](/finance/orders). Products are the only tab with bulk tools: **Import products** ("Upload a CSV file to add or update products in bulk"), **Download sample CSV**, and **Export**. Services and Plans are created one at a time. **Import only ever adds.** Despite the hint's wording, it never matches an existing product by name or SKU, so re-uploading the same file duplicates every row. Edit existing products in the UI, and only import rows that are genuinely new. **The Meta catalogue switches do nothing yet.** **Sync to Facebook** and **Sync to Instagram** save, but nothing reads them — no product is pushed to a Meta catalogue. The tab labels this honestly as **Meta catalogue · Coming soon**. Treat them as off. Products here are your internal catalogue. They are separate from the products that sync in from Shopify or WooCommerce, which are their own records with their own stock automations. Editing one does not touch the other. ## Plans — what you bundle A Plan is what the client actually buys. The price and cadence live on the plan; the contents live in **Plan items**. Choose a **Billing type**: * **One-time** — a package. Bought once. * **Recurring** — a membership. Set **Interval** (**day**, **week**, **month**, **year**) and **Every** to control the cadence. Then use **Add item** to say what the plan grants. Each item has an **Item type**: | Item type | Grants | | ----------- | --------------------------------------------------------------------------------------------------------------------------------------------- | | **Credit** | Credits into the client's balance. Pointing it at a service labels what the credits are *for* — it does not restrict where they can be spent. | | **Service** | A service bundled into the plan. | | **Product** | A product bundled into the plan. | If your plan has credit items, the credits on those items add up to what the client is granted when the subscription starts — and again on each renewal that is actually charged (auto-charge). A recurring subscription with no auto-charge rolls its period but does not re-grant credits. The plan's own headline credits number is only used when no credit item grants any. Full detail is on [Plans and credits](/offerings/plans-and-credits). ### How credits behave * **A credit is a whole number on a contact.** One balance per person. Granting adds, booking subtracts. * **A service spends credits only if its Credit cost is above zero.** The field's own help text: "Number of credits this service consumes when a client books with a plan." * **A client can never go negative.** DMLY rejects a spend that exceeds the balance rather than overdrawing it. * **A booking spends credits once.** A double-click or a retried job cannot take them twice. * **Credits do not expire.** Nothing in DMLY ages them out or sweeps them away. A credit granted today is still spendable in two years. * **The client sees their credit history** on their profile, showing the most recent 50 entries. See [The client profile](/contacts/client-profile). **The low-credit alert fires at 3, and you cannot change it.** When a client's balance drops to 3 or below by using credits, DMLY can trigger an automation. That number is fixed — there is no setting for it, per workspace or per plan. (Product low-stock thresholds *are* editable; credits are not.) ### Plans and Finance Putting a client on a recurring plan creates a **subscription**: DMLY copies the plan's items as they are today, grants the credits, and converts the contact to a client. Later edits to the plan do not rewrite an existing subscription. **Creating a subscription does not charge anyone.** It grants the credits and starts the record — taking the money is a separate step. Money only moves on its own if the client enrols in **auto-charge**: send them a card-capture link from Finance → Subscriptions, and once a card is saved DMLY charges it on each renewal date, invoices it and sends a receipt. Without that, nothing is billed automatically. See [Subscriptions](/finance/subscriptions). ## Categories Categories are shared across all three tabs and managed inline from each one — there is no separate settings page. A category can be scoped to a single type, or left open so it works for services, products and plans alike. You can add and delete categories; you cannot rename one. See [Categories](/offerings/categories). ## What the catalogue feeds Every booking is made against a Service, using the duration, buffers and notice you set here. A line copies the offering's name, price and tax at the moment it is issued. Flows can send a client a service with its booking link, or a product or plan, and branch on whether a product is in stock. Credits issued, used and low; product stock low and back in stock. **Editing the catalogue never changes an invoice you already sent.** Invoice and order lines store a copy of the name, price and tax rate as they were when the document was created. Put your prices up tomorrow and last month's invoice still says what it said. ### Stock automations behave differently to the rest Two things worth knowing before you build one: * They fire **on the crossing, not on every save**. Low stock triggers when the quantity falls *through* your threshold, and back-in-stock when it rises above zero from nothing. Editing a product that is already low will not fire it again. * They have **no customer attached**. A product running low is not something one client did, so there is nobody to reply to. Instead the flow runs for the contacts holding a tag you choose on the trigger — capped at 500 contacts per run. Pick a small internal tag (your staff), not a customer segment. See [Triggers](/automation/triggers). When a flow checks stock, a product with **Track stock** switched off always counts as in stock, and a product it cannot find counts as out of stock. DMLY will not claim availability it cannot confirm. ## Two fields that look like settings and aren't **The Credits box on a service does nothing. Credit cost is the real one.** A service form has two credit fields next to each other. **Credit cost** is what a booking spends. **Credits** is stored and never read — filling it in has no effect on anything. If a client's credits are not being consumed, check **Credit cost**. **Sync to Facebook** and **Sync to Instagram** on a product are likewise saved and unread. See above. ## Where to go next Stock tracking, the low-stock threshold, and CSV import and export. Packages, memberships, plan items and how the credit balance moves. Group the catalogue, and scope a category to one type. Duration, buffers, staff and the booking policy in full. Pay before, pay after, and what happens to an unpaid hold. Where the catalogue turns into invoices, orders and payments.