Quote delivery, documents & e-signature

The “propose and close” loop: getting an approved quote in front of the customer, seeing when they engage, and letting them accept and sign — no login required.

Core objects

Share links — tokenised, unguessable public links to a quote. A link is keyed by its token (never the quote id), can carry a recipient and an optional expiry, and can be revoked. Each has an engagement timeline.
Share events — the buyer-engagement timeline: SENT, VIEWED, DOWNLOADED, ACCEPTED, REJECTED and SIGNED, with IP/user-agent context.
Quote PDF — the customer-facing document: a branded, fully laid-out A4 quotation generated server-side. See The quote PDF below.
Signatures — captured on acceptance and stored with a SHA-256 hash, method, signatory details, timestamp and device info. The same store backs standalone signature requests — see E-signature.

The quote PDF

One generator (pdfmake, using the PDF standard Helvetica fonts so it never depends on font files being present on the server) produces this document on every delivery surface — the rep-side download, the public share-link download, the file attached to the quote email, and the mobile app’s download/share. It renders:

A branded header band — your company logo (fetched and embedded; if the logo is missing or unreadable the header falls back to the legal name), legal name, address, phone/email/website, and tax registration (GSTIN, PAN, CIN).
Title and quote meta — a large QUOTATION title, a colour-coded status badge (draft, in review, pending approval, approved, presented, sent, accepted, declined, rejected, expired, cancelled), and the quote number, date and valid-until date.
Bill-To and Quote-information panels — customer name, code, contact, email, phone, billing address and GSTIN alongside quote name, currency, payment terms, delivery terms and price book. Fields that are empty are simply omitted.
A zebra-striped line-item table — product code, name, an optional product-type tag (PRODUCT, BUNDLE, SERVICE, SUBSCRIPTION, plus OPTIONAL on optional lines) and description, against quantity, list price, discount %, net price, tax and line total. The header row repeats on every page and a line’s cells are never split across a page break.
A pricing summary — subtotal, discount and tax, closing on an emphasised grand-total bar. Amounts carry the ISO currency code (INR 4,65,972.00) because the standard fonts cannot render most currency symbols.
Commercial terms — the quote’s terms and conditions (or its notes), shown only when present.
An acceptance block — signature, name & title, date and purchase-order reference lines for signing and returning a copy, alongside a note that the quote can instead be accepted online from the secure link in the email.
A legal footer on every page — legal entity, GSTIN/CIN, a confidentiality line, the quote number and Page n of m. Continuation pages also carry a slim running header.

It intentionally excludes internal fields such as cost and margin.

This layout is fixed. Generating a document from a quote template is a separate path that renders that template’s own arrangement instead — see Quote templates and generated documents below.

What you can do

Rep side (authenticated):

Send a quote by email — the dialog prefills the recipient’s name and address from the quote’s customer, attaches the PDF and puts the public link in the body. Sending is open/click-tracked and moves the quote to SENT.
Each send mints a fresh link tied to that recipient. The quote’s engagement card lists every link with its status and event timeline, and lets you copy a link or revoke it so the public URL stops working.
Download the quote PDF.
Get an in-app notification the first time a customer opens a shared quote, and when they accept or decline.

If your mail server rejects the message, the send fails with the actual reason rather than a generic error — and when the failure is that email simply isn’t configured in this environment, it says so. Either way the share link has already been created, so you can copy it from the engagement card and send it yourself.

Customer side (public, no login, rate-limited):

View the quote and download its PDF via the share token. Downloading the PDF is recorded on the timeline.
Accept the quote. Full name, email address and agreeing to the terms are required; a signature is optional and can be drawn with a mouse or finger or typed and rendered in a signature face. Acceptance moves the quote to ACCEPTED.
Reject the quote with an optional reason (moves it to DECLINED).

Accept and reject are open only once the quote is approved, presented or sent — a link shared from a still-draft quote is view/download only. Note that emailing a draft moves it to SENT, which opens both actions, so send a draft only when you are content for the customer to accept it as it stands.

The public quote payload is whitelisted, so internal fields never leave the tenant, and public endpoints are rate-limited per IP.

Recording the answer yourself

Customers frequently accept out of band — on a call, in a reply to your email, or by signing and returning the PDF. Record Acceptance and Record Decline on the quote let an authorised user capture that decision directly, so the path to a sales order never depends on the customer using the online link.

Both actions are available from APPROVED, PRESENTED and SENT, the same statuses the customer-facing link honours — a draft can never be accepted, and a quote that is already accepted, declined or converted is refused with an explanation of why. The buttons appear only for users who can update the quote.

Every quote therefore carries a small acceptance record regardless of route: who accepted or declined, their email, the time, and whether it came in through the customer link or was recorded internally. Declines also store the reason you typed. Conversion downstream reads that record — a sales order or contract can only be raised from an ACCEPTED quote, an approved-or-sent one is turned away with a prompt to record the acceptance first, and a DECLINED quote has to be revised and accepted again before it can be converted.

E-signature

E-signature is built into CPQ. Signatures are captured, hashed and stored by CPQ itself — there is no third-party e-signature account to buy or configure.

A signature belongs to a document — quotes in practice today, with contracts, proposals, amendments, renewals, order forms and NDAs covered by the same record — and holds the signatory’s name, email and role, the signature image, a SHA-256 hash of that image, the method used, the signing timestamp, and the IP address and device the signature came from.

