Fulfillment

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

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. 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