Custom Order Advance Payment: A Small-Team Playbook

In a one-person brand, the same person answers the custom-order DM, prices the work, checks payment, makes the product and packs it. In a three-person brand, those steps are shared—which creates a different risk: everyone assumes someone else confirmed the brief or payment.

This custom order advance payment playbook gives a small Indian team one dependable handoff from enquiry to production. It is designed for crochet, gifting, art and personalised products where buyers need a real conversation, but the business still needs a clear order record.

A small-team custom-order playbook needs five named states: enquiry, brief agreed, awaiting payment, paid and in production. Assign one owner to each transition. Nobody buys material or starts making until the person responsible for payment has confirmed the matching order.

The five-state custom-order board

1. Enquiry: an idea has arrived, but feasibility and price are still open.
2. Brief agreed: scope, options, final price, timeline and policy are written down.
3. Awaiting payment: the buyer has the correct link and a stated expiry or follow-up point.
4. Paid: the complete required payment is confirmed against the order.
5. In production: material and maker time are committed, with the next update scheduled.

Do not add a vague “confirmed” column. It hides whether the brief, buyer or payment has actually been confirmed. Each state should answer one operational question and have one next action.

Choose the payment policy before the next enquiry

Decide which products require full payment before production and which genuinely need staged billing. Base the decision on material exposure, maker time, resale value and how stable the final price is. Publish the policy before payment and have it reviewed when the legal or financial consequences are material.

SmolBusiness fits fixed-price work that can use complete checkout payment before production. It does not natively split one order into a deposit and later balance. Do not disguise a staged commission as a normal checkout if your team needs milestone invoices, proof approvals or a changing total.

Assign the roles for a 1, 2 or 3-person brand

One person

Use the states to separate your own work. Check enquiries in a defined window, move agreed briefs to payment and start production from the paid queue. This prevents a warm DM from interrupting a piece already due.

Two people

Give one person sales and payment ownership; give the other production and dispatch ownership. The handoff is the paid order, not a forwarded screenshot. Production should be able to see the final product, note, buyer and timeline without asking sales to reconstruct the DM.

Three people

Separate enquiry and briefing, payment and order control, and production or fulfilment. One person may wear two roles on quiet days, but the state transition should still have a named owner.

Use one brief template every time

• Product or commission type
• Dimensions, format, materials and quantity
• Colours, names or other personalised text
• Reference images and the agreed interpretation
• Final price and what it includes
• Production lead time and delivery expectation
• Included changes, cancellation rule and payment trigger

Keep artwork and long references in DMs or your agreed file channel. SmolBusiness checkout has a text note of up to 500 characters, not file uploads or approval stages. Use the order note as a short pointer, not as a replacement for a complex creative brief.

Verify payment with the order beside it

For manual UPI, the payment owner should match the proof to the expected amount and order before changing the state to paid. For the seller’s connected Razorpay account, work from the confirmed order state. Do not treat a buyer message or an initiated screen as completion.

The National Payments Corporation of India’s UPI Help guidance distinguishes initiated, processing, completed and failed transaction states. That supports a simple team rule: start from the confirmed result, not from a cropped screenshot whose status is unclear.

A daily operating rhythm that does not consume the day

• Morning: review new enquiries, paid orders and today’s production promises.
• Midday: send final briefs and payment links for requests that are actually ready.
• End of day: expire unpaid holds, update production states and send promised exceptions.

This is not a claim that three check-ins are universally optimal. It is a starting cadence that keeps notifications from controlling the whole day. Adjust it to your order volume and buyer expectations.

Handle unpaid custom requests consistently

The supplied seller account of a ghosted custom bouquet is one qualitative example of what happens when work crosses the payment boundary too early. Your team should not need to decide from sympathy each time. Use a saved reply that states the payment requirement and when the slot is released.

We have the final brief ready. Your production slot is confirmed after payment, and we begin buying or allocating material at that point. Here is the agreed product link. If you need a change, reply before checkout so we can update the scope and price first.

Review the playbook every ten completed custom orders

Review actual failures, not vanity totals. Which briefs needed clarification? Which payments could not be matched quickly? Which orders changed after production began? Which promised dates slipped? Ten orders is a practical review batch, not a statistical benchmark; it is small enough for a founder to inspect in detail.

Link the review to the seven custom-order mistakes and update one rule at a time. If you need the buyer-facing flow, use the custom-order storefront guide.

Give every person the same start signal

A small team does not need a complicated operations stack. It needs shared definitions and a clean handoff. Agree the brief, collect the required payment, mark the order paid and only then move it into production. When everyone uses the same start signal, custom service stays personal without depending on one founder’s memory.