Content Request Intake Form: Which Fields Belong to the Requester

A product marketer fills in the content request form on a Thursday afternoon. Under “target keyword” they type the product's tagline. Under “tone” they write “professional but fun,” and under word count they pick 2,000 because that was the top of the dropdown. The one thing the content team needed, the customer question that started all of this on a sales call two days earlier, appears nowhere on the form. Nothing asked for it.

The form worked exactly as designed.

The pages that rank for content request forms mostly agree on the fields. EasyContent's best-practices guide and Sanity's glossary entry on intake workflows are the most useful of them, and both list some version of goal, audience, deadline, references and an approver. EasyContent adds keywords and tone. Both are right that a form beats a request dropped into Slack. Neither says which of those fields the person filling in the form is actually equipped to answer. Our view is that an intake form should ask a requester only for what they know better than the content team, and leave every search and craft decision blank, because a guess typed into a form has hardened into a requirement by the time it reaches a writer.

One test for every field

Go through your current form line by line. If the requester knows the answer better than your strategist does, the field stays. If your strategist knows it better, the field moves into the brief, where the person qualified to fill it will.

Most forms fail this test in about half their fields.

Fields the requester should fill in

• The trigger, in someone else's words. Paste the exact question a prospect asked (or the support ticket it arrived in) and say where it came from. “Three prospects this month asked whether we integrate with HubSpot, two of them on calls Dana ran” is worth more than every other field on the form put together. It is the raw material for both the keyword and the angle, and the requester is often the only person in the building who heard it.
• The reader's situation. Describe where the reader is in their decision, because a job title tells the writer very little: “ops managers who have seen a demo and are now comparing us against a spreadsheet.”
• What the reader should do next. One action.
• The date, and the reason for the date. A launch on the 14th is a deadline. “ASAP” tells you how the requester feels. Make the reason a required field and the second kind mostly disappears.
• Who can check the facts. Name the subject matter expert and say whether they have actually agreed to give the writer half an hour. If they have, the SME interview can be scheduled before the brief is finished.
• Material they already hold. Release notes, the launch deck, the call recording, last quarter's pricing sheet if pricing changed. Paste links. Summaries lose the detail the writer needs.

Fields to take off the form

Target keyword. A requester types the phrase their own team uses, and internal language is frequently the language nobody searches for. Choosing a keyword means reading the results page, which is the strategist's job and happens after intake, as part of SERP analysis for the brief. Once someone has written a keyword on a form with their name on it, talking them out of it takes a meeting.

Word count. Length follows from what the page has to cover and what already ranks. Nobody outside the content team has the information to pick it, and a number chosen from a dropdown will still be quoted back at the editor three weeks later.

Tone. Your style guide already settled this. If a requester wants a page to sound different from everything else you publish, have that conversation directly, once, instead of collecting a fresh adjective with every request.

Title. Ask a requester for a title and you get a headline written for their manager.

The priority dropdown

Everyone picks High.

Where the request turns into a brief

A request is complete when the strategist can write one sentence from it without asking a follow-up, naming the reader and what we want them to do once they finish reading. Until that sentence exists, nobody should be drafting a brief, and the fastest fix is usually a ten-minute call with the requester about the trigger field.

Once it exists, the strategist turns the trigger question into the phrase a reader would actually search. Paste that phrase into the ContentBrief.io brief generator and it reads the current top results and comes back, in about 30 seconds and for free, with an outline of five to eight H2s, six to ten questions readers want answered, a summary of each competing page, and a target length. Then do the step most teams skip: put the requester's original question next to the generated questions list and see whether it is there.

If it is, you have a search page, and the requester's evidence tells you which of the generated questions to lead with. If it is not anywhere in the list, or anywhere on the first page of results, the people asking your sales team are asking something the search results do not reflect yet. That can still be worth writing. It is probably a page sales sends by link, and it should be briefed and measured that way rather than given a keyword it will never rank for. From there the brief follows the normal steps in how to write a content brief, and the request becomes one item in the queue described in our SEO content workflow guide.

Requests that are not articles

Some requests should leave the content queue at intake. “A blog post about our funding round” is a press release. “A page comparing us to the competitor who just undercut our price” may be a real article, but it needs proof the requester has to supply, and our guide to briefing a comparison page lists what that is. Saying so at intake costs one reply. Saying so after a writer has spent a week on the draft costs the week, and usually some goodwill with the team that asked.

Keep the original request attached to the brief either way. When a page underperforms six months later, the first question in a content post-mortem is what the page was supposed to do, and the requester's trigger field answers it in their own words. It also settles what the requester signs off on during brief approval: the angle and the next action, which came from them, and never the keyword, which did not.