Build a quote-drafting automation

Who would use this?

A supplier with a maintained product catalogue and repeat quoting work.

Staff retype product requests and look up the same prices, but an incorrect quote can damage margin.

A concrete pilot offer

A quote-drafting pilot that converts requests into line items, uses deterministic pricing and routes the draft for approval.

Build the workflow

1. Extract requested product IDs, quantities and required options.
2. Resolve each product against the trusted catalogue; ask about ambiguous matches.
3. Calculate unit price, tax and totals in code using the approved price version.
4. Present assumptions and a draft expiry date to a reviewer before sending.

Walk through the example

The full prompt

Replace the bracketed inputs. Use synthetic or appropriately permitted data. The prompt drafts a result; the surrounding application must enforce permissions, checks and approvals.

Extract quote requirements from REQUEST using CATALOGUE only. Return product_id, quantity, requested_options, ambiguities and missing_fields. Never invent a product, price, discount or tax treatment. Leave all calculated totals to application code. Do not send a quote. Mark status: needs_review if any requested item lacks an exact approved match.

REQUEST: [redacted request]
CATALOGUE: [approved IDs, names, options and version]
OUTPUT: status, line_items, missing_fields, ambiguities, catalogue_version

Test before delivery

• Unknown products never receive invented prices.
• Totals use integer minor units and the correct currency.
• A changed price version invalidates the old draft.

Measure: Draft preparation time and pricing correction rate.

Is the workflow worth a pilot?

Replace these sample assumptions with the buyer’s figures. Time capacity is not automatically cash savings or revenue.

Delivery effort, setup fees, error costs and demand are not included. Validate the assumptions during the pilot before using them in a proposal.

Scope the service before quoting

Agree the input volume, exact output, integration access, human reviewer, acceptance tests and handover owner. Quote implementation effort separately from ongoing software, API usage and support. Validate customer demand through real conversations.

These examples demonstrate a possible service. They do not report client results or establish an income expectation.

Keep the guide

Go deeper into the engineering

The linked note includes additional examples and primary documentation. Provider capabilities change; check the relevant docs before implementation.