Back to Websites

Websites

Websites for industrial companies: helping the customer evaluate a vendor

Present technical capabilities in a way that's useful to whoever is selecting production partners.

SqualiOnline editorial team · 2026-09-07

Someone selecting a production vendor isn't browsing: they're narrowing down a list. They open six or eight websites, rule out most of them within minutes, and keep the two or three worth spending a phone call on. The website's first job is to keep you from being ruled out, and its second is to bring in a technical request that's already complete. These are two different tasks, and they're designed differently.

The difference from a presentation-style website is that here the reader already has a defined problem: a part, a material, a tolerance, a quantity, a deadline. They're trying to figure out whether it fits within what you know how to do. Anything that doesn't help them answer yes or no is dead weight, and dead weight is paid for with abandonment.

Whoever is evaluating you is mostly looking for reasons to rule you out

In a vendor selection, there are almost always two people involved, with different questions.

  • The technical department checks feasibility: materials handled, maximum dimensions, achievable tolerances, treatments available, minimum and maximum quantities. If they don't find this data, they assume the answer is no.
  • The procurement side checks reliability: how long you've been in business, which industries you work with, which certifications you hold and whether they're still valid, how you handle nonconformities and delays.
  • Both are working against the clock. Neither will call you to ask for information the website could have given: they'll move on to the next vendor.

This leads to an uncomfortable rule: stating a limit loses you some requests and brings in better ones. A list of capabilities with no limits is indistinguishable from anyone else's, and it produces requests you'll later have to turn down.

The four coordinates: process, material, application, limit

Industrial companies almost always organize their website by process, because that's how they talk about it internally. Whoever is searching, though, starts from any one of the four coordinates, and needs to be guided from one to the others.

  • Process: what you know how to do, with which technology and to what finish quality.
  • Material: what you do it on, and what you don't. This is the most-searched coordinate and the most often left out.
  • Application or industry: what uses and what fields you've already done it for. This helps someone who can't name the process but can describe their own problem.
  • Limit: dimensions, thicknesses, tolerances, quantities, typical setup times. A limit is commercial information, not a weakness.

The pages need to cross-link: from the process you reach the materials it's available on, from the material to the possible processes, from the application to both.

Stated limits carry more weight than stated capabilities

A list of machinery tells a knowledgeable reader a lot, but only when it comes with the numbers that bound it. Without them, it stays a snapshot of the workshop: it confirms you have a department, not that you can make their part.

Documents and certifications: findable and still valid

Certifications expire, spec sheets change revision, and industrial websites are full of attachments that no longer match what's produced today. The problem isn't publishing them: it's managing them.

  • Every published document shows a visible revision and date, and a person responsible for keeping it current.
  • Certifications state the issuing body, scope, and validity period. A logo with no scope doesn't say which process or which plant it refers to, and whoever is evaluating you knows that.
  • Confidential documents, such as specifications and price lists, don't sit behind a contact form disguised as a download: they belong in a separate area with clearly stated access.
  • Document pages say who they're useful for, not just that they exist.

A sample page, and the questions sales keeps hearing

The fastest way to find out what's missing is to listen to whoever answers the phone: the questions that keep coming up are the page's table of contents. Below is an illustrative example for a single process. The fields serve as a template; the values should come from your own.

Page fieldWhat it containsWho verifies it
What it is and what it's forTwo lines in the customer's language, not the machine'sSales
Materials processedList of materials handled and those excludedTechnical department
Dimensional limits and tolerancesReference values and the conditions under which they applyProduction
QuantitiesMinimum batch, typical batches, handling of single pieces or prototypesSales
Treatments and finishesWhat's done in-house and what's outsourcedTechnical department
Inspection and testingAvailable equipment and documentation that can be issuedQuality
Completed examplesTwo or three cases with industry, problem, and constraint addressedSales
Attached documentsProcess spec sheet and relevant certifications, with revision and dateQuality

Three well-told cases are worth more than twenty photos: the customer's industry, the constraint to meet, how it was solved. If a job is covered by confidentiality, you can describe the problem without naming the client, and it still counts as proof.

The technical request: ask for context, not personal details

The form on an industrial website isn't there to collect contacts: it's there to bring in a request that can already be worked on. That changes the questions.

  1. What's needed: description, drawing, or sample. If you accept attachments, state which formats and what maximum size.
  2. How many pieces and how often: a prototype and an ongoing supply aren't assessed the same way.
  3. By when, and whether the date is tied to something further upstream.
  4. Which requirements are mandatory: material, treatment, certification, testing, documentation to be issued.
  5. Who's writing in, and who the technical content should be discussed with, which is often a different person.

VAT number, address, and legal business name are needed to make an offer, not to receive the request: asking for them upfront lengthens the form and adds nothing to the assessment. Instead, say what happens after submission: who looks at the request, what you reply if the job isn't feasible, and that sometimes a clarifying question comes before any figure.

What this guide doesn't cover

This guide covers the case of getting evaluated as a vendor and receiving technical requests. An online catalog with prices, configuration, quoting, or direct purchase is a different build, with different rules. How to tell the story of completed projects, with what context and what authorization, also deserves a discussion of its own.

Frequently asked questions

How much technical information is safe to publish without helping competitors?

Competitors already know what machines you have, because they buy them from the same suppliers; potential customers don't. What needs protecting is customer drawings and process parameters, not the materials you handle and your dimensional limits, which are exactly the information they use to evaluate you.

Do I need a private area for technical documents?

Only if you have documents that can't be public, such as specifications or confidential terms. Putting even generic spec sheets behind a registration adds friction at the worst possible moment, when someone is still evaluating you and has no reason yet to hand over their details.

Is it better to organize the website by process or by industry?

It's best to keep the core structure organized by process, because that's what you can describe precisely. Industry pages work as entry points for people who don't know the name of the process, and they link back to the technical pages without duplicating their content.

Let's design the path for technical requests.

If you’d like to talk it through, the service that handles this is Websites.

Related guides