How to get website content out of clients (without chasing)

Ask any agency where projects stall and you'll get the same answer: waiting for content. The design is approved, development is scheduled, and somewhere in a client's inbox sits an email titled "Website copy???" that nobody will ever answer.

The usual diagnosis is that clients are slow. The real problem is that "send us your content" is an impossible brief. You've asked a busy person, who has never written a website, to produce an unspecified amount of copy, in no particular format, for pages they can't picture, by a deadline that came from your project plan rather than their calendar. Of course nothing arrives.

Getting content out of clients isn't a chasing problem. It's a process design problem, and it's fixable.

Why "send us your content" always fails

Break down what you're actually asking for and the failure is predictable:

• The client can't see the shape of the ask. "The About page" isn't a shape. Three hundred words? Three thousand? A founder story or a list of accreditations? Without structure, every page is an essay assignment — and people postpone essay assignments.
• Nobody owns anything. Content requests go to "the client" — an organisation, not a person. The marketing manager thinks the MD is writing the About page. The MD thinks the agency is. Six weeks pass.
• There's no way to say "this bit is done". Copy arrives in one giant document, half-finished, with "TBC" scattered through it. You can't start design on the finished parts because you can't tell which parts are finished.
• Feedback arrives as conversation, not decisions. "Can we make the intro punchier?" in an email thread is not an approval state. Nothing is ever signed off, so everything stays open forever.

Every fix below attacks one of those failures.

Step 1: Build the structure before you ask for a single word

Before any content request goes out, the site's structure should exist: the page tree, and within each page, the sections it's made of — hero, proposition, proof, call to action. Not designed. Structured.

This changes the ask completely. "Write the About page" becomes: "This page has five sections. The hero needs a headline of about ten words and a supporting sentence. The team section needs a two-sentence bio per person. Here's an example of each."

A blank page is a threat; a labelled box is a form field. People fill in forms.

Do this in whatever tool you like — a spreadsheet works, though it gets painful the moment things change. The point is the principle: structure first, then words. Nobody should ever be asked to write into the void.

Step 2: Every section gets one owner and one date

Not "the client" — a named person, per section. The founder writes the story on the About page. The ops manager owns the services descriptions. Your copywriter owns the homepage.

Two rules make this work:

1. One owner per section, never per page. Pages are too big to own; sections are an afternoon's work. Small ownership is ownership that actually happens.
2. Dates are agreed, not assigned. Ask "when could you realistically get this done?" and hold people to their own answer. A deadline someone chose is ten times stickier than one they were given.

When you can see owners and due dates across the whole site, chasing transforms. Instead of "any news on the content?" — a question that invites silence — you send: "The three sections you own are due Friday; two are done, the hero headline is still open." Specific, small, answerable.

Step 3: Stage the work so "done" means something

Copy isn't binary. A useful scale has about five states: not started, in progress, draft, ready for review, final. The exact labels matter less than the shared meaning — especially the difference between draft ("directionally right, wording loose") and final ("I'd be happy for a customer to read this").

Staging fixes the giant-document problem. Design and build can start on final sections while stragglers catch up. Your project's critical path stops being the slowest paragraph on the site.

Step 4: Make review feel like reading a website, not marking homework

Here's the step almost everyone skips, and it's the one that changes client behaviour most.

Clients are bad at reviewing copy in documents because documents don't look like websites. A wall of Helvetica in a Google Doc gives no sense of hierarchy, rhythm, or what's a headline versus a caption. So clients review the only thing they can see — the words as prose — and miss the questions that matter: does this page make the case? Is anything missing? Would a visitor keep scrolling?

Show them the content in place instead: real words, in real sections, on a page they can scroll like a website — even as plain wireframes. Feedback quality jumps immediately. "Punchier?" becomes "the proof section should come before pricing", which is feedback you can act on.

And when they approve, capture it properly: per section, recorded, attached to the exact version they read. "Looks great!" in an email approves nothing in particular. A recorded approval of a specific section, frozen at a specific moment, ends the era of "that's not what I signed off".

Step 5: Chase the system, not the person

With structure, owners, dates, and stages in place, chasing mostly automates itself. The weekly nudge writes itself from the state of the work: what's due, what's late, what's blocking design. Nobody has to compose an awkward email, and no client feels nagged — the system is just reporting the plan they agreed to.

The clients didn't get better. The ask did.

The short version

1. Never request content without structure — sections, not pages, are the unit of work.
2. One named owner and one self-chosen date per section.
3. Five stages, so "done" is a fact rather than a feeling.
4. Review happens on something that looks like the website, and approvals are recorded per section.
5. Chasing becomes a status report, not a personal appeal.

We built Blocky because we run an agency and got tired of doing all of this across nine documents and a spreadsheet — it holds the structure, the owners, the stages and the sign-off in one place. But the process works wherever you run it. Start with structure; the words will follow.