Quote Request Guide

The buyer journey is intentionally simple:

Buyer opens a quote request as a guest or signed-in user → print shop quotes → buyer chooses a quote → buyer signs up or signs in with the same email → order is created → accepted payment terms are confirmed → file/preflight and production information gates are completed → print shop starts production → order is delivered → buyer closes the order.

AI-assisted quote request page: /en/quote

Opening this route without a selected product shows the product catalog. Its secondary action moves to the product cards instead of linking back to the same quote page. Continuing from a product card carries the canonical product identity and label into the form. If the category is changed manually, the visible summary is refreshed instead of retaining an obsolete Custom summary.

Customer tracking and supplier feed/detail cards expose only the customer-written description; legacy internal AI trace text is removed at each projection boundary. Known category slugs use localized labels, unknown legacy slugs use a readable fallback without emitting missing-message errors, and deadlines below 24 hours are shown in hours rather than rounded to a full day.

Standard quote links open the smart page at /en/quote. To use the manual form, open the explicit manual entry choice inside that page. The existing /en/new-quote short path and /en/marketplace/new-quote manual surface remain available.

If the buyer is signed in, AI-assisted and manual quote forms prefill known name and email details when available. The buyer can still edit phone, company, delivery, or stale contact details before submitting; the form does not overwrite name/email values the buyer has typed manually.

When the buyer registers with the same email, the signup flow carries the private tracking link into onboarding. After onboarding, the buyer returns to the private tracking link. The guest request is claimed during quote acceptance, using both the matching email and the proof in the private offer link. The private tracking link continues to work.

AI readiness, confidence, and resolved-field provenance stays in structured RFQ evidence for authorized review. It is not appended to the customer description or private tracking note. A reference estimate is displayed only when the pricing authority returns a valid positive amount; an unavailable estimate is never presented as a ready zero-price quote.

Requesting quotes by email

Buyers can also start a quote request by emailing quote@nowtoprint.com. NowToPrint extracts print specifications from the subject, message body, and supported attachments. A meaningful product description and a positive quantity explicitly supplied by the buyer are required before an RFQ or tracking link is created. If one is missing, NowToPrint asks for it in the same thread. Once explicit book, novel, poetry, or story intent and a real quantity are present, the Bulut example profile may complete non-critical details such as pages, size, paper, colour, and binding. Inferred fields are marked in assumptionFields; the result is an assumption example, not an exact customer declaration or quote. An unpublished finishing rate is excluded and called out. A PDF is optional. Dimensions may be written as 19.5x27.5 cm, 19.5-27.5, or 195x275 mm; centimetre declarations are converted to millimetres before costing. Single color inner printing is explicit 1/1 buyer input rather than a system assumption. If AI extraction is unavailable, the deterministic fallback preserves only facts and explicit book intent found in the subject/body. It does not classify an empty or generic message as a book, invent a quantity, or open an incomplete RFQ. “At least 100” or “100–200” is not an exact copy count. A withdrawn delivery date is not reused, and the quote deadline does not become a delivery deadline. Independent products are never silently reduced to one request. Products in one email are first summarized as K1, K2, and so on; only the incomplete item is queried. Identify a correction with its item code, for example K2: 200 copies. Check every item and any disclosed assumptions, then reply CONFIRM code using the current code shown in the summary. No RFQ is created before confirmation. After confirmation, each product has a separate RFQ and private tracking link in the same email conversation. An old summary code is rejected. Replays and partial failures do not create completed RFQs again. One conversation supports one group of up to ten items; start a new conversation for a new group. Inner and cover components of one book, and quantity alternatives, are not separate products. If scope cannot be determined safely, the system asks you to retry or send a separate email per product.

If a file's product is unclear, identify the item code and filename. A file is never silently attached to every product. Give different files distinct names. Every item in a test-request conversation remains private. A “do not assume” instruction is preserved across the relevant items. Messages that do not identify which existing item to change make no changes. A different correction received while an operation is still in progress is not applied; follow the reply and send it again after that operation completes.

Channels try to resolve a specific canonical customer print product. Unresolved classification can be captured for operations review; it does not establish pricing, routing, acceptance, or production authority. A category/group landing page such as book, catalog, or packaging is not promoted to a product; the system may ask the buyer to clarify the L2 product. Legacy leaf aliases migrate only through the audited ledger. Quantity must be a positive integer. If the buyer does not provide a city, no city, country, or region is invented.

