> ## Documentation Index > Fetch the complete documentation index at: https://firespark.cloud/docs/llms.txt > Use this file to discover all available pages before exploring further. # Fulfillment > How orders are completed — standard modes, custom types, and rules per store and channel. **Fulfillment** is how a customer receives their order after they pay. It is not the menu and not the channel app itself — it is the **promise**: pickup at the counter, delivery to an address, eat-in at the table, or any other flow you define for how the order gets done. ## Common fulfillment modes | Mode | Customer expectation | Commercial note | | -------- | ---------------------------- | ----------------------------------------------------------- | | Pickup | Collect at the store | Often highest margin on owned channels | | Delivery | Brought to an address | May involve own fleet, third party, or aggregator logistics | | Dine-in | Served or collected in venue | Common for kiosk and QR flows | Those are the starting points. Fire spark also lets you **create fulfillment types to match how you actually sell** — with their own rules and checkout workflow — without treating every variation as a one-off hack per channel. | Custom example | What you might configure | | -------------- | ---------------------------------------------------- | | Drive-thru | Lane pickup, timing, and store-specific availability | | Curbside | Handoff rules and customer arrival flow | | Shipping | Delivery fee logic for retail or packaged goods | | Tips | Optional or suggested gratuity as part of checkout | A drive-thru lane, a shipping line item, or tip prompts are not separate products; they are **behavior attached to a fulfillment type**. You decide which stores and channels expose each option, the same way you gate delivery or pickup today. ## Rules per store, channel, and type Fulfillment rules can vary **per store** and **per channel**. A location might offer delivery on your app but pickup-only on an aggregator. A custom drive-thru fulfillment might exist only at locations with a lane, while shipping appears on web but not on kiosk. Fire spark keeps those rules in one model so each surface exposes **only what that store can honor** — whether the type is built-in or custom. ## Why this matters commercially Misconfigured fulfillment causes the most visible failures: the customer expects delivery, the store prepared pickup; an aggregator shows a service the kitchen cannot run. Unified fulfillment configuration also means commercial experiments — adding tips on owned channels, testing a new handoff mode, or rolling out shipping to one region — do not require a new integration per idea. You define the type, its workflow, and where it is live. ## Operations handoff When an order is placed, fulfillment type and any related charges travel with it into your POS or RMS. Kitchen and dispatch workflows stay in the systems your team already uses; Fire spark carries the customer’s choice accurately from channel to counter. ## Related concepts Purchases with a fulfillment type Where fulfillment happens Surfaces that expose fulfillment options