Find the decision that checkout cannot make
A standard buying journey works when a customer can choose a known product at a known price. Custom commerce gets harder when feasibility, quantity, artwork or delivery timing must be confirmed by a person before the business can accept the order.
That does not mean the storefront needs rebuilding. Identify the uncertain decision first. A clear product page plus a structured request may be enough. The checkout should not imply a promise that operations cannot yet keep.
Capture requirements with the product context
For an illustrative made-to-order product, capture the chosen base product, relevant dimensions or options, quantity and any requirements affecting feasibility. Keep free text for exceptions rather than asking the customer to describe everything from scratch.
Show a summary before submission and explain what happens next. Preserve that version of the request so a later change can be discussed explicitly. If staff revise a requirement, both sides should be able to tell which specification is being quoted.
- Required choices are separated from optional preferences.
- The request retains the original product context.
- Files and notes belong to a recognizable request.
- Customers know whether they requested a quote or placed an order.
Use draft orders where they fit
Shopify supports creating draft orders with product variants or custom line items and sending an invoice. Its GraphQL draft-order API can support a tailored workflow around those capabilities. Check the current documentation, permissions and store requirements before choosing the integration.
A draft order does not resolve the business process by itself. You still need to define who confirms the specification, how a revised quote replaces an older one and what counts as customer approval. Use Shopify’s supported functionality where it fits rather than duplicating commerce fundamentals unnecessarily.
Give operations a useful work queue
An internal view should make the next decision obvious. A request awaiting specification review should not sit beside a paid order with the same generic “pending” label. Separate review, customer approval, payment and fulfilment states where they represent different responsibilities.
Keep a deliberate exception path for incomplete information, expired quotes and changed requirements. Define whether a change requires a new quote or approval. This is usually more valuable than adding another decorative storefront feature.
| Stage | Question to answer |
|---|---|
| Request | Do we have enough information to assess it? |
| Quote | Which specification and price are being offered? |
| Approval | Has the customer accepted this version? |
| Payment | Has the authoritative payment state been confirmed? |
| Fulfilment | Does the team have the approved instructions? |
Test the changes, not only the successful order
Walk through a customer revising quantities after a quote, a payment arriving late, a duplicate submission and an order that cannot be fulfilled as requested. Check that the system preserves the agreed context instead of silently overwriting it.
Begin with the most common custom-order path. Review it with the people who price, approve and fulfil the work. Expand only when the first flow makes their decisions clearer.