What to put in a web-to-print RFP, section by section

What should a web-to-print RFP contain?

A request for proposal for a web-to-print platform works when it describes the business's rules, not a feature wish list. Suppliers answer feature lists with "yes" to every line, and the differences only appear after a contract is signed. Rules are harder to agree with casually: a pricing rule either produces the known price or it does not, and a file either passes the printer's specification or it does not.

The checklist below, dated 29 September 2026, has nine sections. It is written so a buyer can use it against any supplier, including this one. Each section names what to write, what to attach and what a weak answer from a supplier sounds like.

How should products and options be described?

Describe products as rules, not as a flat list. For each product family, state the options, their allowed values and the dependencies between them: a stock that is not available in a size, a finish that requires a minimum quantity, a fold that changes the page count. The rules between options are where configurators fail, and a supplier cannot estimate them from a product name.

Name your three hardest products explicitly. A supplier's answer about a business card says little; its answer about a folded, die-cut product with variable quantity breaks and a finishing dependency says a lot. Ask each supplier to show how its approach would model those three products.

How should pricing rules be written into an RFP?

Write the pricing rules as a function, not a price list: which inputs change the price, how quantity breaks work, how stock, size, colours and finishing combine, and which customer accounts receive different rules. Name the person who owns the rules today. If nobody owns them, that is the first finding, and it belongs in the RFP.

Attach a set of known-good quotes: real configurations with the price your business would charge today. They become the acceptance test for pricing. Leave price values out of any public document; the rules and the test quotes can be shared with suppliers under a confidentiality agreement. The print pricing engine page describes how such a rule set is formalised and accepted.

A weak supplier answer here sounds like "our pricing module is very flexible" with no statement of how your test quotes will be reproduced.

What should the RFP say about artwork and preflight?

State what production accepts: page geometry with trim and bleed, colour space and printing condition, font handling, minimum resolution at final size, ink limits, and the PDF target, such as PDF/X-1a or PDF/X-4. Where a technical standard is named, it describes the output specification an engagement produces to, not a credential Web2Print Solutions holds. The seven checks behind a print-ready file are explained in print-ready PDF requirements.

Say which failures block an order and which only warn, and who reviews a warning. Attach one accepted and one rejected file for each product family. Ask each supplier how its preflight would treat the rejected file.

Which integrations must the RFP list?

List every system an order touches, in order: storefront, payment, customer accounts, the production MIS or ERP, file storage, shipping and accounting. For each, state whether the connection is required at launch, its direction, and the interface the system offers: an API, a file drop or hot folder, a JDF or XJDF job ticket, or a procurement protocol such as cXML PunchOut for corporate buyers.

Be exact about the production system. An integration with an MIS is only as good as the interface the MIS vendor sanctions, and a supplier that promises to integrate without seeing the interface is guessing. The web-to-print MIS integration page lists what such an integration has to handle, including duplicate submission, reconciliation and status mapping.

How do roles and approvals change the requirements?

Roles and approvals change the data model, so they belong in the RFP from the start. List every account type: retail customer, business account, account buyer, approver, brand administrator, customer service and production operator. For each, state what it may order, edit, approve and see. Describe approval steps with their triggers, such as an order above a quantity threshold or a template edit outside brand rules.

Corporate and franchise buyers often need brand-locked templates, cost-centre fields and approval chains. A platform that adds these after launch usually has to restructure accounts and orders, which is slower than designing them in.

Turn this into a scoped brief

If this checklist has surfaced sections your team cannot fill in yet, send a project brief with the sections you have and a note of the ones you do not. A discovery engagement can write the missing sections with you.

What output files must the platform produce?

Specify the production output exactly: file format and PDF target, one file for each item or one for each order, naming convention, job ticket or metadata, delivery route to production, and what happens when output generation fails. If production imposes files itself, say so; if the platform must impose or gang jobs, specify sheet sizes and marks. Attach the printer's written file specification. An RFP that says only "print-ready PDF" will receive proposals that each mean something different by it.

How do you write acceptance tests a supplier cannot argue with?

Write acceptance tests as orders with expected results. Each test names a configuration, the artwork supplied, the expected price, the expected preflight outcome, the expected output file and the expected state in the production system. Include failure cases: a rejected file, a disallowed option combination, a duplicate submission, an approval refused.

State who runs the tests, on which environment, and who signs acceptance. Tests written before the proposal protect both sides: the buyer knows what is being bought, and the supplier knows what done means. How we work describes the acceptance route used on this site's engagements.

What should the RFP say about ownership and licensing?

Ask each supplier to state, in writing, what the buyer will own at the end, what is licensed and on which terms, and what can be exported if the relationship ends: product data, customer accounts, orders, artwork and pricing rules. Ask how any fee scales as volume grows, and what happens to the platform if a subscription or licence stops. This site publishes no prices, rates, day rates or payment terms, and the RFP does not need them to answer this question.

Expect a mixed answer from most suppliers, including this one. Client-specific deliverables, access and handover are defined in the engagement contract. Pre-existing software, products, APIs and third-party components remain subject to their respective ownership and licence terms. The RFP should make each supplier draw that line explicitly rather than leave it to the contract stage. The choice between approaches is compared in web-to-print build options.

What support terms belong in the RFP?

Describe who will run the platform after launch and what support you need: monitoring, security patching, platform upgrades, incident response, backups with tested restores, and a route for small changes. State your hours of operation and time zones rather than asking for round-the-clock cover by default. Ask each supplier what it will and will not support, and how an incident is reported, triaged and closed. If accessibility matters to your buyers, name the target, for example WCAG 2.2 level AA, and include it in acceptance.

How should the responses be scored?

Score each response against the nine sections, weighted by what matters to the business. Give more weight to answers that engage with the attached test quotes, files and interfaces than to general capability statements. A response that asks good questions about your hardest products is usually worth more than one that answers every line with "supported".

We can run a paid discovery engagement that produces an architecture, an explicit pricing-rule specification, an integration inventory and a phased plan you could hand to another supplier. The output of a discovery engagement is written so that a supplier other than us can execute it. Web-to-print architecture and discovery describes that engagement. Terms used on this page are defined in the web-to-print glossary.

Limitations

This checklist is general. A regulated buyer, a public-sector tender or a multi-country rollout will need sections it does not cover, such as data residency, procurement law and localisation. It does not rank suppliers or products. Web2Print Solutions claims no certification, accreditation, audit result or named compliance standard as a held credential. Web2Print Solutions is the web-to-print engineering service of Netbase JSC. Delivery records cited on this site belong to Netbase JSC; where no delivered example of a capability is published, the page says so rather than implying a record. No RFP answered by this property is published here.

Sources

• cXML.org, cXML protocol and PunchOut. https://cxml.org/, accessed 2026-09-29.
• CIP4, JDF and XJDF print automation. https://www.cip4.org/print-automation/jdf, accessed 2026-09-29.
• Wikipedia, PDF/X. https://en.wikipedia.org/wiki/PDF/X, accessed 2026-09-29.
• W3C Web Accessibility Initiative, WCAG standards and guidelines. https://www.w3.org/WAI/standards-guidelines/wcag/, accessed 2026-09-29.