Imagine a company rebuilding its brand website with marketing, sales, and IT involved but no dedicated project manager. Before procurement, create a requirements sheet covering the home page, service pages, articles, contact forms, membership or video features, available copy and images, and the visitor path from entry to enquiry. Ask every agency to respond to the same sheet and separate template-versus-custom decisions, mobile layouts, admin roles, integrations, hosting, domain ownership, asset rights, and revision rounds. This prevents a proposal from being judged only by attractive screens.

Define acceptance before selecting a supplier. Request a test checklist covering major browsers and mobile sizes, navigation, form notifications, error messages, loading behavior, permissions, and backups. If search traffic matters, include URL structure, title fields, content-upload responsibility, and analytics setup. Ask who supplies materials, approves copy, publishes changes, and adds future pages. These answers turn a broad service promise into deliverables that can be documented and compared.

Website projects often slow down because materials and decisions have no clear owner. Break the engagement into discovery, information architecture, visual direction, content preparation, development, testing, launch, and handover. Ask each proposal to identify the input, output, owner, and approval deadline for every stage. If the company already has brand guidelines, photography, product information, or an old site, confirm formats, quantities, rights, and cleanup responsibilities. If materials are incomplete, ask for a temporary approach and a replacement process rather than assuming the agency will create everything.

Make handover questions concrete. Ask which source files, copy and image assets, code or theme changes, domain and hosting accounts, analytics tools, form-routing settings, and admin training will be delivered, when, and in what format. For a platform or template, request a demonstration of adding pages, editing metadata, exporting data, and managing access. For ongoing hosting, confirm updates, backups, security notifications, incident contacts, and migration after termination. The useful comparison is not only production ability but whether the business can manage the site afterward.

Design the selection process as a short workshop rather than a request for a standard quote. Give every team the same scenario: reorganize service information, launch core pages first, let the business add articles later, and monitor enquiries from a form. Ask what they would clarify, how they would prioritize features, handle existing URLs, configure tracking, organize reviews, and record changes. Observe whether they can turn a vague goal into pages, workflows, data, and acceptance items; this is more useful than counting design terminology.

Convert the proposal into written confirmation instead of relying on verbal assurances. List page and inner-page deliverables, editable fields, form test cases, mobile and browser checks, search settings, data and account ownership, training, maintenance contacts, and issue-reporting procedures. During acceptance, record each item as passed, pending revision, or out of scope, with versions and change history. When a capability is not documented publicly, mark it for interview confirmation rather than assuming it exists or does not exist. Decisions should rest on verifiable answers and documents.