The Marketplace presentation group and the L2 product leaf remain separate. The server validates and stores the group as categoryGroupId for public titles, discovery, and filtering; costing and routing use only the canonical L2 productSlug. Channels carry explicit category_group or product_leaf provenance for collisions such as magazine and yearbook instead of guessing from a bare string. Broad groups such as packaging, label, and large_format never choose a product. When a separate canonical product leaf is supplied, the server only checks that the leaf belongs to the group's audited L2 category or group hierarchy.

Automated replies carry a stable delivery identity. If delivery is interrupted after Gmail accepts the message, NowToPrint recovers the sent copy before retrying; the same request should not produce a second assistant reply. If no reply arrives after a reasonable delay, reply in the existing thread instead of starting a duplicate request.

An uncertain send outcome does not authorize an automatic resend while the sent copy is unavailable. Receipt reconciliation or operational review may be required; this protection does not guarantee eventual delivery of every reply.

Automated replies include a size-bounded quote of the current customer message below the answer, including sender, date, and subject. The parser does not treat that quote or older Gmail history as a new request; it extracts new facts only from the latest text at the top of the reply.

If a temporary persistence or infrastructure step fails, the assistant does not claim that an RFQ exists or send a tracking code. It sends one honest automatic-retry notice; the buyer does not need to retype the request.

Each verified sender gets a stable opaque personal-owner identity; unrelated customers do not share one anonymous RFQ owner. Every message keeps its own hash-keyed create/amend receipt, so an older retry cannot write another revision after a newer customer reply. The bounded counter starts before Gmail download, and after five failed attempts the message moves to technical review.

Replies in that thread are evaluated as one cumulative conversation. Recorded text and eligible retained file evidence can be reused, so a follow-up may contain only the missing quantity. Free-path attachment bytes are not retained for later use. Once an RFQ exists, a follow-up revises that RFQ instead of creating another one. Material changes make existing quotes stale and require suppliers to reprice the new RFQ revision. When a manual or Auto-Bid exact quote is placed, a buyer-safe summary, PDF, and signed review link are delivered in the original Gmail thread instead of a new unrelated message. Delivery is deduplicated by the durable quote event. A missing thread route, RFQ revision, or verified requester email fails the event for retry and bounded technical review rather than acknowledging a silent success. The RFQ revision priced by a manual quote is taken from the canonical RFQ by the server; form or API input cannot override it. Before sending mail, the event quote/RFQ identities, the quote's RFQ binding, current and thread revisions, and requester/thread recipient emails must match exactly. A cross-bound or malformed event creates no notification, link, or email.

For any exact manual or Auto-Bid quote, the email's Review quote link opens a quote-, RFQ-, and revision-bound guest capability page. The buyer can review the buyer-safe quote without signing in; accepting the quote then asks for an account or sign-in with the same email used for the request. The raw capability is not stored in Firestore, only its SHA-256 lookup hash, and the link expires. Preliminary pricing does not receive an acceptance link.

PDF, plain-text, and CSV attachments are supported. One message may contain up to 5 attachments, 25 MB per file, and 40 MB in total. Files whose declared type does not match their content, unsupported files, and files over these limits are reported by filename. Inline AI document analysis is limited to 10 MB per file and 12 MB in total. A larger valid file may still be stored privately with the RFQ; the confirmation explicitly says when its contents were not read automatically.

Email attachments follow the sender's authorised processing path. The application distinguishes an eligible paying sender from a free or unrecognised sender; an account or authority lookup failure does not grant heavier processing.

• Eligible paying sender: attachments can be kept as private, SHA-256-verified references rather than public download links. They are stored before the independent scan, with distribution closed until a matching clean receipt is available. Only clean files can enter model analysis or the server preflight path.
• Free or unrecognised sender: attachments still go to the independent external malware scanner. Clean PDFs can be read for light file information in temporary server memory. This path does not persist the attachment, send its bytes to the model or run server preflight. Light page/size information is not a preflight report, readiness verdict or retained production file. This does not erase the original message from the mail provider.
• Scanner unavailable or rejected file: the text request can continue, but the file is not treated as clean. Persisted files remain private and quarantined; a non-persisting path does not promise a stored file for later recovery. A filename such as 56 PAGES may supply a clear buyer declaration; it is not proof that PDF contents or dimensions were measured.

For the authorised server path, a clean PDF is submitted to Runtime V2. A processing/job receipt does not establish measured pages, size, score, verdict, a report or production proof. Those claims require terminal evidence bound to the same source, request, job, profile and artifact. PDF preflight is separate from malware screening.

