Aydınlatma metni yükleniyor…
An export manufacturer's website should help an overseas buyer assess product suitability and submit an enquiry the sales team can act on. Product pages, technical documents, language versions and request-for-quotation forms therefore need a shared information structure. Start with the information a buyer needs to make progress, not with a preferred visual style.
This guide is for B2B companies selling standard or made-to-order products. It concerns the path from product research to a useful sales conversation, rather than online checkout or automatic pricing. The matrix and examples below are planning tools developed for this article. They do not describe completed Kumsal Agency client work or measured commercial results.
Identify the decisions an overseas buyer needs to make
Saying that a business exports is not enough to help someone select a product. Buyers need to understand which product family fits their application, which specifications are standard and which options require further review. Begin the content exercise with the sales team: collect the questions that repeatedly appear in actual enquiries.
Separate those questions into information everyone needs before contacting you, details relevant only to certain products, and commercial matters that require discussion. Do not hide the first category behind a form. Equally, do not make every visitor answer every technical question. Put selection information on the product page and quotation inputs in the relevant enquiry step.
For an industrial filter, for example, connection dimensions belong in the catalogue. The page can also explain that suitability for particular operating conditions requires engineering review. Detailed delivery arrangements may be premature when the buyer has not yet selected a product.
Map products, documents and enquiry fields together
Complete the following worksheet for each product family you intend to publish. It makes gaps between page content and sales requirements visible before design begins. In your internal version, identify a person responsible for keeping each item current rather than assigning responsibility only to a department.
| Buyer question | On-page information | Supporting document | Enquiry input | Information owner |
|---|---|---|---|---|
| Will it suit my application? | Intended use and limitations | Technical data sheet | Application or operating conditions | Product / engineering |
| Which model should I select? | Model code and comparable specifications | Dimensional drawing | Selected model and required options | Product management |
| Can you supply the quantity? | Verified minimum-order information, where applicable | Packaging information, if needed | Quantity and unit | Sales / planning |
| Is custom production possible? | Customisations available for evaluation | Customer drawing through a secure channel | Special requirement and file-sharing preference | Engineering / sales |
| Who will handle my enquiry? | Supported communication languages and process | None required | Country, preferred language and email | Export sales |
A blank cell points to a specific job. If the document does not exist, asking a designer for a download button will not solve the problem. If specifications differ between languages, the information owner must resolve them. If the sales team never uses a field, reconsider whether buyers should be required to complete it.
Build a navigable catalogue, not just a collection of files
A downloadable catalogue can be helpful, but buyers should not have to search an entire PDF to identify a product. Create a route through product families, meaningful filters and product details. Name filters using criteria buyers understand, while retaining direct code search for experienced procurement staff.
A product detail page should explain what the model is, its intended use, its key specifications and the next step. Variants that differ only in dimensions do not automatically need separate pages. Make that decision according to whether the variant needs an independent explanation and assessment; do not multiply nearly empty templates.
If visitors can add products to a quotation list, carry the model code and selected variant into the form. Make it clear whether moving to another product preserves earlier selections. For multi-item requests, associate quantities and notes with each line item instead of leaving the sales team to interpret an undifferentiated message.
Manage documents by language, revision and access needs
We recommend recording the associated product, language, revision and internal owner for every technical document. When a dimension changes, check the translated page and attached files as well as the original content. If external recipients may still use an old document, plan how the change will be communicated.
A public data sheet and a customer's proprietary drawing need different access arrangements. Public documents can be linked from the product page; uploaded customer files should not be placed at publicly accessible media addresses. Include permitted file types, size limits, authorised access and security checks in the development scope. The OWASP file upload guidance recommends layered validation rather than relying on a single safeguard.
Allow buyers who do not wish to upload a file to send an initial enquiry and agree a secure sharing method later. Privacy explanations should describe the access and retention arrangements that will actually operate. A padlock graphic or checkbox is not a substitute for technical safeguards or an appropriate legal process.
Design the RFQ around the product's information requirements
An RFQ is a request for quotation, not a confirmed order or an approved price. Preserve that distinction in interface copy. If a salesperson must review the request, “Submit your quotation request” is more accurate than promising an immediate price.
A starting set might include the product or requirement, quantity and unit, company details, contact address and destination country. This is not a universal field-count rule. Custom production may require technical requirements; a service enquiry may need equipment details; project supply may require a target date. Ask whether each mandatory field is necessary for the first assessment.
Long forms can be divided into meaningful stages, but three steps are not inherently better than one. A short, clear form may work well. The W3C forms tutorial emphasises asking for necessary information, labelling controls and providing understandable guidance. Keep the product context intact as buyers move through the request.
After submission, consider showing a reference number and explaining what happens next. Publish a response-time commitment only if the sales operation can meet it. If submission fails, preserve entered information and explain how to correct the problem or use an alternative contact route.
Localise the complete task, not just the navigation
Product descriptions, units, document links, validation messages and acknowledgement emails all form part of the language experience. Where possible, switching languages should open the equivalent product. An English download button leading to an unexplained Turkish document, or a translated form returning an untranslated error, should be caught in acceptance testing.
Google's multilingual site guidance describes separate language URLs and appropriate language annotations. For the wider URL and language-switching decisions, see our multilingual website planning guide. The export-specific task here is to define the product and enquiry information that belongs inside that structure.
Define what happens when the enquiry reaches sales
Do not treat the request as merely an email notification. Define how the record will be associated with products, a language and an owner. If CRM integration is unnecessary for the first release, a controlled recording and assignment process can be enough. An email being sent should not be treated as evidence that a salesperson has reviewed the request.
An illustrative status sequence is received, assigned, awaiting information, quotation in preparation and closed. These are proposed working states, not a mandatory industry process. Simplify them to match your business. Reassigning a misrouted request and making unowned enquiries visible are just as important as automatic routing.
Assess more than form volume. Track the share of requests with understandable products and quantities, records needing additional information, and time to the first human response. Keep definitions consistent: an automated acknowledgement is not the same as a salesperson evaluating the requirement.
Prepare a small project pack before requesting development proposals
Select one product family and prepare an example product page, a current technical document and a sample enquiry record. Review their Turkish and English equivalents side by side. That pack communicates a much clearer scope than a request for a modern export website.
- Are product families, variants and content owners identified?
- Is approved product and document information available in both languages?
- Does every mandatory enquiry field have a business justification?
- Is the behaviour for failed uploads and connection interruptions defined?
- Can an enquiry be assigned to a salesperson and tracked?
- Will mobile testing cover product selection, document access and submission together?
To discuss an export-focused website with Kumsal Agency, share your product families, target languages, an example technical document and your current enquiry process. We can use these inputs to define the initial scope across catalogue structure, content management, quotation requests and any necessary integrations.