Does a custom-product production time begin at payment or at proof approval?

Payment and production start can occur on different dates

A payment timestamp proves payment, not that design inputs are complete. Similarly, a first draft is not necessarily the buyer’s approved production proof. Separate customer waiting time, revision work, production and shipping instead of blending them into a single attractive number.

Map payment, completed information, proof approval, production and dispatch as separate milestones. The seller decides which actually starts the quoted production interval. If buyer information is incomplete, a paid order may still be waiting for a prerequisite rather than already in production.

Name the event that starts the production clock

Map payment, information completion, proof approval, production start and expected dispatch as separate nodes. Ask the seller which node triggers the documented duration and how revisions affect that clock. Put the condition beside the time promise, and keep shipping estimates in their own field.

Use a milestone table with the responsible party and actual condition for each event. State whether the quoted interval ends at completion or dispatch. Avoid inventing a universal calendar rule; clarify working-day or other stated definitions only from the seller’s approved terms.

1. Do not treat as automatic start: actual order payment event.
2. Confirm completion: required buyer information.
3. Record the trigger version: identified final proof.
4. State the real starting event: production and transit fields.

A custom nameplate waits for artwork approval

Fictional exercise: a personalized plaque has a stated production period that begins after proof approval. Payment happens earlier, and the customer later corrects the name. The page explains the approval dependency and keeps transit separate. This exercise does not supply a real deadline or determine contractual rights.

For the fictional nameplate, proof approval is the confirmed start event. A revised spelling sends the artwork back for review, so the earlier approval no longer proves the changed version ready. The creative explains that dependency without blaming the customer or inventing a new dispatch date. If the buyer revises the artwork, record which milestone returns to review and who confirms the next start event. Keep the previous proof identifiable. Do not silently retain its date while changing the approved spelling, layout or product configuration.

Resolve every prerequisite and the current proof version

Fictional milestone exercise: payment is complete at event 1, buyer details at event 2, and proof v3 is approved at event 3. If the seller’s documented terms require all three, payment alone does not establish the start. Record the seller-confirmed trigger after the required conditions are satisfied; do not invent a calendar date from the first event.

If v4 changes the name after v3 approval, keep both version IDs and mark which approval applies. Ask the fulfillment owner whether work pauses, restarts or continues under the actual terms. Do not automatically reset the clock or silently carry the earlier approval onto the changed proof.

A customer-facing template can be “Production estimate: [confirmed interval] from [documented trigger], subject to [confirmed prerequisite/revision conditions].” Replace every bracket with actual approved terms or hold the promise. Record the interval’s day definition, timezone, start/end event and separate dispatch/transit estimate; no bracketed example is ready for publication.

Do not promise dispatch from an unresolved start

Stop if nobody can identify the timing trigger or revision rule. Keep the draft time promise unapproved until the actual seller clarifies it.

Stop date claims until the milestone definition and current proof status are confirmed. Keep the customer-facing explanation consistent with the actual order route. The seller’s fulfillment owner approves the calendar. AI copy assistance cannot start a production clock, know factory availability or guarantee a delivery date.

Payment to time promise: decision worksheet

Use this matrix as a manual review record and add your own real evidence. Its conditions are not completed test results.

Download this question’s review worksheet (CSV)