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, how many items exist only as PDFs, the volume of technical documentation and who controls it, and the state of the content in each language.
Data condition is the largest single variable in an industrial website timeline. Understating it produces responses priced on an assumption that will not survive contact with the export, and the difference reappears as a change request.
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.
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 and weightings in the document, score independently before discussion, and compare assumptions rather than headline totals. Check whether product data preparation, content migration, translation management, integration work, redirect mapping and support sit inside or outside each figure, since a lower price usually reflects a narrower assumed scope.
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.
Talk through the commercial, content and technical context before you invite proposals.