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 → payment is 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.

Manual quote request short path: /en/new-quote. It redirects to the technical manual pilot surface at /en/marketplace/new-quote.

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 is complete, guest quote requests opened with that email are linked to the new account and the buyer returns to the private tracking link to continue. 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, product type, 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.

Email and MCP requests resolve to a specific canonical customer print product. A category/group landing page such as book, catalog, or packaging is not promoted to a product; the system asks the buyer to select an 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.

Every automated reply quotes 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. PDF files and print facts from the first message remain available, so a follow-up may contain only the missing quantity. 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.

Attachments are not stored as durable download links on the RFQ. They use a private SHA-256-verified file reference. After a clean scan, a PDF is submitted to the canonical Runtime V2 preflight queue. An initial processing/job receipt does not claim measured pages, size, score, verdict, report, or production proof. Those claims require terminal evidence bound to the same source, request, job, profile, and artifact. PDF preflight is not a malware scan. A file remains quarantined and cannot be distributed to suppliers or public surfaces until an independent scanner returns a clean result. Email and MCP PDF intake use the same hash-verified, fail-closed scanner boundary. Book interiors and covers use the interior and cover file roles.

If the independent scanner is temporarily unavailable, the text RFQ and quote flow can continue, but attachments are never assumed clean. They remain in private quarantine and do not enter AI, supplier distribution, or production handoff without a clean scan receipt. If a quarantined PDF filename contains one unambiguous declaration such as 56 PAGES, that value may be carried into the RFQ only as buyer-declared metadata. It does not claim that PDF bytes were measured. Page size and other file facts remain unmeasured until clean scanning and terminal Runtime V2 preflight evidence finish; Auto-Bid stays fail-closed while a price-critical assumption remains.

When several PDFs arrive, each file keeps its own SHA-256 scan receipt and preflight evidence. A rejected file, or a file without a clean scan/preflight receipt, is never passed to AI, quote evidence, or production handoff; the text RFQ may continue with an explicit quarantine note. At quote acceptance, an inside block, cover, or insert is not collapsed into one accepted PDF revision: each component needs its own accepted revision and production handoff, otherwise the order remains component_handoffs_required.

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. Ordinary missing information does not block RFQ intake. 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 only close visibility for spam/fraud, rejected/cancelled, or later-paused requests.

For every print request, what is being printed, a server-resolved canonical L2 product leaf, a meaningful product category, and a positive quantity explicitly supplied by the buyer form the minimum publication evidence. If any of these is missing, or quantity exists only as a system assumption, no RFQ is created or sent to print shops yet. The system asks for the missing critical information in the same conversation; after completion it creates the RFQ and shares the real tracking link.

For requests such as flyers, labels, packaging, and large-format work, missing size, paper, binding, city, deadline, file, or other non-critical technical information does not by itself prevent publication. The gaps are tracked as an operations signal; the system can disable Auto-Bid and other risky automation while keeping a request that passed the minimum gate in the print-shop opportunity flow.

Public list and detail reads do not trust a stale isPublic flag by itself. They re-check critical completeness, positive integer quantity, and the canonical L2 grounding receipt together with its validated Marketplace group; legacy or corrupt records fail closed. The homepage server seed uses the same gate and applies its limit only after valid rows are selected. It does not invent category, quantity, city, or deadline.

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.

Risky or manual-review RFQs can remain published. A print shop may submit a conditional price while that review is pending, but the quote is not yet awardable. The buyer page shows both Open and Under review, explains the lock, and disables quote selection until steward approval is complete. After approval the client reads the current RFQ projection again; Master Data/preflight and production handoff evidence remain separate fail-closed gates.

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

Card payment is not part of the live pilot. The platform collects the payment and pays the print shop after delivery, minus commission. Payment confirmation is handled through manual operations, bank transfer, open account, or agreed corporate payment terms. Payment approval is one production gate; when customer artwork is required, the file must also pass the agreed review gate and be approved. If the production handoff package or file readiness gate is missing, the order and committed delivery clock wait until that evidence is ready.

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