Each retained production component needs its own current evidence. Multi-component work cannot be reduced to one accepted PDF: missing component revisions or handoffs keep production-file readiness pending. Text and quoting can continue where the commercial gates allow, while price-critical assumptions can still block an exact automatic quote.

AI assists with extracting fields from unstructured text and documents. Canonical validation rules decide how the RFQ is safely persisted, which fields are missing, and which deterministic message template is sent. Missing-information signals do not themselves block publication; each channel still validates its own submission contract. AI cannot invent a price or an uncertain technical specification.

Buyer flow

1. Open /en/quote.
2. Describe what you want to print, select the product type, and provide the real quantity; upload files when available.
3. Enter name and email, then add city, delivery expectation, and other technical details when available.
4. Submit the request.
5. Track quotes from the private email link.
6. Choose one quote.
7. Sign up or sign in with the same email.
8. Complete onboarding if the account is still pending.
9. Continue from the created order.

Book and publication requests

Book-like requests, including novels, magazines, annual reports, yearbooks, photo books, and product catalogs, are checked against the Master Data publication model before they can move into supplier-facing RFQ handling. The platform records trusted catalog evidence and an immutable Master Data evidence record for these requests.

If a Book/publication request arrives without trusted Master Data evidence, it still stays published as a valid request; it does not wait for admin or steward approval before first publication. In that case, the system disables risky automation such as Auto-Bid, one-click quoting, and production handoff, then sends the request to operations review.

These requests remain published for the buyer and public request record. On the print-shop side, becoming an open quote opportunity depends on scope and production-fit review. The same review evidence is preserved when the buyer accepts the quote into an order. Admins can separately pause visibility or quote intake under the applicable policy.

Provide a meaningful product, explicit positive quantity, and contact details so the printer can quote the intended job. Channel validation differs: the manual form requires its current product/quantity/contact fields, partner create requires its catalog context and schema, and the email creation guard asks for missing product description or quantity. Do not treat a tracking link as evidence that all technical fields are complete.

The shared completeness policy records missing product, quantity, city, size, paper and other fields as follow-up work; it does not itself block publication. Public reads require a public record and a schema-valid projection with status and creation time. Missing product grounding or quantity does not automatically hide an already public record; invalid/missing quantity is omitted from that projection. This read permission is distinct from supplier eligibility, actionable quote authority, and production readiness. Admin visibility controls can separately pause publication.

Current RFQ snapshot policy kinds are intentionally family-scoped: book_publication_required, p0_non_publication_snapshot_advisory, and generic_soft_link. Book-like product-catalogs and catalogs requests require trusted publication evidence before supplier-facing automation; non-publication families stay advisory for RFQ intake and are reviewed before risky automation.

Guest continuation rule

The request is tied to the email used at submission. If the buyer later signs up with the same email, the request can continue after onboarding. A pending-onboarding account cannot create the order yet; it is sent back to onboarding with the private tracking link preserved. A different email cannot claim the request in self-service.

Supplier rule

Only approved producers can quote. A registered print shop cannot see active RFQs or quote until admin approval is complete.

A print shop can open an RFQ for its own buying need, but the same organization cannot quote its own RFQ as a producer.

Print shops cannot see competitor quote rows, prices, print shop names, or aggregate quote/view counts. That information is visible only to the buyer and the required admin/operations roles.

Quote revisions and validity

A quote is not valid forever. During first live, quote validity defaults to 7 days and must stay within the supported 1-30 day range. If the buyer needs a small change, request a revision from the same RFQ/quote context instead of losing the thread.

A print shop may correct a newly submitted open quote through that same quote during the first 15 minutes after creation. The end instant is exclusive: quick edit is closed at exactly minute 15. Later price or delivery changes require a buyer revision request in the same quote context. Accepted, ordered, rejected, withdrawn, or expired quotes cannot be changed unilaterally. The edit form reloads the current amount, delivery days, shipping, tax declaration, notes, and variants; a stale browser cannot overwrite a newer revision.

The canonical money authority is the currency-aware minor-unit record. The UI derives the displayed major amount from it and does not hide a malformed canonical value with a legacy field or zero. Accepted quotes in different currencies are reported as multiple currencies instead of being added together and labelled as TRY.

The quote closes at the exact validity timestamp shown in the quote; it cannot be selected at or after that instant. If the stored validity or a required excluded shipping charge cannot be verified, the platform stops order creation and asks for a corrected quote instead of assuming an unlimited deadline or a zero shipping charge.

