How to Brief a WordPress Agency So You Get Exactly What You Actually Want
Most WordPress projects that go sideways weren’t doomed by bad developers — they were doomed by bad briefs. Here’s how to write one that sets everyone up to succeed.
Table of Contents
Bad Briefs Kill Good Projects Before They Start

I’ve been on the receiving end of hundreds of WordPress project briefs over the years, and I can tell you with absolute certainty: the quality of the brief predicts the quality of the outcome more reliably than budget, timeline, or even the skill of the development team. A vague brief doesn’t just slow things down — it creates a vacuum that gets filled with assumptions, and assumptions are where projects go to die.
The most common version of a bad brief I see from B2B tech companies is what I call the “wishlist dump.” It’s a bullet-pointed list of features — mega menu, custom calculator, HubSpot integration, blog with filtering — with zero context about why any of it matters. The agency nods along, quotes a number, starts building, and three months later the client says, “This isn’t what I had in mind.” Of course it isn’t. Nobody ever explained what was in their mind.
A good brief isn’t a spec sheet. It’s a communication tool. It tells the agency what problem you’re solving, who you’re solving it for, and what success looks like. Get those three things right and you’ve already eliminated 80% of the misunderstandings that plague WordPress builds.
Start With the Business Problem, Not the Feature List
Before you write a single word about homepage sliders or page builders, I need you to answer one question: what is this website supposed to do for your business? And “look better” is not an answer. Are you trying to shorten your sales cycle? Reduce support tickets? Capture more qualified leads from organic search? Enter a new market segment?
When a client tells me, “We need to increase demo requests from mid-market SaaS buyers by 40% in the next two quarters,” I can make a hundred smart decisions they’d never think to specify. I know the CTAs need to be prominent. I know the case studies page matters more than the about page. I know page speed on mobile is critical because these buyers are researching on the go. Context changes everything.
In my experience, the best briefs dedicate the first full page to business context — your market position, your growth goals, what’s broken about the current site, and why now is the right time to fix it. This isn’t fluff. It’s the foundation every design and development decision gets built on.
Define Your Audience With Uncomfortable Specificity
“Our audience is IT decision-makers” tells me almost nothing. Are they CTOs at 50-person startups evaluating tools for the first time, or are they enterprise procurement managers comparing your solution against three incumbents? Those two people need radically different WordPress experiences, and if your brief doesn’t distinguish between them, your agency is guessing.
I always ask clients to describe their top two or three audience segments with enough detail that I could recognize one at a conference. What’s their job title? What keeps them up at night? What objections do they have about your product? What did they Google before they landed on your site? This level of specificity might feel excessive, but it directly informs information architecture, content hierarchy, and conversion paths.
Here’s a practical tip: include real quotes from your sales team. Things like, “Prospects always ask about SOC 2 compliance before they’ll book a demo” or “Most leads come in already comparing us to Competitor X.” These nuggets of insight are gold for an agency that knows what to do with them, and they belong in your brief — not buried in a Slack thread three weeks into development.
Show What You Like and Explain Why You Like It
Reference sites are incredibly useful — but only when they come with context. Sending an agency five URLs with no commentary is like handing someone a Pinterest board and saying, “Make my house look like this.” I need to know what specifically you’re drawn to. Is it the typography? The way the pricing page is structured? The overall sense of restraint in the design? The scroll animations?
I recommend creating a simple table: the URL, a screenshot of the specific element you’re referencing, and a one-sentence explanation of why it resonates. Something like, “I like how Stripe’s documentation page uses a left-rail nav — we need something similar because our product has 30+ features and users need to self-serve.” That’s actionable. That’s useful. That saves everyone time.
Equally valuable is showing what you don’t want. If your last agency built you a WordPress site drowning in parallax effects and you hated every second of it, say that. Negative references eliminate entire categories of wrong answers and help your agency calibrate faster than positive references alone. Be honest, be specific, and don’t worry about sounding picky — picky clients get better websites.
Be Ruthlessly Honest About Budget, Timeline, and Internal Politics
I’ve lost count of the times a prospect has told me, “Budget is flexible — just show us what’s possible,” only to reveal three weeks into discovery that the actual budget is half of what was implied. This wastes everyone’s time. A good agency doesn’t judge your budget — they design a solution that fits it. Telling me you have $40K instead of $120K doesn’t mean you get a worse website. It means I scope differently, prioritize differently, and propose a phased approach that delivers real value at every stage.
Timeline honesty matters just as much. If your CEO promised investors a new site by Q3 and that deadline is immovable, I need to know on day one — not day thirty. Hard deadlines change how we staff the project, what we build in phase one versus phase two, and how much risk we can absorb in the design process.
And then there’s the one nobody wants to talk about: internal politics. If the VP of Marketing and the VP of Product disagree on the homepage hero, that’s not a design problem — it’s a stakeholder alignment problem, and it will torpedo your project if it isn’t surfaced early. Your brief should name every stakeholder, define who has final approval, and be transparent about any known disagreements. The best agencies can help you navigate these dynamics, but only if you let them in.
The Anatomy of a Brief That Actually Works
After years of refining what I ask clients to send us, here’s the structure I recommend for any B2B tech company briefing a WordPress agency:
- Business Context: Who you are, what you sell, your market position, and your growth goals for the next 12 months.
- Project Goals: The specific, measurable outcomes this website needs to deliver.
- Audience Profiles: Two to three detailed descriptions of your primary user segments.
- Functional Requirements: What the site needs to do — integrations, content types, user flows — with priority levels (must-have, nice-to-have, future phase).
- Design References: Annotated examples of what you like and don’t like, with explanations.
- Constraints: Realistic budget range, hard deadlines, technical requirements (hosting, existing tech stack), and stakeholder map with approval authority.
- Existing Assets: Brand guidelines, content inventory, analytics access, and any previous discovery work.
You don’t need a 40-page document. I’ve received brilliant briefs that were three pages long. What matters is that every section is specific and honest. A brief that says “we want a modern, clean design” tells me nothing. A brief that says “our current site feels cluttered and enterprise-y, and we’re losing deals to competitors who look more approachable” tells me everything. Put in the work upfront, and you won’t spend the next six months paying for revisions that could have been avoided.
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.