On acceptance. When a customer signs while accepting from the share link, the signature is written before the acceptance is recorded, so an acceptance can never end up without the signature that was drawn for it. It lands as a signed, customer-role signature attached to the quote and also appears on the engagement timeline as a SIGNED event.

As a request. You can also ask a named signatory to sign a document. The request is created as pending with a verification code and an expiry (30 days unless you shorten or extend it), and the signatory is emailed a signing link, the code and any covering message you added. From there:

Action	What happens
Sign	The signatory agrees to the terms and submits their signature; it is hashed, stamped with the time, IP and device, and the request becomes `SIGNED`
Reject	The request becomes `REJECTED`, the reason is kept, and a rejection notice is emailed
Resend	The invitation email goes out again — pending requests only
Cancel	The pending request is withdrawn

Past its expiry date a request can no longer be signed, and only pending requests can be signed, rejected, resent or cancelled at all — once a signatory has answered, the record is settled.

When every signature on a document is complete, CPQ finalises it and emails all signatories to confirm the document is fully signed.

Verification. Any signed signature can be re-verified on demand. CPQ recomputes the hash of the stored signature image and compares it with the hash recorded at signing, and checks that the timestamp, originating IP and signed status are all present and consistent. You get back an overall valid/invalid verdict plus each individual check, which is what you show when someone questions whether a signature was altered after the fact. One caveat for signatures collected through a request: the check also takes the request’s expiry date into account, so a verification run after that date reports invalid even when the signature itself is intact.

The Signatures screen (Admin → Security & Approvals → Signatures) is where outstanding requests are monitored: it lists what is pending and handles resend, cancel, reject and verify. Raising a request and submitting a signature from that screen are not complete — the forms there do not yet carry the signatory’s name and role, or the signature image itself, which the signature API requires — so both remain API operations for now.

Sending from the sales app

The Android sales app hands out the same branded PDF as the web app: it fetches the finished document from the server rather than drawing its own, so there is never a second layout to keep in sync. The quote’s PDF preview screen shows an on-screen summary of the quotation, and three actions work on the real file behind it:

Download opens the PDF in whichever viewer the device has.
Share hands the PDF to the Android share sheet.
Email opens the mail app with the PDF already attached and the quote number in the subject.

Those hand the document over directly, from your own mail app or whatever you share to. The full delivery — PDF attached, public accept/decline link, engagement timeline — is a web-app send.

Email engagement tracking

Every quote emailed from the web app is tracked. CPQ embeds a 1×1 pixel and wraps the quote link in a redirect, then records:

Opens — the first open, the most recent open, and a running count.
Clicks — the first click on the tracked link and a running count.
Status — the record moves from sent to opened to clicked as the customer engages.

Two views are available over that data: everything sent for one quote, and a company-wide summary over a rolling window (30 days by default) giving totals sent, opened and clicked plus open and click rates. Both are read through the API. In the app, the day-to-day view of a single deal is the quote’s engagement card, which reports link views, PDF downloads and the accept/decline outcome rather than mail opens.

Two things worth knowing. Open tracking depends on the recipient’s mail client loading images, so opens undercount for anyone who blocks them — clicks are the firmer signal. And tracking covers the quote emails sent from the web app’s Send to Customer dialog; other notifications CPQ sends are not part of these figures.

The tracked link only ever redirects to http/https destinations, so the wrapper cannot be reused to bounce someone somewhere unexpected.

Quote templates and generated documents

Alongside the built-in quote PDF, CPQ keeps a library of quote templates — reusable arrangements of the sections a quotation document should contain, for teams that want a proposal-style document rather than (or as well as) the standard quotation.

A template carries a name and code, a description, a classification — standard, product family, customer segment or promotional, with the family or segment it applies to — a status of draft, active or archived, and an optional default flag. Its body is an ordered list of sections:

Section	What it renders
Header	Company block, the quotation title, quote number, date and validity
Products	The quote’s line items
Pricing summary	Subtotal, discount, tax and grand total
Terms & conditions	The commercial terms you write into the section
Signature block	Signature, name and date lines
Custom	Free content you write yourself

Sections can be reordered, hidden without being deleted, and edited at any time. The template’s own page carries a Quote Preview tab that renders the assembled quotation so you can see the shape of the document (and print it) before anyone uses it. A finished template can be duplicated as the basis of a variant, made the default, activated or archived.

To produce a document, open a quote’s version history, choose Generate Document and pick a template. CPQ merges that version’s snapshot into the template — header, product and pricing sections fill themselves from the quote, and anything you wrote yourself has its {{placeholder}} merge fields substituted. The assembled document appears for review, and can be downloaded as an A4 PDF rendered from that preview.

This is a different document, produced a different way, from the quote PDF described earlier. The PDF that CPQ attaches to the quote email, serves on the share link and streams to the mobile app always uses the built-in branded layout; templates never change it.

Email templates

Email templates are a separate library, organised by purpose — quote sent, approval request, expiration reminder, quote accepted, quote rejected, follow-up, quote reminder, document ready and signature request. Each carries a subject line and an HTML body written with the same merge placeholders, has a preview tab that renders the body as the recipient will see it, and can be deactivated rather than deleted so old copy stays on record.

These are your own reusable copy. The quote email CPQ sends from Send to Customer is composed by the delivery layer itself and does not read from this library.

Connects to

Quotes & approvals — only sendable statuses (draft, approved, presented, or already sent) can be shared; a quote in review or pending approval is refused until approval completes, and a finalised one can no longer be sent. A link created on a still-draft quote is view/download only. Acceptance closes the loop.
Orders & contracts — an accepted quote can be converted onward.