Aydınlatma metni yükleniyor…
B2B companies serving Levent and Maslak may need one corporate website to support procurement, technical specialists, executives, candidates and international visitors. These audiences do not share the same questions or decision criteria. Forcing everyone through an About–Services–Contact structure hides important evidence and weakens qualified enquiry journeys.
This guide does not use the location as evidence of an office or local results. It scopes a multi-stakeholder B2B website as a system of information paths, evidence ownership, enquiry journeys and measurement rather than a visual refresh.
Segment stakeholders by decision task, not title
Procurement evaluates scope, supplier fit, delivery and commercial process. Technical teams need architecture, integration, security boundaries and implementation material. Executives look for business risk, governance and credible evidence. Candidates need real role and team information. International visitors need a properly localised company, solution and contact route.
Write the first three questions, required evidence, primary action and content owner for each stakeholder before designing navigation. Otherwise, the organisation chart becomes the visitor journey.
A five-stakeholder B2B information and evidence map
Kumsal Ajans developed this map to connect each decision question to evidence and a measurable next action. Where one asset supports several audiences, reuse it in the correct context rather than duplicating generic copy.
| Stakeholder | Primary question | Required evidence | Next action |
|---|---|---|---|
| Procurement | Does this supplier fit our scope? | Deliverables, process, ownership and terms | Structured proposal request |
| Technical | Will the solution work with our environment? | Architecture, integration, security and documentation | Technical consultation or document |
| Executive | How are risk and value governed? | Governance, method and verifiable cases | Decision meeting |
| Candidate | Does the role and working model fit? | Role scope, team and genuine working information | Qualified application |
| International | Can I understand the company and offer in my language? | Localised solution, company and contact information | Enquiry to the right market team |
Do not surrender information architecture to the org chart
Departments rarely match the visitor's mental model. Test navigation against questions such as which solution, which industry, what evidence, how delivery works and who to contact. Solution, sector and capability pages should not repeat the same copy; each needs a distinct decision task and next action.
Maintain the stakeholder, primary question, owner, evidence source, review cycle and next step for every page. A page without an accountable content owner is not publication-ready.
Move evidence beyond the slogan
Terms such as “leading”, “innovative” and “end-to-end” do not help procurement verify fit. Explain the problem, method, delivery boundary, team responsibility and verifiable examples. Case studies should separate context, scope, role, limitations and authorised outcome data. Where client or metric permission is unavailable, publish an honest anonymised process example rather than inventing a result.
Manage legal name, logo, address and contact details from a controlled source. Google's Organization documentation recommends applicable and accurate organisation details such as name, logo, address and contact information (Google Organization documentation). Structured data should not conflict with visible copy.
Design the enquiry journey for qualification
A generic contact form may not support procurement. Select fields that help the first assessment, such as solution area, project stage, target timing, integrations and preferred contact method. Document why each field is needed, where it is transferred and who can access it.
After submission, explain response expectations, useful preparation material and an alternative channel. Include errors, file uploads, repeated submissions, spam prevention and failed CRM transfers in acceptance tests.
Give technical stakeholders more than marketing copy
Explain integration categories, data flow, security approach, operating responsibility, versioning and support at a useful level without revealing confidential implementation detail. Assign an owner and review date to technical documents and define how obsolete versions behave.
Do not build multilingual pages as duplicated copy
The English version should localise terminology, evidence needs and contact routes rather than mirror Turkish sentence by sentence. Google recommends separate URLs for language versions and explicit reciprocal alternatives (Google localized versions documentation). The language control should lead to the corresponding page, not restart at the homepage.
Treat accessibility and performance as corporate trust
Long technical pages, tables, forms and documents need to work with keyboards and assistive technologies. WCAG 2.2 covers descriptive headings and labels, visible focus and understandable link purpose (WCAG 2.2). Add these to template and component acceptance criteria.
Corporate video, animation and third-party tools also need a performance budget. Google's Web Vitals model evaluates loading, responsiveness and visual stability through LCP, INP and CLS (Web Vitals). Review field data separately for mobile and desktop.
Connect measurement to stakeholder tasks
Traffic and total forms do not prove the site is useful. Measure proposal starts and qualified enquiries for procurement; document use and consultations for technical teams; vacancy views and appropriate applications for candidates; and correct-language journeys for international visitors. Define each event, data owner and report recipient before launch.
Do not leave publishing governance inside design files
After launch, different teams will update solutions, people, cases and careers content. Define role-based permissions, draft–approval–publish workflows, revision history, media rules and required SEO fields in the management platform. Material legal or commercial claims may need a second approval. Before removing old content, evaluate redirects, archives and dependent documents.
A maintenance agreement is more than a technical update window. It should cover access removal when owners change, coordinated updates across language pairs, periodic tests for forms and integrations, broken-link and image checks, and verification that analytics events still work. State the frequency, evidence format and incident owner for each control.
Deliverables to require
- Stakeholder tasks and content routes
- Page, evidence and content ownership inventory
- Turkish–English localisation and language mapping
- Mobile and accessible prototypes including failure states
- Proposal, careers and technical-consultation form scenarios
- Analytics events and qualified-enquiry definitions
- Source, account, documentation and maintenance handover
Use the website requirements guide to develop the brief and review the Kumsal Ajans web design service for delivery scope. A successful corporate website is not one display for everyone; it is a manageable system that connects the right stakeholder to credible information and the right business action.