What enterprise buyers check on your website

Before a tender invitation or a large order, several different people open your website, and none of them reads it as marketing material. Procurement looks for confirmation that the company exists and fits a category. The technical team looks for the edges of your competence. Legal and security look for documents, policies and a channel to ask through.

A website does not replace a bid pack. Its job is to raise no doubts before the first contact and to hand over verifiable proof quickly. Vague wording, inconsistent names and a form with no context end the review before anyone asks you anything.

Who actually looks at the site

Draw a map of the roles. For each one define the question, the public proof, the private proof and the next action. One visitor may hold several roles, but the pages have to let them find what they need without reading the whole site.

Procurement

This role is not judging the quality of your work. It answers a different question: can a formal process be run with you at all, and which category do you belong in? If the answer is not quick to find, the route often stops there.

• Supplier identity. The exact name, registration details, where you operate and whether you can sign a contract.
• Category fit. A clear description of services rather than a slogan. A well-written line with no list of competences gives nothing to match against a requirement.
• A way to start the process. A separate contact for tenders, or a choice in the form, saves being forwarded between departments.
• A list of available material. Do not publish sensitive documents openly for convenience: show they exist and describe how to obtain them.

The technical team

A technical reviewer reads skeptically and looks for reasons to rule you out. They have seen enough pages listing twenty technologies and saying nothing about what the team did with them. A precise boundary serves you better than a broad list.

• The edges of competence. A general technology list with no context proves nothing.
• Evidence of similar work. A case study or service page has to show which problem the team solved and what they were responsible for.
• How integration happens. What you work with routinely and what needs investigation first.
• An honest limit. Promising to support any system lowers trust, because a technical buyer understands the risk behind universal promises.

Legal and security

These people arrive last and can stop the process on their own. What they need is not volume of information but its currency and a clear route to the rest. A policy dated three years ago raises questions. Update its content and date, but do not remove it.

• Public policies. Data handling, subcontracting, ownership of the result.
• The current version of a document. The page leads to the live file with a date on it.
• A channel for due diligence. A controlled route for requesting further material.
• No unnecessary detail. A full description of your internal security setup on a public page creates a new vulnerability.

Basic proof of the company

The people checking your site compare its data against documents and public registers. Different spellings of the name and outdated addresses create manual work, and every one of those steps counts against you.

• The legal name where it belongs. The brand is explained separately rather than replacing it.
• Contacts with a stated response time. Channels, working hours and a way to escalate a formal request.
• Not an employee’s personal inbox. And not only a social profile: both vanish with the person.
• A clear scope for each service. Client type and boundaries. A contractor, an integrator and a product vendor fall into different procurement categories.
• Dates and versions on documents. The page shows the current file, the update date and the owner. An archive can exist, but navigation must not present it as current.

If the pages themselves are still being decided, see our article on the structure of a corporate website.

Competence and case studies

This is where most sites lose the review. The work behind them is usually substantial, but the description makes it impossible to tell what the team actually did. The buyer sees a recognizable logo and no way at all to verify the contribution.

A case study answers four questions: what the context was, what your role was, what you proposed and what result was verified. A logo with no description of the contribution proves nothing.

• Role, not participation. “Delivered together with a partner” without splitting the responsibilities reads as claiming someone else’s work.
• Industry at the permitted level. If the name is under NDA, the class of process and its complexity can still be shown.
• The acceptance criterion. What counted as success and who confirmed it.
• Grouped by task rather than technology. Buyers look for a migration, an integration, multiple locales or support, not a list of programming languages.

Do not invent detail to fill gaps. A large buyer will clarify the team composition at the next step anyway, and a discrepancy there costs more than a modest case study would have.

Process, responsibility and support

A buyer of a large project judges not only your ability to produce a result but how manageable the work is. There is no need to publish an internal procedure; there is a need to show that the process has owners and outputs.

• The main stages and approval points. What happens between kickoff and handover, and when the client decides.
• Roles rather than names. Management, analysis, design, development, testing, support. People change, functions stay.
• A mechanism for scope change. The word “flexible” with no decision log and no criteria reads as the absence of a plan.
• The limits of support after launch. The request channel, severity levels, knowledge transfer and ownership of credentials.

Do not publish promises a contract will not back. It is enough to describe the model and say that the specific figures are agreed on for each system according to its risk.

Documents without leaking data

The second most common failure, after case studies, looks like the exact opposite: a company publishes everything openly and calls it transparency. In practice that creates two problems at once. The reviewer cannot tell which version is current, and a competitor gets your pack without asking for it.

Split the material into three groups: public, available after a request is vetted, and available only inside an active process.

• A catalog rather than an archive. Name, description, date and how to request it. The recipient sees the document exists, and your team checks the context.
• Links with an expiry. For sensitive material, with a log of who received what.
• A check before sending. Hidden sheets, comments and earlier versions inside the file. Deleting a line from a finished document does not clear its history.
• An approved copy rather than the working file. An exported version with no internal edits or approval traces left in it.
• An owner and a review date. An expired certificate should not go on living in presentations and emails.

