Separate the company website from the procurement platform
A buyer may arrive to understand the company, inspect a technical document, request a private-sector proposal or follow an official procurement process. The website should make those routes understandable. ChileCompra describes Mercado Público as the transactional platform for public purchasing and maintains a supplier register with its own information and conditions. A supplier's marketing website is not that register and cannot replace the formal process by adding a quotation form or a badge.
For a Santiago business serving both public and private buyers, describe capability on the site and link to the appropriate official profile or process when relevant. Keep the legal entity name and public identity consistent with verified records. Do not imply that a contact request counts as a submitted bid. Ask your procurement owner to approve the wording and external destination; the web team should implement and test the handoff rather than interpret eligibility rules or promise an award.
Organise capabilities around the buyer's technical question
A long list of products or services does not explain where the supplier fits. Group capabilities by the problems a buyer is trying to solve and show the relevant conditions: applications, compatibility, delivery scope, installation responsibility or ongoing support. Keep the difference between manufacturing, distribution, integration and maintenance explicit. A business that supplies a component should not present itself as the designer of the entire system unless that is true.
Ask the website studio to build a sample capability page using a real, approved technical brief. It should explain the problem in accessible language, show the necessary specification detail and offer a useful next step. A purchasing contact and an engineer may need different depths of information on the same page. Use clear headings and linked supporting documents so both can orient themselves. W3C's page-structure guidance is relevant here: visual emphasis alone should not be the only way readers identify sections or understand relationships.
Make technical documents current and traceable
Assign every public document a title, product or service relationship, revision date and owner. Explain whether it is a general brochure, a technical sheet or a project-specific deliverable. If a certificate is shown, verify what entity, activity and period it actually covers; do not use an old image to imply a current certification for every service. Remove confidential client details before publication and obtain permission for project photography.
The design brief should include how documents are replaced and what happens to an old link shared by a buyer. A stable document landing page can explain the current revision and link to the approved file. Provide the essential decision-making information in HTML where practical rather than forcing every visitor to download a large PDF. W3C's table guidance helps when specifications contain related rows and columns. Ask for readable units, clear headers and a mobile treatment that preserves the meaning instead of cropping half the comparison.
Route sales, support and partnership requests separately
A new project inquiry, a warranty question and a distributor proposal need different responses. Name those paths in the navigation or contact area if the business can actually staff them. For a sales inquiry, preserve the relevant capability or product and ask the few scope questions that determine who should respond. For support, explain the secure channel for necessary account or equipment details; do not encourage confidential operational information in a public comment or analytics event.
Agree which system receives each request and who checks it. A mailto link is not equivalent to a managed intake with a receipt, and a form success message should not appear before the server accepts the submission. Test a missing field, an unsupported attachment where attachments are offered, a retry and the confirmation. For English-speaking buyers, translate the instructions and response expectations rather than only the service introduction. Report received sales opportunities separately from support tickets so the site is not judged on an inflated lead count.
Use this supplier brief to price the real work
Imagine a Santiago technical supplier with four capability areas, twenty approved technical documents, three project examples and separate sales and support teams. The website needs a clear capability structure, document records, case studies and two distinct inquiry routes. An official supplier-profile link may be useful; recreating the public procurement platform is outside this brief. This is an illustrative scope, not a customer case or a claim about a particular supplier.
Ask bidders to identify who cleans up the twenty documents, checks claims, writes summaries and translates approved content. Those tasks can cost more effort than the page templates. Separate the initial build from hosting, maintenance and document updates. State the proposal currency, applicable tax treatment to be confirmed by the parties and the cost of work outside the agreed inventory. A quote for visual design only is not comparable with one that includes technical content preparation, migration and a verified inquiry system.
| Visitor task | Correct destination |
|---|---|
| Understand supplier capability | Approved service page and relevant evidence |
| Follow formal public procurement | Relevant official process or supplier profile |
| Request a private proposal | Received sales inquiry with product context |
| Resolve an existing service issue | The staffed support channel |
Test the evidence trail before the visual launch
Choose one capability and follow it from a search-style landing to a technical document and a received inquiry. Check that document titles, revision information and ownership claims agree. Then have an editor replace a file and confirm that the relevant page updates without breaking the route a buyer already saved. Repeat the core journey on mobile and with a keyboard. These are acceptance tests for the system you commissioned, not a guarantee about search rankings or procurement outcomes.
A local workshop may help the team understand equipment and staff routines; remote design can still be viable when subject-matter review and approvals are explicit. Verify any claimed Santiago office directly. Dardo does not assert one through this guide. After release, track which capability pages bring suitable requests and which generate repeated clarification questions. Use those questions to improve specifications and proof. Keep the review cycle connected to actual product changes so the polished website does not become an archive of outdated claims.
Plan a project with Dardo
Plan a project for Chile
Choose a review date and a time in Bogotá to see the corresponding local time. This is a planning aid, we’ll confirm availability when we reply.
America/Santiago — Representative time zone; some countries have more than one. Check the actual city and agree on a working window. Dates include seasonal clock changes through your browser’s time-zone data.
Budget currency to discuss: CLP. The project calculator lets you enter your own rate. It does not convert exchange rates.
Let’s make it happen.
Send your result and project details directly to Dardo. We’ll review them and reply to your email. Review the included details below before sending.
Prefer email? hello@dardo.studio
Sources & further reading
Sources behind this guide, with further detail from the original publishers.
- ChileCompra: supplier register
- ChileCompra: the role of Mercado Público
- W3C: accessible page structure
- W3C: accessible data tables