Taking a quote request in

1. In Settings -> Seller, create an offer with pricing unspecified and activate it. That is the whole difference between this flow and a fixed-price sale: an unspecified offer has no amount, so an order against it opens in pricing and waits for you.
2. In Reception, create one public intake form for enquiries. Require visitor email. This recipe declares the answers it reads in requires_form_fields, so pairing it to a form that spells them differently is refused while you are still setting up rather than storing nothing on every submission.

- Destination: form_response. ⛔ Not task — that destination materialises its own record from the visitor's answers on approve, which is not what you want in front of an order.

1. Accept a test response, open it in Data -> Form responses, choose Automate this form, and clone this installed template. The clone is scoped to that exact form; installing the pack never arms a public trigger.
2. Set Seller offer to the unspecified offer's id and Sender account to a registered send-capable mail account.
3. Run one accepted response manually. The card shows the order handle — the only order id a customer may ever be shown — the order sitting in pricing, and the request record this run wrote.
4. Price it with Price and send a quote. Arm the exact-form trigger only after one request has gone end to end.

⚠ Nothing here names a price, and that is structural rather than stylistic: core.seller.order.open refuses an amount argument outright, so the offer row is the only thing that can carry money and an unspecified offer carries none. The total arrives once, from you, through core.seller.order.quote.

What gets stored locally

Two things are written, in two different places, and they answer different questions.

• The order lives in the seller store and is the authority on phase and money. Nothing here copies that.
• The request record lives in this pack's Records storage and holds what the order cannot: the customer's own description of the work, who to address the quote to, their address, the order handle, and when they submitted. Price and send a quote later adds the subject and covering note it emailed.

The row id is derived by the kernel from (offer, submission), so it is the same row on every delivery of the same accepted response.

The run looks for that row before creating it, and the reason is recovery rather than duplication. Open a quote request reports the order as already open on every delivery after the first, so a write gated on that alone would skip forever if a run died between opening the order and writing the row — and the request would never reach the board at all. Gating on the search instead means the next delivery notices the row is missing and writes it.

⚠ requested_at is the visitor's submission time, not the moment the row was written. Sort a board on it for the customer's chronology and on _record.created_at for what this pack learned when — after a recovery run those two are legitimately far apart.

⚠ The description is stored up to 4000 characters, where the card still shows the first 500. The stored copy is the one the board reads.