The borough supports several procurement settings within a short radius. Central Woking contains offices, professional firms and the Victoria Place retail complex. Sheerwater has commercial and industrial premises; Byfleet and West Byfleet add trading estates, workshops and service businesses. Horsell, Goldsworth Park, Knaphill, Brookwood and Old Woking sustain practices whose instructions are frequently personal rather than corporate. Search intent therefore changes by district and task. A facilities manager seeking planned maintenance requires coverage, mobilisation and escalation information. A resident selecting a solicitor or clinician requires professional standing, privacy assurances and an intelligible first appointment. Combining those requirements beneath an all-purpose ‘solutions’ page weakens both decisions.
For an organisation selling to larger employers, the website should function as a controlled pre-qualification record. We inventory the questions repeatedly appearing in requests for information, supplier questionnaires and due-diligence calls, then assign a durable home to each answer. Typical records include legal identity, operating territory, insurance or accreditation boundaries, named responsibility, subcontracting policy, service levels, continuity arrangements, data handling and documented outcomes. Not every item belongs on an unrestricted page; commercially sensitive evidence may sit behind a request or within the tender response. The public layer should nevertheless contain enough specific material for a buyer to record a defensible longlist decision. Ownership and review dates are established at content-model stage so obsolete assurances do not remain online by accident.
Woking's technical economy calls for separate evidence structures rather than a generic technology theme. A telecoms or software provider may need deployment topology, interoperability, migration sequence, resilience assumptions, support demarcation and a route for security documentation. Automotive engineering and specialist production instead depend on materials, tolerances, inspection, traceability, batch capability and change control. The reader, document owner and approval cycle differ in each case. Case material is consequently indexed by problem, environment and measurable result, not displayed as an undifferentiated logo wall. Enquiry capture also follows the operating model: estate, user volume and incumbent platform for a managed service; drawing revision, quantity, material and required date for manufactured work. Better inputs reduce avoidable qualification calls and permit a useful initial response.
Procurement vocabulary deserves literal treatment. PQQ, RFI and ITT readers are not at the same stage. A PQQ-oriented corporate section establishes eligibility: company particulars, financial or insurance thresholds, policy coverage, certifications and exclusions. RFI material explains the feasible operating model and lets both sides expose assumptions. An ITT support area may hold schedules, response matrices, clarification updates and controlled downloads. We label these functions rather than disguising everything as ‘resources’. Version, issue date, applicability and owner can accompany documents where validity matters. Superseded files are withdrawn, direct URLs are redirected, and an archive decision is recorded. This is mundane information governance, but it prevents a polished interface from distributing contradictory policies or an expired certificate during evaluation.
The same discipline applies after a prospect has qualified the firm. We specify enquiry routing as an operational workflow: required fields, consent wording, recipient, acknowledgement, response target, escalation and retention. A tender invitation should not share a queue with a routine appointment request. A drawing upload should state accepted format, size and confidentiality treatment. A vulnerability report needs a protected route rather than a sales form. Analytics then measure useful events — specification download, framework enquiry, booked assessment, completed RFQ — instead of celebrating undifferentiated page views. CRM or service-desk integration is considered only where ownership exists on the receiving side; automating an unowned mailbox merely conceals delay. These controls are agreed in a decision log and tested with realistic submissions before release.
Corporate publishing also creates an approval problem. Legal, compliance, information security, operations and marketing may each own one fragment while nobody owns the assembled page. At commencement we produce a content register with accountable approver, source record, review interval and expiry trigger. Claims such as geographical coverage, response commitment, accreditation scope or quantified saving are linked to evidence. Draft comments are resolved against that register, preventing an unsupported superlative from surviving because it appeared in an old brochure. Accessibility, privacy and cookie behaviour are handled as acceptance criteria rather than launch-week accessories. The result is easier to audit and cheaper to maintain: when a standard, senior contact or service boundary changes, the affected records can be found without rereading the entire site.
A practical acceptance schedule might read quite differently from a conventional design checklist. Identity: registered particulars reconcile across footer, privacy notice and proposal template. Authority: every badge or membership names the issuing body and applicable entity. Capability: each service states inputs, outputs, exclusions and responsible contact. Assurance: certificate numbers, expiry points and downloadable files agree. Performance: quantified results retain baseline, period and source. Contact: test submissions reach a monitored queue and receive the promised acknowledgement. Resilience: essential telephone, address and service information remains usable when scripts fail. Inclusion: keyboard order, labels, focus, contrast and error recovery pass review. Records: owners can locate and revise governed content without a developer. These are binary release tests wherever possible; ‘looks credible’ is not an auditable acceptance criterion.
Regulated and advisory practices require another information hierarchy. The organisation, individual practitioner and service are separate records. A visitor may need to establish which entity contracts, which professional performs the work, whether an authorisation covers the requested activity, how fees are calculated, and where a complaint would go. We place those answers at the decision point instead of collecting them in an obscure legal page. Biographies identify role and substantiated experience without inflated seniority. Service entries declare who the work is unsuitable for as carefully as who it serves. Sensitive intake is kept proportionate: an initial form gathers enough to route the matter, not an unnecessary case history. Privacy wording explains the immediate processing event in plain terms and points to the full notice. This architecture assists both Woking residents checking a referral and purchasing teams commissioning professional advice.
Local discoverability is treated as data maintenance, not repeated town-name prose. The canonical name, address, telephone, opening status, appointment rules and service boundary must remain consistent wherever they are published. Coverage language distinguishes a staffed site, a visitable office, a mobile territory and remote delivery. For Woking town centre, practical arrival information may include station-facing directions or access to Victoria Place; an industrial unit in Sheerwater or Byfleet may instead need gate, loading, vehicle and collection instructions. A practitioner serving Horsell, Knaphill or Goldsworth Park can list a real catchment without manufacturing a page for every neighbourhood. Structured location records, map references and visible contact details support verification; invented micro-offices do not. Changes of premises or hours receive an owner and effective date so third-party listings are corrected alongside the website.
Before handover we run scenario-based checks using roles rather than vague user types. Scenario A: a procurement analyst has seven minutes to confirm legal entity, capability, insurance and a comparable engagement. Scenario B: an engineer needs a process limit, compatible standard and route to send a controlled drawing. Scenario C: a risk reviewer seeks privacy, continuity and security contacts without entering a marketing funnel. Scenario D: a referred patient or client needs the named professional, indicative fee basis, accessibility and first available action. Scenario E: an incumbent customer wants support rather than another sales conversation. Each scenario has a required destination, evidence set and completion signal. Failure becomes a content or routing defect with an owner; it is not excused as a preference. This method gives stakeholder review a common basis and stops homepage debate consuming the project.
Delivery is administered from Nerdster's studio in Egham, in the Borough of Runnymede. Egham lies northwest of Woking; the two are separate Surrey towns, and this entry does not imply a branch address. A requirements workshop, stakeholder interview or content audit can be held in Woking when physical attendance will shorten approval. Routine production remains documented through calls, written decisions and shared previews. That hybrid arrangement is a practical geography statement, not borrowed local identity: no invented Woking team, mailbox or client list is used as proof.