Site security during a tender

Tender activity draws more attention to your site, and not only from the buyer.

• Access and updates. Check administrator accounts, updates and backups before the campaign starts.
• Form protection. It becomes the main channel and the main target at the same time.
• Files from your own domain. A shared cloud folder with loose permissions reads as carelessness.
• No sign-up just to get a document. Every new account with a weak password is another way in.
• Third-party scripts do not block the essentials. Contacts and documents stay reachable even if a widget fails to load.

The tender inquiry form

The form has to tell a tender request apart from a general inquiry and route it to the responsible team rather than a shared inbox.

• A minimum at the first step. Company, contact, category, approximate stage and a safe description.
• No file required immediately. Asking for the full pack before the channel is confirmed is premature.
• A reference number. Shown after the server has saved the record, not after an email is sent.
• The inquiry lives in the database and the email only announces it. The inquiry has its own identifier and a delivery log.
• A second click does not create a duplicate. And does not make anyone retype the form.
• A fallback channel. If the destination system is down, the form stores the data or names an alternative honestly without losing what was typed.

Do not promise a non-disclosure agreement automatically through a checkbox. The site records the request; the document and the channel are agreed by the responsible team before any sensitive exchange.

The review route

A site can contain every piece of proof required and still fail the review if nobody can reach it. Someone on the buyer’s side does not know your internal structure and will not study the menu: they open two or three pages and decide.

Build a few short routes and walk each of them end to end as an outsider would.

• Procurement. Service, company, proof, documents, form.
• The technical role. Case study, process, competence, contact.
• Security. Policy, due diligence channel, responsible person.

Navigation has to use familiar words. A procurement team will not decode your internal marketing term and will go and find a competitor who wrote it plainly.

• The error page helps. An old link from a tender database lives for years, and it should lead to the current document or to the request channel.
• The mobile route as well. People open a link from an email during a meeting: a table, a document and a form have to be readable without zooming.
• Large files with a short description. So nobody downloads a document only to find it is the wrong one.

Managing your claims

Keep a register of public statements: the text, the page, the source, the owner, the date checked and when it is next due for review. That is the single thing that saves you from an outdated figure sitting somewhere prominent.

• Project counts and geography. These go stale first.
• Certificates and partner statuses. They expire on a date a calendar remembers and a person does not.
• Proof and interpretation kept apart. A certificate confirms a status, not the ability to deliver any project. A case study confirms experience in a context, not universal expertise.
• A primary and a backup owner. If a document expires while one person is away, the site should not be left with the old version.
• A single source for each file. Do not upload the same document to several places under different names: sooner or later they diverge.

Do not write “we will provide all documents” if a third party prepares some of them or an approval is needed. Better to list the ready categories and name a contact who will confirm the rest.

Preparing the team

It hurts most when the last link in the chain breaks. The inquiry arrived, the site did its job, and the reply went out three days later from someone with no context who asked for information the form already contained.

The site can route the request correctly, but from there a person has to see it for what it is.

• A responsible person and a backup. By name, not “one of the managers”.
• A time to first acknowledgement. The reply need not contain every document, but it has to confirm receipt and name the next step.
• An internal brief. Which pages the visitor has already seen, what can be sent without approval and what needs a secure channel.
• A review after each cycle. Questions that keep recurring become public pages with an owner and a source, provided the answer is safe to publish.

The checklist before a campaign

• Name and registration details match the registers. In every spelling across the site.
• Service descriptions match the procurement category. Without mixing different delivery models into one paragraph.
• Case studies carry a role and an acceptance criterion. Not just a logo.
• Documents are current. With a date, an owner and a working link.
• The form recognizes a tender request. And reaches the responsible team.
• The routes have been walked by three roles. Each one without using site search.
• A test inquiry was found by its reference. In the working system, not only in the mailbox.

Conclusions

Before a large order, a website becomes the first stage of vetting. People read it looking for grounds to continue or a reason not to, and the second is considerably easier to find.

The expensive mistakes are not in the design. They are inconsistent spellings of the company name, a case study with no role in it, a document with no date, a form that cannot tell a tender request from a price inquiry, and a claim that belongs to nobody and therefore went stale unnoticed.

If you are preparing to bid, send us your site address and name the category you intend to compete in. We will look at the site and tell you what on it gets in the way of passing a review. Some of these issues are obvious straight away, and copy changes are enough to fix them. If the requirements call for a different site structure, we build that as part of developing corporate websites.

A corporate website with a custom design and a structure built around your services costs from $2,000 to $3,000. A tender form that stores requests in its own database and a document library with expiring links and a download log are quoted separately as custom modules, from $500 to $2,000.