Customer operations

From enquiry to accepted quote: the workflow behind the PDF

Turn a customer request into a reviewed offer, a verified buyer response and an accountable next action without losing the commercial history.

WRKZY EditorialProduct learning and Help editorial team
guide7 min readUpdated August 5, 2026

The message is simple: can you supply a bulk rollout kit, implementation and team enablement before the next store opens?

A quick reply is easy. A reliable quote is not. Maya has to identify the buyer, confirm the scope, use current prices, resolve approval, send the right version and know what should happen after Aarav responds. Put those decisions in separate messages and spreadsheets and the team can send a beautiful quote while still losing the customer outcome.

We will follow one illustrative offer—Q-2026-014, Revision 2, for ₹1,85,000—from Aarav’s WhatsApp enquiry to a verified response. The amount is incidental. The operating chain around it is the real subject.

A sales operator and finance teammate review a buyer-specific offer together across a laptop and phone.
A quote is a shared decision workflow before it is a document.

A quote is a decision, not a PDF

It is tempting to treat quoting as document generation: collect line items, make a PDF and send it. That model stops too early. The customer is making a decision, and the seller needs to know that the right offer reached the intended buyer, received a clear response and created owned follow-through.

A stronger outcome is:

The buyer can understand the current offer, ask a question, request a governed change, decline, or accept—and the team can see which version, amount, and next owner that response belongs to.

That outcome needs a connected sequence. Each state should have its own evidence instead of borrowing certainty from the state before it.

WRKZY operating modelOne enquiry, one current offer, one accountable decision
  1. 01Customer requestSourced enquiry and responsible owner
  2. 02Reviewed scopeCatalog items, quantities, price, and currency
  3. 03Controlled quoteRecipient, terms, validity, and approval
  4. 04Buyer decisionVerified review and recorded response
  5. 05Follow-throughNamed owner and next commercial action
Customer context grounds the scope; internal review governs the offer; controlled delivery and buyer verification establish the response path; the recorded decision creates the next owned action.
StateOperating questionEvidence to inspect
EnquiryWhat is the customer actually asking for?Source conversation and verified customer context
DraftDoes the offer match that request?Buyer, catalog lines, quantities, totals, terms, owner
ApprovalDid an authorized person review this exact commercial state?Approval status, reviewed snapshot, and decision reason
Published and sentWhich current revision was made available, and through which channel?Quote lineage, recipient, channel, and delivery history
Buyer responseWhat did the buyer choose against which offer?Verification event, selection, revision, amount, response
Follow-throughWho owns the work created by that decision?Linked deal, handoff, owner, due action, and current state

Begin where the request arrived

Maya begins in the customer work that created the request. She confirms Aarav, Mehta Stores, the relevant conversation, the open deal, the intended currency, and the latest commercial question. She also searches for an existing draft or revision before creating another offer.

This first step prevents two common failures. The first is quoting the right product to the wrong customer context. The second is creating competing “latest” versions because somebody started from a blank document instead of the current commercial record.

In WRKZY, Customer Context connects the contact, company, conversation, and open commercial work needed for the next decision. Catalog supplies reviewed product and service records. Quotes turns that material into a buyer-specific offer with its own validity, terms, approval, revision, delivery, and response history.

The boundary matters: the conversation explains the need; the catalog defines reusable offers; the deal carries working commercial scope; and the quote records what this buyer can act on now.

Build the offer the buyer can actually inspect

For Q-2026-014, Maya selects the reviewed rollout kit, implementation service, and enablement service. She then checks the fields that make the offer specific to Aarav’s decision:

  • buyer and company;
  • linked deal and accountable owner;
  • currency, quantities, unit prices, discounts, tax, and total;
  • packages or optional lines, including any buyer-editable ranges;
  • validity, payment terms, delivery assumptions, and exclusions; and
  • buyer-facing branding, notes, and section visibility.

The catalog default is a starting input, not permission to skip judgment. A current product price may still be wrong for the buyer’s approved segment, quantity, currency, or effective period. The team should understand any difference between the quote total and the linked deal rather than forcing the two records to match silently.

WRKZY New quote builder showing required title, INR currency, optional validity, required recipient, linked company, deal, and owner context, plus an empty quote summary.
Look forIdentity · recipient · offer readinessOpen larger ↗
  1. 1Quote identity, currency, and validity
  2. 2Required recipient and linked context
  3. 3Current offer summary
This current first-use builder shows the buyer, currency, validity, and readiness fields that must be established before an offer is assembled. It is setup evidence—not proof of a completed, approved, or delivered customer quote.

Evidence boundaryThis empty-state capture proves the quote's required identity, currency, recipient, linked context, and live summary structure. It does not prove populated line items, approval, publication, delivery, or buyer response.

