An industrial website RFP should cover eight things: the commercial problem, the audiences and their tasks, the product and content position, the systems that must connect, markets and languages, governance and ownership, the commercial framework, and how responses will be evaluated.
The balance to hold is between enough context for a supplier to solve the right problem and enough freedom for them to recommend how. Fixing the solution in the document too early narrows the responses to whoever is willing to agree with it, which is the opposite of what a competitive process is for.
State why the project exists now: a catalogue buyers cannot search by application, weak findability in export markets, a fragmented portfolio after an acquisition, a platform that can no longer be updated safely, or a sales team spending its time sending datasheets by email.
Express the intended outcome commercially: better-qualified enquiries, easier product discovery for specifying engineers, distributor self-service, reduced manual sales support. A visual preference is a weak substitute for that.
An industrial site typically serves a specifying engineer needing tolerances and datasheets, a procurement lead needing certifications, lead times and supplier credentials, a distributor needing material for its own customers, a maintenance engineer looking for a replacement part, and often a technical recruit.
Naming those readers and their tasks gives suppliers something concrete to design against, and it exposes early where the current site serves one of them well and the rest not at all.
Give the product count, how ranges are grouped, where attributes are mastered, whether naming is consistent across systems, the documents available and who controls them. Describe the state of each language version and supply a representative sample.
Data condition can materially affect scope and schedule. State what is known, what needs assessment and who will prepare it. An export size alone does not establish the effort required to normalise relationships or resolve missing ownership.
Identify the CMS, PIM, ERP, CRM, DAM and authentication landscape and which connections are required, whether each integration exists already, and who owns it internally. State priority markets, committed languages, and whether you sell direct or through distributors.
Include fixed constraints openly: an IT standard, a hosting requirement, a procurement timetable, a trade fair the launch has to precede. Constraints stated in the document produce a workable plan; constraints revealed later produce a renegotiation.
Say who decides, who provides technical or legal sign-off on product claims and how long that takes, and who will maintain the site afterwards. Ask suppliers to state what happens to code ownership, hosting accounts, domain control and administrator access at handover.
Ask what the support arrangement covers and what a second-phase change would cost. That is where the real cost of the relationship sits, and it is routinely left out of the response.
Request a proposed approach, comparable work, the named delivery team, stated assumptions, identified risks, a timeline and a transparent commercial structure with discovery separated from implementation where uncertainty remains.
Publish the evaluation criteria and their weightings in the document. Assess strategic understanding, platform judgement, product data and integration capability, working style and plan credibility alongside cost. Where scope is still open, funding project scoping first is more productive than forcing precision.
Ask for the source of each record, product identifiers, revision/applicability rules, publishing owners and public or restricted audiences. Include one historical file and one access exception in the sample. The technical documentation portal guide for 2027 provides a decision matrix for the brief.
Request separate assumptions for search, file delivery, source integration, URL transition and operations. Define accepted evidence for permitted and denied downloads and a document update. A product catalogue screenshot does not demonstrate a governed documentation workflow.
The documentation portal service and legacy PDF URL guidance help distinguish the implementation scope from the migration decisions.
The commercial problem and why now, the audiences and their tasks, the product data and content position stated candidly, the systems that must connect, priority markets and languages, governance and post-launch ownership, the commercial framework, and the evaluation criteria with their weightings. Detail the needs and leave the solution open.
A realistic range or commercial guardrails helps suppliers frame a proportionate response, and without one the submissions cluster around guesses rather than around your requirements. Where the scope is not mature enough for a fixed implementation budget, commission and fund a defined discovery phase instead of forcing precision the information does not support.
Detailed about needs, users, data, integrations and constraints; open about the solution. A requirement can be entirely clear without naming the component, CMS or interface pattern in advance. Fixing the solution in the document narrows responses to suppliers willing to agree with it, and removes the recommendation you were buying.
The teams owning marketing, product or engineering information, IT and the commercial relationship with customers or distributors, with one accountable sponsor to resolve trade-offs and keep the process moving. Include whoever will maintain the site afterwards, since they hold the practical view of what is sustainable once the project ends.
Publish criteria, compare the same sample and check assumptions as well as price. Identify who provides data and content, which integration and migration tasks are included, how acceptance is demonstrated and what support covers. A lower total alone does not establish a narrower scope or better value.
Missing context about product data, unresolved internal decisions, no named sponsor, and a demand for a fixed price before anyone has assessed the content, integrations or governance model. Suppliers will respond regardless, and their assumptions become the hidden scope, which surfaces as change requests once delivery is underway.
State document ownership, source systems, product/revision relationships, access rules and historic URL decisions. Include a representative sample and require observable checks for discovery, correct delivery, source updates and publication. Treat optional previews or account features as separate scope items.
Talk through the commercial, content and technical context before you invite proposals.