How agencies collect website content from clients (without chasing)

Ask any web agency what makes client sites launch late and you'll hear the same answer: content. The design is signed off, the build is ready, and the team is waiting on an About page, three service descriptions and a set of photos that were "coming this week" a month ago.

It's tempting to blame the client. In practice, most content delays come from the way the content was asked for. The request was vague, it was spread across several emails, nobody owned each page, and there was no clear finish line. Fix the process and most of the chasing goes away.

Here's a practical way to collect website content from clients that works for a five-page brochure site and for a 150-page rebuild.

Why collecting content stalls

Before changing anything, it helps to name the usual causes:

• The client doesn't know what you need. "Send us your content" is not a task anyone can finish. It has no edges.
• Requests are scattered. One email asks for the team bios, a call mentions the case studies, a shared folder has a half-finished questionnaire. Nobody has the full list.
• No one owns each page. The client's marketing lead assumes the product manager is writing the product pages, and the product manager assumes the opposite.
• Review has no end. Copy goes back and forth with comments, but nobody ever says "this is approved".
• Files live in five places. Email attachments, a Google Drive folder, a Dropbox link and a WhatsApp photo, all with different versions.

Every step below is aimed at one of these.

1. Agree the sitemap before you ask for a single word

Content requests should come from the sitemap, not from memory. Before you ask the client for anything, agree the list of pages the site will have: every page, where it sits, and its address.

If it's a rebuild, go through the current site page by page and mark each one as keep, rewrite, merge or drop. Dropped and merged pages need redirects, so note them now; they're easy to forget at launch.

The sitemap becomes your content checklist. Once it's agreed, "what do you need from us?" has a precise answer: copy for these pages, by these dates.

2. Turn every page into a specific request

A good content request answers four questions:

1. What is needed: the page, its purpose, and roughly how much text.
2. Who is writing it: one named person, not "the team".
3. Where it should go: the document or folder you want it in.
4. When it's due.

For example:

Services > Commercial cleaning (/services/commercial-cleaning). Please write 300–500 words covering who the service is for, what's included, and how to get a quote. Sam is writing it. Please use the linked Google Doc. Due Friday 14th.

That takes a minute to write and saves a week of back-and-forth. If a page needs input from a subject expert, say so in the request and name them.

3. Decide where the copy lives, then stick to it

Most clients are happy writing in Google Docs, Word online or SharePoint. Let them. Asking a client to learn a new editor is one more reason for the work to stall.

What matters is that there is one document per page and that each page in your sitemap links to its document. Use a simple naming pattern such as "Services – Commercial cleaning" so documents are easy to find. When feedback comes in by email, move it into the document as a comment so the history stays in one place.

4. Give every piece of content one status

A page's copy should always be in exactly one of a few states:

• Not started
• In progress
• Ready for review
• Sent back with changes
• Approved

When every page carries a status, the project status meeting becomes a glance at a list. You can see which pages are blocking launch and who they're waiting on, and you stop sending "any update?" emails to everyone.

5. Set dates, and let reminders do the nudging

Chasing is draining because it's personal. A reminder that arrives automatically two days before a due date doesn't feel like nagging; it feels like a calendar doing its job.

Agree due dates at the start, spread them out so the client isn't asked for everything at once, and send reminders from a system rather than from your inbox. Group pages so the client writes related pages together, such as all service pages in one week.

6. Make approval explicit

"Looks good!" in a reply-all is not approval. It's a mood. When you build a page from that email and the client later says they never approved it, there's no record to point to.

Agree who the approver is for each page, usually one person on the client side. Approval should be a deliberate action: they mark the copy approved, and you record who did it and when. If they want changes, it goes back to the writer with a note, and the status says so.

7. Plan for the content that doesn't arrive

Some pages will be late no matter what. Decide early what happens then. A useful approach is to split the site into versions: the pages that must exist on launch day, and the pages that can follow a few weeks later. The case studies, the team pages and the detailed FAQ are common candidates for the second version.

That way one missing page doesn't hold up the whole launch, and the client can see exactly what's in each version.

8. Hand off from one list

When copy is approved, the designer or developer needs a clean list: every page, its address, the link to the approved copy, and any redirects. If they have to dig through email threads to find the final version, mistakes creep in. Build the hand-off list from the same sitemap you started with, so nothing is missed.

Which tools help?

You don't need special software to do any of this, but it helps to know what each type of tool is good at:

• A spreadsheet plus shared documents works for small sites. One row per page, columns for writer, status, due date and document link. It's free and familiar, but statuses go stale unless someone updates them by hand.
• Client content-collection tools such as Content Snare are built for gathering files and answers from clients through a portal, with automated reminders. They're especially useful for logos, photos, questionnaires and forms.
• DraftBay, which we make, is built for the page-by-page part: map the sitemap, request copy for each page, track its status, review and approve it with a trail, and export a hand-off spreadsheet for the designer. Copy stays in Google Docs, SharePoint or Word online, DraftBay sends the reminders, and one team update email tells everyone what changed and what's waiting on them.

Whatever you use, the principles are the same: one list of pages, one owner and one due date per page, one place for each document, one clear status, and explicit approval.

A short checklist

• Sitemap agreed, including redirects for removed pages
• Every page has a writer, a due date and a linked document
• Every page has an approver
• Statuses are visible to the agency and the client
• Reminders are automatic
• Launch and post-launch pages are split into versions
• The hand-off list comes from the same sitemap

Collecting content will never be the fun part of a web project. But with a clear list, clear owners and a clear finish line, it stops being the reason the site is late.