How to Brief a WordPress Agency So You Get Exactly What You Actually Want
Most failed WordPress projects don’t fail because of bad developers — they fail because of bad briefs. Here’s how to write one that gets you the site you actually need.
Table of Contents
Why Most WordPress Project Briefs Fail Before a Single Line of Code
I’ve reviewed hundreds of project briefs over the years, and I can usually tell within the first two paragraphs whether a project is headed for success or a slow, expensive spiral of revisions. The pattern is almost always the same: the brief describes a solution instead of a problem. It lists pages and features without ever explaining what the business actually needs the site to accomplish.
A brief that says “we need a homepage with a hero slider, three service cards, and a testimonial carousel” tells me what you think the solution looks like. But it doesn’t tell me why those elements matter, what user behavior you’re trying to drive, or what success looks like six months after launch. That gap is where misalignment lives — and misalignment is the single most expensive thing in web development.
The worst part? Agencies are partly to blame. Many shops will happily take a prescriptive brief and build exactly what’s described, because it’s the path of least resistance. But a good agency should push back and ask harder questions. Your job as the client is to give them the raw material to do that. That starts with a brief that’s honest about goals, constraints, and what you don’t yet know.
Start with Business Outcomes, Not Feature Lists
The single most important section of your brief isn’t about WordPress at all. It’s about what your business needs. Before you describe a single page or plugin, answer these questions: What is this website supposed to do for your company in the next 12 months? Are you trying to generate demo requests? Reduce support ticket volume? Establish credibility with enterprise buyers? Recruit engineers?
When I receive a brief that opens with clear, measurable outcomes — something like “increase qualified demo requests by 30% while reducing our sales team’s time spent on unqualified leads” — I immediately know how to evaluate every design and development decision against a real standard. Every feature either serves that goal or it doesn’t.
I’ve seen companies spend $40,000 on a WordPress build packed with features nobody uses because the brief never established what mattered. Meanwhile, I’ve seen $15,000 builds outperform them dramatically because every decision was anchored to a specific business result. Outcomes-first briefing doesn’t just help the agency — it protects your budget.
Describe Your Users Honestly, Not How You Wish They Behaved
Every brief should include a section on your audience, but most of them read like aspirational fiction. “Our users are CTOs at Fortune 500 companies who carefully evaluate our thought leadership content before scheduling a strategic consultation.” In reality, that CTO is on their phone between meetings, scanning your site for 15 seconds to decide if you’re worth a second look.
Tell your agency the truth about your users. How do they actually find your site? What device are they on? What’s their level of technical sophistication? What objections do they have? What competing tabs are open in their browser right now? If you have analytics data, share it — even if it’s embarrassing. If your bounce rate is 80%, that’s not a secret to hide; it’s the most important data point in the entire brief.
In my experience, the clients who share real user behavior — including the messy, unflattering parts — end up with sites that convert dramatically better. We can’t solve problems we don’t know about, and we can’t design for users we’ve never been introduced to honestly.
Be Upfront About Content: Who Writes It, Who Owns It, Who Updates It
Content is the silent project killer. I cannot overstate this. More WordPress projects stall or fail because of content than because of any technical issue. Your brief needs to address content head-on: What content exists today? What needs to be written from scratch? Who on your team is responsible for producing it, and do they actually have the bandwidth?
Equally important is post-launch governance. Tell your agency who will be updating the site after launch and what their technical comfort level is. If your marketing coordinator has never used WordPress and is terrified of breaking something, that fundamentally changes how we build the editing experience. We might use ACF blocks with guardrails instead of giving them full Gutenberg freedom. We might build a style guide directly into the CMS.
My view is that a WordPress site is only as good as the team maintaining it. If the brief doesn’t address ongoing content operations, the agency is building a site for launch day — not for the 365 days that follow. Be honest about your internal capacity, and a good agency will design a system that works within those real constraints.
Why Hiding Your Budget from Your Agency Always Backfires
I understand the instinct to withhold budget information. You’re worried the agency will just spend whatever number you say. But here’s what actually happens when you hide your budget: the agency either over-scopes the project and prices you out, or under-scopes it and delivers something that doesn’t meet your needs. Both scenarios waste everyone’s time.
A transparent budget lets us do the most important part of our job — prioritization. If you have $25,000 and a list of 15 features, I can tell you which 8 features will deliver 90% of the business value and which 7 are nice-to-haves for a phase two. Without that number, I’m guessing, and guessing leads to proposals that miss the mark entirely.
The same applies to timeline. If you have a hard launch date tied to a product launch or industry event, say so in the brief. If the timeline is flexible, say that too. Every constraint you share makes the proposal more accurate and the project more likely to succeed. Treat your agency like a strategic partner, not an adversary in a negotiation, and the results will speak for themselves.
The Anatomy of a Brief That Gets You a Great WordPress Site
After everything I’ve covered, here’s what a genuinely useful brief includes — and it doesn’t need to be longer than two or three pages:
- Business context: What your company does, who you serve, and where the website fits in your growth strategy.
- Goals and KPIs: 2–4 measurable outcomes the site needs to drive, ranked by priority.
- Audience reality: Who your users actually are, how they behave, and what data you have to prove it.
- Content plan: What exists, what needs creating, who’s responsible, and who maintains the site post-launch.
- Technical context: Integrations, existing tools (CRM, marketing automation, analytics), hosting preferences, and any non-negotiable technical requirements.
- Budget and timeline: A realistic range and any hard deadlines, with context for why they matter.
- References: 3–5 sites you admire, with specific notes about what you like and why — not just “I like the vibe.”
I’ve seen this format transform client-agency relationships. When both sides start from a place of clarity and honesty, the entire project runs faster, costs less, and delivers something that actually moves the needle. A great brief isn’t extra work — it’s the highest-leverage hour you’ll spend on the entire project.
This post represents my own professional opinion based on my experience. It is not legal, financial, or technical advice for your specific situation, and it is not a statement of fact about any third-party product, plugin, or company.