Use the customer quote creation and review guide as the pre-send operating checklist. Reopen the saved draft and confirm its status, totals, validity, approval state, linked context, preview, and follow-up owner.

Approval, publishing and delivery are separate events

These states are related, but none proves the next:

  • Approved means an authorized decision was recorded for the reviewed snapshot. It does not mean the quote was published or sent.
  • Published means controlled buyer access was created or refreshed. It does not mean the provider delivered the message.
  • Sent means a provider send was recorded. It does not prove delivery, viewing, or agreement.
  • Delivered is provider-reported delivery. It does not prove that the buyer understood or accepted the offer.
  • Viewed means the secure quote page was opened. It does not identify every viewer or prove purchase intent.
  • Accepted means the buyer submitted a governed response against the offer. It does not mean the downstream deal, invoicing, or fulfilment is complete.

For Acme Retail, an approver reviews the exact Q-2026-014 snapshot: buyer, scope, totals, discount, tax, validity, and terms. If the decision is rejected, the reason should tell Maya what to change. The team does not temporarily change value or scope to avoid an approval rule.

When the quote is ready, Maya uses the supported email or WhatsApp share flow rather than copying a secure URL into an unrelated conversation. That keeps the intended recipient, provider attempt, attachment behavior, status, and timeline connected. The quote sharing guide explains the channel preflight, including the WhatsApp customer-service window and approved-template paths.

Design the buyer’s side of the decision

The secure buyer page can present the approved brand, current quote number, validity, packages, line items, quantities, prices, tax, total, notes, and terms without giving the buyer access to the internal workspace. Within the seller’s pre-approved rules, a buyer may compare packages, select optional lines, or adjust allowed quantities before responding.

Before a consequential response, WRKZY can ask the buyer to verify through the configured email or WhatsApp path. The response can capture the buyer-provided name, role, authority confirmation, selection, revision, and amount.

The buyer can accept, decline, ask a question, or request a structured change to product, price, scope, terms, or timing. Those are different operational outcomes. A question needs a response owner. A change request needs a new reviewable revision. A decline should inform an honest deal update. Acceptance creates a handoff rather than ending the workflow.

Archived WRKZY buyer-facing offer showing offer identity, value, customer, validity, archived state, one scoped item, tax, and total due.
Look forOffer state · scoped item · totalOpen larger ↗
  1. 1Offer identity and value
  2. 2Archived status is explicit
  3. 3Scoped item and commercial total
This archived buyer page proves that an earlier offer can remain visible as lifecycle evidence while no longer being actionable. It does not demonstrate an active offer, verification, delivery, or buyer acceptance.

Evidence boundaryThis proves the structure and explicit inactive state of one buyer-facing offer. It does not prove an active verification session, a submitted buyer response, acceptance, or downstream fulfillment.

An active current revision should make available actions clear. An expired, voided, archived, or superseded quote should explain that it is no longer actionable and direct the buyer to the current path. The public state is part of the decision experience, not decoration around the PDF.

Revise forward; do not edit history

Suppose Aarav asks to move the start date and reduce an eligible quantity. Maya should not edit the sent offer. She creates a revision in the same lineage, reviews what was added, changed, or removed, recalculates totals and tax, and repeats approval when the new state crosses the workspace’s rules.

The older offer remains evidence of what the buyer could previously act on. The new revision becomes the current path where applicable. This is why “Revision 2” is operationally meaningful: it lets the team answer which terms were offered, which response belongs to them, and what changed next.

The approval and revision guide covers this workflow in detail.

Acceptance starts the next piece of work

When Aarav accepts Revision 2, the recorded response preserves the accepted amount and currency. Maya then checks the selected package or quantities, verification evidence, linked conversation, contact, and deal. She reconciles the accepted offer with the deal deliberately; recording reconciliation does not silently change deal value, currency, status, or stage.

The next action might be an implementation handoff, an order or billing step in the organization’s approved system, or a customer confirmation. Whatever the process, name one owner and a due point. “Quote accepted” is a commercial decision, not proof that every downstream commitment is complete.

Measure the chain, not just the conversion rate

Review a small sample of quotes each month and track signals the team can improve:

  1. time from the enquiry to a named owner;
  2. time from complete scope to approval-ready draft;
  3. drafts blocked by missing buyer, terms, prices, or approval;
  4. delivery failures and repeated sends before root-cause correction;
  5. questions or change requests without an owner or due action;
  6. revision count and the reason for each material change; and
  7. time from verified acceptance to the first owned downstream action.

Do not treat sends, views, or acceptance rate alone as proof of a good workflow. A fast acceptance built on the wrong scope is not success. The goal is a decision the buyer can understand and a team can carry forward without reconstructing the commercial history.

For your next representative offer, test the WRKZY quote workflow from draft to verified buyer response. Start with the exact customer request, inspect every state separately, and finish only when the resulting work has a visible owner.