--- title: "Understanding Products & Pricing" description: "A concept overview of Orbit Products: a purchasable logistics service whose price is calculated per transport, why a product can show no price or be marked unavailable, and the sales/purchasing split." url: "https://support.pr-4.orbit.do/en/advanced-features/understanding-products-pricing" locale: "en" lastReviewed: "2026-07-10" --- # Understanding Products & Pricing A concept overview of Orbit Products: a purchasable logistics service whose price is calculated per transport, why a product can show no price or be marked unavailable, and the sales/purchasing split. > **Note:** A `Product` is a purchasable logistics service you offer to shippers. Its price isn't a fixed number in a catalogue — Orbit works it out for each transport when the service is chosen. **Who this is for:** operators who want to understand what a `Product` represents and how a price appears — or doesn't — when booking. It is a concept overview, not a build guide; if you configure products, the build guides are linked at the end. ## What a product is A `Product` is a sellable logistics service — a same-day courier, an overnight pallet service, a temperature-controlled run. Rather than storing one fixed price, a product describes *how* to price a service and *whether* it can be offered at all. When someone chooses the product for a specific transport, Orbit runs that description against the details of the job — the route, the load, the timing — and produces the price and terms for that particular move. This is why the same product can return one figure for a Paris to Berlin run and another for a London to Manchester one, and why a price only exists once there is a real transport to price it against. ## How a product is assembled A product is built from a set of modular building blocks, sometimes called bricks. You don't need to work with them to book, but knowing the four kinds explains what a product decides for each transport: * **Context** — gathers the shared facts the other blocks need, such as the route or the vehicle type. * **Feasibility** — decides whether the service can be offered for this job at all. * **Pricing** — produces the priced lines that add up to the quote. * **Scheduling** — offers the bookable time slots or windows for the service. Because the price is assembled this way, it reflects the actual job in front of you rather than a generic list price. ## Sales, purchasing, or both A product prices one or both sides of a deal: * **Sales** — what the customer pays. This lands on the `Order`. * **Purchasing** — what it costs you to have a carrier carry it out. This lands on the `Tour`. * **Sales and purchasing** — both sides, from a single product. The two are different numbers for different audiences: a customer sees the sales price on their `Order`; a carrier only ever sees the purchasing-side rate on the `Tour`. ## When no price is shown — this is normal A product doesn't always come back with a bookable price, and that is valid, expected data rather than a fault to fix. Evaluating a product against a transport has three possible outcomes: * **A price** — the service is available and can be booked at the price shown. * **Price on request** — the service is available, but a price can't be worked out automatically for this job. Instead of a figure, the customer is offered the chance to request a quote, which reaches an operator to price by hand. * **Unavailable** — the service can't be offered for this particular transport, usually with a short message explaining why, such as a load that is too heavy for the service. So a product card that shows no price, or is marked unavailable, is telling you something true about that specific job — it is not a broken price. Operators enable the request path with the **Allow Requests** option on a product, and the wording of the request prompt shown to the customer is configurable. ## Where you see products Products appear as selectable cards while you build a transport in the **TransportComposer** in Orbit MissionControl, and to shippers booking in Orbit Hub. Each card shows a price, a request prompt, or an unavailable note, depending on the outcome above. ## Learn more This article is a concept overview. For building and running products, see: * [Products](https://support.pr-4.orbit.do/en/advanced-features/products) — the full guide to composing a product. * [Calculator Widget](https://support.pr-4.orbit.do/en/advanced-features/calculator-widget) — an embeddable price calculator. * [Product Messages](https://support.pr-4.orbit.do/en/advanced-features/product-messages) — the notes and alerts a product can show while pricing. * [Product Testing](https://support.pr-4.orbit.do/en/advanced-features/product-testing) — checking a product's output before it goes live. * [Product Metrics](https://support.pr-4.orbit.do/en/advanced-features/product-metrics) — the figures behind a price, such as distance and travel time. ## FAQ **Q: Why does a product show no price?** Because the price for that specific job can't be worked out automatically, or the service isn't available for it. If requests are enabled, the customer can ask for a quote instead; otherwise the card shows the service as unavailable, usually with a reason. Both are valid outcomes, not errors. **Q: Why is the same product a different price on two bookings?** A product prices each transport on its own details — route, load, and timing — so the figure changes from job to job. There is no single stored price to look up. **Q: Does every company have products?** No. Products are Orbit's pricing layer, and a company that prices its services elsewhere may have none. In that case a price is set by hand rather than calculated. **Q: Why doesn't the carrier see the price the customer paid?** The customer's price (sales) and the carrier's rate (purchasing) are separate figures. A carrier only sees the purchasing-side rate on the `Tour`, never the sales price on the `Order`.