Website Redesign Client Intake Form Template

Outcome Summary

• Collect the inputs you actually need to redesign a site without endless back-and-forth.
• Get clarity on branding, content ownership, page scope, technical constraints, and approvals.
• Turn the intake into a concrete next step: a redesign demo you can review with stakeholders.

What Revamp Actually Does (Truth Block)

✅ does

• Generates an AI website redesign when you paste a website URL.
• Produces a redesign demo as a live preview link you can share for feedback.
• Lets you add optional design preferences to steer the output.
• Publishes and runs the finished site on Revamp.

❌ does not

• Guarantee SEO, performance, or conversion outcomes from a redesign.
• Replace discovery, stakeholder alignment, or technical feasibility checks.
• Automatically capture every edge-case feature from complex web apps.

The Core Problem

• Clients describe “a modern redesign” but can’t articulate what must stay, what must change, and who decides.
• Missing inputs (brand assets, content readiness, platform constraints) cause scope creep and stalled reviews.
• Teams forget to capture integration details (forms, CRM, analytics), then discover blockers late.
• Approval paths are unclear, so feedback becomes contradictory and hard to act on.

Framework

• Step 1: Set the frame (before the form)

  • Tell the client/team what this intake is for: clarifying scope, constraints, and decision-making.
  • Define how responses will be used (e.g., demo preview, then final scope).

• Step 2: Copy/paste this intake form template

# Website Redesign Client Intake Form

## A) Project basics
- Company / org name:
- Primary contact (name, role, email):
- Other stakeholders to include (names + roles):
- Who is the final approver / sign-off owner?
- Current website URL(s):
- Any subdomains or separate properties that matter (docs, app, help center, careers, etc.)?

## B) Goals & priorities
- Why redesign now?
- What should this redesign improve (pick what matters most):
  - Messaging/positioning clarity
  - Visual design refresh
  - Lead generation
  - Product education
  - Trust/credibility
  - Hiring/recruiting
  - Performance
  - Accessibility
  - Other:
- Primary action you want visitors to take (the “main CTA”):
- Secondary actions (if any):

## C) Audience & context
- Primary audience segments (who is this for?):
- What objections do buyers/users have today?
- Regions/languages to support (if applicable):
- Mobile vs desktop importance:

## D) Brand & creative inputs
- Brand guidelines (link or file):
- Logo files (link or file):
- Preferred colors / colors to avoid:
- Typography preferences (vibe + any required fonts):
- Tone/voice (e.g., direct, playful, premium, technical):
- Examples you like (links + what you like about each):
- Examples you dislike (links + what you want to avoid):

## E) Pages & information architecture
- Must-keep pages (list):
- Must-remove pages (list):
- Must-add pages (list):
- Any required page types/templates (e.g., landing pages, case studies, blog, docs, pricing, careers):
- Navigation notes (what must be in the top nav / footer?):

## F) Content readiness
- What content exists today that can be reused?
- What content must be rewritten (and who owns writing/approval)?
- Do you have customer proof assets (testimonials, logos, case studies)?
- Media assets (photos, illustrations, product screenshots, video) and who provides them:

## G) Functionality & integrations
- Forms (contact, demo request, newsletter) + where submissions should go:
- CRM (if any):
- Email marketing tool (if any):
- Scheduling/booking (if any):
- Payments/checkout (if any):
- Search, localization, authentication, gated content (if any):
- Required embeds/third-party scripts (chat, reviews, analytics, ads):

## H) Platform, access, and technical constraints
- Current CMS/stack (if known):
- Hosting/provider (if known):
- Who controls domain/DNS?
- Who will implement the redesign (your team, an agency, a dev partner)?
- Access you can provide (check what applies):
  - CMS admin
  - Hosting
  - Domain/DNS
  - Analytics
  - Tag manager
  - Search console
  - Code repo
- Non-negotiable constraints (must keep X, cannot change Y, security/legal constraints):

## I) SEO & measurement (practical)
- SEO priorities (if any):
- Any pages that must keep their URLs?
- Redirect considerations (if known):
- Analytics events that matter (lead form submit, signup, demo request, etc.):

## J) Reviews, approvals, and timeline
- Target launch window:
- Review cadence you can commit to (who reviews, how often):
- Preferred feedback format (comments, doc, issue tracker, email):
- Legal/compliance review needed (if any):

## K) Deliverables & handoff
- What deliverables do you want:
  - A shareable redesign demo/preview for stakeholder review
  - Implementable code handoff
  - CMS build
  - Content writing support
  - Ongoing iteration
- Anything else we should know to avoid surprises?

• Step 3: Validate the “unknowns” before doing any design work

  • If they can’t answer parts of the form, turn those into explicit open questions.
  • Decide what you’ll assume vs what you’ll wait on.

