Pilot Program Guide

[!WARNING] This guide is only valid for Controlled Pilot users and printing offices participating by invitation. Availability is governed per capability; this guide is not a current deployment or public-launch attestation. Supplier-verification mutations and attaching files to an existing RFQ are disabled by default until their security, idempotency and audit evidence is complete. Re-listing an expired RFQ uses a package-owned command with a required idempotency key and exact revision precondition. The RFQ, immutable revision, audit record and outbox event commit together; stale or pre-migration RFQs fail closed. They are available only when explicitly enabled server-side for the controlled pilot. Opening a dispute is disabled by default by the shared server risk-mutation switch for both the API and the application action in Controlled P0. A different UI entry point does not bypass this boundary; support records the risk through the manual operations channel. Internal resolution, escalation, and timeline writes use the current dispute aggregate inside one server transaction; a stale screen cannot authorize a closed dispute. Escalation and timeline retries are exact and do not repeat the mutation or its notification; changed command data is rejected. The domain policy accepts escalation only for canonical active dispute states; terminal, unknown, and already-escalated states fail closed.

Welcome to the NowToPrint Printing Pilot Program! This program is an exclusive controlled phase conducted with a select group of buyers and print shops. Product availability depends on the current catalog, supported request flow, and eligible supplier capability; registration does not guarantee a quote or production capacity.

1. Minimum Information and Missing Technical Details

Give the product, explicit positive quantity, name and email before asking suppliers to quote. The manual form and partner API apply their own required-field/catalog rules; the email creation guard asks for missing product description or quantity before issuing a new RFQ link.

The shared completeness policy treats missing product, quantity, size, paper, city, deadline and related details as follow-up work and records manual-review signals; it does not itself block publication. A public record can remain readable without complete product/quantity evidence. Publication is not proof of pricing authority, file acceptance, or permission to start production. Tracking references are issued by the successful creation path, not by an unfinished form.

2. What Does "Your Request is Under Review" Mean?

When you submit your request, if there are missing or incorrect technical parameters, the system forwards it to our steward queue.

Who is a Steward? A NowToPrint technical operator who checks and corrects request parameters so print shops can provide accurate quotes.
Communication Step: Our steward team may contact you via email or phone to complete missing or incorrect details. Review can block production release, ERP handoff readiness, future Auto-Bid policy readiness, or final quote certainty, but it does not mean the RFQ waits for admin approval before first publication. Automatic external production remains separately gated. Auto-Bid has its own organization, authority, rollout, and exposure policy; review does not grant those permissions.

3. Receiving and Accepting Bids

If admin visibility is not paused and scope review allows it, the request is visible to eligible pilot print shops.

Print shops submit their best pricing quotes for your project.
You will be notified of quotes via email, and they will be listed on your tracking portal.
The comparison screen loads quote rows only after canonical buyer-organization or supervised platform-operations access is granted. A matching raw user id alone does not grant access.
You can choose the quote that suits you best by clicking "Select This Quote".
If the same actor retries the same acceptance request because the connection drops, the system returns the first committed order; it does not create or charge a second order. Reusing the request key for changed details is rejected. A different account using the same text key does not share the first account's command or order identity.
If you opened the request as a guest, the private tracking link is preserved when you sign in or create an account with the same email. A different email cannot claim the request in self-service. If the account is still pending onboarding, order creation waits until onboarding is complete and then returns you to the same private tracking link.

4. Payment Readiness and Wire Transfer Process

Once your order is created, the system directs you to the payment readiness screen.

[!IMPORTANT] Card payment is not part of the live pilot. Bank transfer and approved open-account terms are available. Other payment terms are used only under corporate agreements approved by the operations team; they are not offered to everyone. Production starts only after payment or the accepted commercial terms confirmed by platform finance have been approved. If order details cannot be verified or the payment amount is inconsistent, production waits until the operations team corrects the record.

5. Why Doesn't Production Start Immediately? (Production Hold)

Payment-readiness is a policy decision and audit, not an automatic payment update or production-hold release. Finance must verify the accepted terms; required files, proof, production information, and operations approval remain separate. Printing presses do not start automatically.

Why is there a Hold? During the Controlled Pilot, file quality, plate compatibility, and material stock availability are verified one last time manually by our steward team.
Manual Permission: Following these checks, the steward approves the order, and the production instruction is manually sent to the print shop. This safeguard reduces error and delay risk. Automatic external production integrations will remain locked (on hold) throughout the pilot.

How pilot data cutover is protected

Before a launch cutover, Marketplace operations use a registry-based dry run and verify a current backup. Transaction data cannot be reset without separate data-owner and product-owner approval, and shared print-shop, notification and webhook records are outside Marketplace bulk-delete authority. A cutover is not accepted until the full registry is recounted and revision, receipt and financial orphan checks report zero. These controls do not mean a public launch is approved; the protected backup and restore drill remain launch evidence.