Toronto Website Redesign RFP: A Practical Brief for Comparing Agency Quotes

Use the RFP to Remove Assumptions

A Toronto business asking three agencies for a website redesign can receive three reasonable proposals for three different projects. One includes copywriting, one expects finished copy and another prices a limited template setup. The totals are difficult to compare because the underlying responsibilities differ.

An RFP, or request for proposal, does not need to be a long procurement document. For a small business, a concise brief and a structured response sheet may be enough. The purpose is to explain what the organisation needs and expose what each supplier has assumed.

This guide focuses on selecting and briefing an agency. Use our website redesign SEO checklist for the detailed migration process, rather than duplicating that checklist inside every commercial conversation.

1. Describe the Business Problem in Observable Terms

Replace a request for a modern website with examples of the problem. Perhaps service enquiries arrive without project details, staff cannot update case studies or customers struggle to find the correct location. Explain who is affected and what they need to accomplish.

Provide a baseline if you have one, such as successfully submitted enquiries or the time staff spend making a standard content change. Label missing measurements honestly. Do not invent a conversion target simply to make the brief sound more commercial.

For example, an illustrative goal might be that a visitor can identify the relevant service, understand the next step and send an enquiry from a phone. That can become a testable user journey. A promise to become the leading Toronto brand cannot serve as an acceptance test.

2. Count Templates and Content Separately

Twenty service pages may use one reusable template, while a single interactive estimator may require substantial custom work. List both the types of page and the approximate number of content entries. Include locations, case studies, staff profiles, resources and any campaign pages.

Mark each content item as retain, rewrite, create or retire. Assign ownership of copy, images, approvals and data entry. If the agency migrates content but the business rewrites it, specify which version is migrated and how late changes are managed.

Include downloadable files and embedded services. A redesign scope that counts visible pages but misses brochures, third-party forms and old campaign URLs can underestimate both effort and launch risk.

3. Define the Workflows That Must Survive

Document contact forms, booking tools, CRM handoffs, newsletters and payment journeys where relevant. State the expected result after submission and who receives the information. Link to existing tools and provide anonymised examples rather than sending live credentials during a tender.

For each connection, ask who configures it, who pays the subscription and who investigates delivery failures. A proposal saying CRM integration should explain which fields and actions it includes. Does it create a lead, update an existing record, assign an owner or simply send an email?

Separate launch requirements from later improvements. An honest phase-two list prevents optional features from becoming assumed obligations and makes it easier to protect the first release date when content or external systems are delayed.

4. Specify the Editing Experience

Ask an agency to explain how staff will add a case study, replace a team photograph and edit service content. Require a demonstration of those tasks on the proposed approach. A visual editor can still be difficult if every layout adjustment needs specialist intervention.

Agree on reusable components and publishing permissions. Who can draft, who approves and who can alter navigation? If several departments contribute, a simple review process may be more valuable than giving everyone unrestricted access.

Request documentation and training tied to actual staff tasks. A recorded walkthrough of your page types and a short handover guide are easier to use than generic platform documentation alone. Define whether follow-up questions are included after launch.

5. Make Quality Requirements Demonstrable

Ask for responsive checks on representative phones and desktop widths, keyboard access to navigation and forms, readable validation messages and sensible image handling. Define a representative set of pages and user journeys to review rather than relying on the phrase fully optimised.

For accessibility, distinguish an agreed evaluation scope from a claim of universal compliance. A suitable standard, legal applicability and specialist review needs depend on the organisation. Describe what is being tested and what evidence the agency will provide.

For performance, ask how large media, third-party tools and hosting affect the proposed build. Record the testing conditions. A single score taken on an empty template is not evidence that a media-heavy production site will perform the same way.

6. Give Search Migration Its Own Deliverables

Require an inventory of important existing URLs, a reviewed destination map where paths change and a way to verify redirects. Assign responsibility for metadata, internal links, sitemap updates and removal of staging restrictions at release.

Google's site-move guidance describes preparing, mapping, redirecting and monitoring changed URLs. Use it as a reference when defining responsibilities. No agency can responsibly promise that every ranking remains unchanged during a redesign.

Ask who monitors problems after launch and how urgent issues are reported. A fixed launch-day handoff with nobody assigned to broken important URLs is different from an agreed period of post-launch observation and correction.

7. Ask Agencies to Respond in the Same Format

Request a scope summary, deliverables, exclusions, assumptions, project stages, team responsibilities and recurring costs. Ask for separate lines for optional work. Identify whether quoted amounts are in CAD or another currency and how applicable charges are presented, rather than assuming all proposals use the same basis.

An illustrative evaluation weighting could be scope understanding 30%, implementation and quality approach 25%, ownership and support 20%, relevant evidence 15% and price 10%. Adapt this to your organisation. These are suggested procurement weights, not industry benchmarks.

Review evidence carefully. Ask what the agency actually delivered on a referenced project and whether it can demonstrate similar editing or integration requirements. A visually attractive screenshot does not establish responsibility for strategy, development or measurable results.

8. Agree on Ownership, Changes and Launch Readiness

Clarify ownership and access for the domain, hosting, code repository, CMS, analytics and paid assets. Record what you can export and what happens if you change suppliers. Some licensed products may have separate terms; identify them rather than assuming every dependency is transferred outright.

Define how change requests are documented, priced and approved. Also explain how business-side delays affect the schedule. A simple responsibility list for content delivery and approval dates can prevent repeated disputes about who is holding up launch.

Before acceptance, walk through a real content edit, a labelled test enquiry, important old URLs and the agreed device checks. Confirm backups, access handover and support contacts. Keep a list of outstanding items with owners and completion expectations instead of treating launch as proof that everything is complete.

A Short RFP Starter You Can Adapt

Company and audience: describe the organisation, services and main user groups. Current problems: list three specific obstacles. Launch scope: identify templates, approximate page counts and essential workflows. Content: state who writes, supplies and approves each type of material.

Technical context: list the current platform, integrations and access constraints. Quality: specify representative journeys and checks. Delivery: give a preferred launch window and known dependencies. Supplier response: request scope, exclusions, recurring costs, ownership, support and an itemised commercial proposal.

Keep confidential customer records out of the initial brief. Share deeper technical access only when needed through a suitable process. The strongest RFP gives agencies enough evidence to scope responsibly without collecting unnecessary sensitive information.

Frequently Asked Questions

Does a small business need a formal website RFP?

Not always. A short written brief and consistent response questions can be sufficient. More formal procurement is useful when several stakeholders, integrations or suppliers are involved.

Should the budget be included?

A realistic range can help agencies propose an achievable scope. Ask them to explain what fits within it and which optional items would be deferred, rather than treating the range as a request to spend the maximum.

How do I compare two very different quotes?

Normalise the scope first: templates, content, migration, integrations, quality checks, training and support. Ask each supplier to identify missing responsibilities and recurring costs before comparing the totals.

Should I request a free homepage design from every agency?

A relevant portfolio, a discovery conversation and an explanation of the proposed approach can be more informative. If a design exploration is important, define a properly scoped exercise and its ownership terms.

Plan Your Next Step

Preparing a brief? Explore our Toronto web design services and send your current URL, main problems and required launch workflows so the proposal can address the actual project.