• Step 4: Translate the intake into a clear scope draft

  • Pages/templates in scope.
  • Content owners and dependencies.
  • Integrations and constraints.
  • Review/approval path.

• Step 5: Generate a redesign demo from the existing site

  • Use the current URL as the baseline.
  • Add design preferences based on the “Brand & creative inputs” section.
  • Generate a redesign demo and share the live preview link for feedback in context.
  • (If you need to share internally, you can point stakeholders to the preview link rather than static screenshots.)

• Step 6: Run a structured review (reduce subjective feedback)

  • Ask reviewers to comment using the intake priorities (primary CTA, audience clarity, trust proof, navigation).
  • Track decisions: what changes, what stays, who approved.

• Step 7: Confirm implementation path

  • Decide where the site will live: run it on Revamp, or use the approved design as the build reference for your stack.
  • If the site is complex, confirm what will be custom-built vs simplified.

Use Cases

• Agency pitch (client wants “modern,” but stakeholders disagree)

  • Scenario: The founder wants a refresh, sales wants more leads, and brand wants consistency.
  • Recommended approach: Use the intake to capture the final approver, primary CTA, and must-keep brand rules—then share a Revamp-generated redesign demo link for a single, focused review.
  • Common mistake: Starting with moodboards before locking the decision-maker and success priorities.

• In-house marketing refresh (engineering has constraints)

  • Scenario: Marketing owns the site, but engineering owns the deploy process and has strict constraints.
  • Recommended approach: Treat “Platform, access, and technical constraints” as required fields; generate a redesign demo to align on layout and messaging before engineering estimates.
  • Common mistake: Approving a design concept that requires platform changes nobody budgeted to implement.

• Freelancer redesign (content is not ready)

  • Scenario: Client wants new pages but hasn’t written content and has limited proof assets.
  • Recommended approach: Use the intake’s “Content readiness” section to define who writes what; produce a redesign demo for structure/messaging direction while content gets drafted.
  • Common mistake: Committing to page scope without confirming content ownership and approvals.

Decision Checklist

• Do you have a single named final approver (not “we’ll decide as a team”)?
• Is the primary CTA explicitly stated (and consistent across stakeholders)?
• Are must-keep constraints listed (platform, legal, brand, security), not discovered later?
• Is it clear who owns content writing, proof assets, and reviews?
• Do you know which pages/templates are in scope vs “nice to have”?
• Are required integrations identified (forms → CRM, scheduling, analytics, embeds)?
• Can you generate and share a live preview link early to get feedback on something real?

Constraints

• Intake answers may be incomplete; plan for open questions and explicit assumptions.
• Redesign demos are great for alignment, but complex app-like functionality may need custom implementation.
• Stakeholder feedback can conflict; without a final approver, you’ll churn.
• Content availability (and approvals) often becomes the critical path.
• Technical constraints (CMS, hosting, embeds, security) can limit what’s feasible without replatforming.

Practical Example (Illustrative)

Client response highlights (from the intake):

• “Tone: premium but direct.”
• “Colors: keep current brand color; avoid neon accents.”
• “Primary CTA: request a demo.”
• “Must-keep: existing blog URLs; embedded scheduling tool.”
• “Final approver: Head of Marketing.”

How you apply it:

• In Revamp, paste the current site URL.
• In design preferences, specify the tone and visual constraints (premium/direct, keep brand color, avoid neon).
• Generate the redesign demo and share the live preview link.
• Run review prompts tied to their priorities:
  • “Is the demo request CTA obvious on the pages that matter?”
  • “Does this feel premium while staying within brand rules?”
  • “Where should the scheduling embed appear, and on which pages?”
• Capture decisions in writing, then finalize the implementation plan (including whether the site will run on Revamp or in your own stack).

FAQ

Should I send this intake before or after a kickoff call? If stakeholders are aligned, send it before to make kickoff more productive. If alignment is weak, do a short kickoff first so they understand what “good answers” look like.

How do I prevent stakeholders from giving conflicting feedback? Make the intake name a final approver, and ask reviewers to tie comments to stated priorities (primary CTA, audience, brand rules, constraints).

What if the client doesn’t know their CMS/hosting details? Treat it as a discovery task: ask who controls domain/DNS and who can grant access. If nobody knows, plan time to inventory the current setup.

Do I need brand assets before generating a redesign demo? Not always. You can start from the existing site and use design preferences, but you’ll get smoother alignment once brand guidelines and “must-keep” rules are known.

Where does Revamp fit in this process? After you collect the intake, Revamp helps you turn the current URL + preferences into a shareable redesign demo link for faster, more concrete stakeholder reviews. You can start at the Revamp app or learn more on Revamp.dev.