RFQ and quote details are private account resources. Opening a copied dashboard/action link still requires sign-in and the buyer, supplier or organization ownership appropriate to that resource; knowing an RFQ id, tracking code or quote id is not authorization.

A personal RFQ owner can read only the quotes whose RFQ record names that account, even when no organization or package context exists. This personal ownership authority is separate from an organization's shared received-quote inbox and never grants access to another buyer's request. After a deterministic access denial, the page stops background polling, shows a localized error, and offers an explicit Try again action. An unverified quote list is not silently presented as “0 quotes.”

Once the buyer accepts a quote, the accepted price and delivery snapshot are locked for that job scope. A supplier cannot change the accepted price unilaterally. If the file, quantity, size, or production scope changes, the buyer and print shop must agree on a revision through the tracked quote/order context. RFQ and quote changes are append-only revisions. The current document is a read projection; every accepted change advances its revision and writes an immutable sourcing or commercial snapshot in the same transaction. A stale browser receives a revision conflict instead of overwriting newer work.

If a network or channel retry arrives after the first durable write, the platform returns the original RFQ instead of creating a second request or notification. If the RFQ changes while Auto-Bid is calculating, that old calculation is not committed as a quote. The new revision is priced again, while an older quote keeps both the revision it priced and the later revision that made it stale.

Manual-review RFQs can remain published and collect supplier offers. Steward/publication/abuse review is a notice and does not itself disable quote selection. A separate explicit supplier-quote pause does block submission. Acceptance still checks the exact pricing mode, ownership, current quote/RFQ and applicable execution snapshot evidence; a preliminary reference is not awardable. Review notes do not establish production-file readiness.

Buyer-safe review and comparison

The public RFQ flow shows the buyer the normalized print specification needed to review the request. Internal source references, Master Data lineage, and standards traceability are operational evidence and are not exposed on the public buyer page.

One exact quote is a selectable offer, not a comparison winner. Best-value, lowest-price, fastest-delivery, ranking, and recommendation language is enabled only when at least two awardable exact quotes can actually be compared. If the best-value scores tie, the interface does not choose an arbitrary winner; the buyer reviews the commercial terms and makes the decision.

When a quote is selected

When the buyer selects one quote:

• the selected quote becomes an order,
• the other quotes close,
• the order appears in the buyer dashboard,
• the print shop sees the order with production gates still enforced.

If the accepted quote has one verified PDF, the platform pins that source to the order by hash. A missing file, multiple production components, or insufficient preflight evidence does not block the commercial order in every case, but it does keep production-file readiness pending and asks for the missing evidence.

An output created with PDF Tools/Organize or a later replacement upload never silently overwrites the accepted file. Explicit buyer approval creates a new revision and invalidates prior preflight, imposition, and file-bound costing evidence. The print shop can start production only after the current revision is bound to exact imposition, postflight, and any required proof evidence.

Before the quote becomes an order, the system verifies that the buyer-observed quote/RFQ summary and production handoff package have not changed. If that evidence is missing or stale, the buyer must refresh the comparison; the RFQ can stay published, but the order/production gate does not move forward.

Buyer order dashboard: /en/dashboard/my-orders

Print shop order dashboard: /en/dashboard/print-shop/orders

Payment scope

NowToPrint is your point of contact for payment. Card payment is not part of the live pilot.

Payment is confirmed through bank transfer, open-account or corporate payment terms, or manual approval by the operations team. Before production can start, the accepted financial release condition and required print file, preflight review and production information must be satisfied. Production starts only after the required information and approvals are complete; the confirmed delivery time is determined accordingly.

When does an order close?

The print shop delivers the order. The customer checks the delivery and closes the order. If something is wrong, the support team joins the process.

Related pages

Request saved but files were not attached

In the manual form, request creation and file attachment are separate operations. Existing-RFQ upload is disabled by default under the server risk-mutation switch; the retry procedure applies when this capability is enabled. If uploading fails, a persistent notice remains on the confirmation screen. Retry file upload attaches files to the same request without creating another one. When browser storage is available, the submitted request survives closing and reopening the tab in the same browser and account; it is not presented as an unfinished draft. Upload completion in another tab also updates this screen. File bytes are not stored in the browser; after reloading, select the same interior PDF and, if included before, the same cover PDF.

Uploading requires an account authorized for the request. Guest requests are not claimed merely by registering with the same email: quote acceptance must use the proof in the private offer link. The screen distinguishes sign-in, access, file validation and temporary connection errors. A saved request does not imply that files were attached or production started.