Brief an industrial web agency on the commercial problem, the audiences and the operational constraints, rather than on a list of pages. A brief that explains why the project exists now lets an agency recommend the right work instead of pricing the work you assumed.
Four things carry most of the value: what needs to change and for whom, where product data and technical content currently live and in what condition, which systems have to connect, and who decides. Uncertainty is fine and worth stating; a defined discovery phase is a more useful response to it than invented implementation detail.
State the commercial and operational reason the project exists now. It may be that buyers cannot find products by application, that international content has diverged, that sales spends hours sending datasheets by email, that the platform can no longer be updated safely, or that a merger has left two ranges presented as two companies.
Name the audiences and the decisions each has to make. That framing lets an agency propose outcomes rather than treat a redesign as a visual exercise.
Say how many products there are, how they are grouped, where the attributes are mastered, whether naming is consistent across systems, and how much of the range currently exists only as PDFs. Say how many technical documents there are and who controls them.
Be candid where the data is poor. An agency that knows the condition in advance can scope the preparation properly; one that discovers it in month three will raise a change request, and the project will absorb the delay either way.
Identify the CMS, PIM, ERP, CRM, DAM and authentication landscape, and which of them the website has to read from or write to. Note whether an integration is already available or would need building, and who owns the system on the client side.
Include the constraints that are real: an IT standard that mandates a platform, a procurement process with fixed stages, a trade fair the launch has to precede, or a budget approval window. Constraints stated early shape a workable plan.
Priority markets, the languages you sell in, and whether you sell direct or through distributors change the shape of the site substantially. A distributor model adds a second audience with its own needs, and often a portal or a locator alongside the public site.
Say which markets are committed and which are aspirational. Building for eight languages when three are funded produces a structure the team cannot fill.
Identify one accountable sponsor with authority to resolve trade-offs, the technical reviewer who will sign off specifications and claims, and anyone in legal, quality or regional sales whose approval is required. Say how long each review realistically takes.
Availability of the technical reviewer is the single most common schedule risk on industrial projects, and it is worth stating in the brief rather than discovering it during delivery.
Ask agencies to set out their approach, the team who will deliver, comparable work, their assumptions, the risks they see and how discovery and implementation are separated commercially. Give a realistic investment range so responses are calibrated rather than speculative.
A brief does not need every answer. It needs enough clarity to start the right conversation and a stated route for resolving what is still open, which is what project scoping is for.
Explain the commercial problem and who it affects, describe the product data and technical content candidly, including its condition, list the systems that must connect and the constraints that are fixed, and name the sponsor and technical reviewer. Then state what a good response contains. Page counts and feature lists are the least useful part of a brief.
Document what you know about needs, users, systems and constraints, and mark clearly what is still open. Where scope remains uncertain, commissioning a defined discovery phase is more useful than writing implementation detail that will be revised. False precision in a specification tends to reappear as change requests during delivery.
The current website and any staging or intranet versions, analytics and search console access if possible, the product architecture and where attributes are mastered, priority markets and languages, the systems landscape, the stakeholder list, the commercial objective and any fixed constraints on platform, timeline or procurement. Access to real data shortens the whole process.
One accountable sponsor should lead it, drawing input from marketing, product or engineering, sales and IT. The sponsor needs authority to resolve trade-offs once delivery starts, because a brief owned by a committee produces contradictory requirements that surface late. Name the technical reviewer in the same document.
A realistic range or an investment framework helps agencies recommend a proportionate route rather than guessing at your appetite. Without one, responses tend to cluster around assumptions rather than around your needs. Where it is too early for a delivery budget, define and fund the discovery phase separately and decide the rest afterwards.
As much as you have. Product count, how ranges are grouped, where attributes are mastered, whether naming is consistent across systems, how many items exist only as PDFs, and who owns each field. Data condition is the largest single variable in an industrial website timeline, and understating it moves the problem rather than removing it.
Tell us the commercial, content and technical context behind the website you need to build.