Requests arrive as a Slack message saying we need a landing page by Thursday. Here is the model behind an intake app that fixes that, the prompts to build it, and what it takes to run it.
Your private status link is on its way to your inbox.
A campaign brief intake app is four parts: a brief form that adapts to the request type, prioritisation against capacity rather than arrival order, a queue requesters can see, and a record of what shipped. The field that changes the most is the objective. A brief that says what success looks like as a number produces different work from one that names a deliverable, and asking for it up front filters out the requests nobody can justify.
Campaign intake
23
In the queue
14
Above the capacity line
9
Delivered, no result
11 days
Median to delivery
Rebrand of hub
Brand · no objective stated
Conference booth
Events · 80 leads · 69
Partner webinar
120 registrations · 74
Case study, Halden
cited in 20 deals · 71
Q4 launch page
300 sign-ups by Nov · 88
14 briefs
capacity runs out here
You run marketing operations or a marketing team that takes requests. You already have too many. What you want is briefs that can be started without a meeting, and a priority order you can defend.
What a requester does, and what the team does with what they get.
A landing page needs the conversion goal and the destination. An event needs dates and audience size. One long form produces short answers on all of it.
"We need a landing page" is a deliverable. "300 qualified sign-ups by the end of Q3" is an objective, and it produces different work.
Most deadlines are preferences, and people find it hard to justify a date they invented.
With the components shown, so a score can be argued with specifically rather than generally.
And what sits below it is shown, not hidden. A queue with no capacity model just re-sorts an impossible list.
Prompted after delivery, because nobody returns on their own, and without them next quarter is the same argument.
A campaign intake app is not a request form. It is four parts, and the second is the one that makes the queue defensible.
Fields that change by request type, with the objective expressed as a measurable outcome, the audience, the deadline and its reason, and the assets or approvals already in place.
A score from strategic fit, expected impact, effort and deadline, combined with a capacity model, so the queue reflects what can actually be done.
Requesters see position, status and expected start, without asking. Most escalation is caused by an absence of information rather than by genuine urgency.
What shipped, when, and what it produced against the objective in the brief. This is what makes next quarter's prioritisation an evidence-based conversation.
These prompts start from a Helix project, which is what handles sign-in, credentials and hosting. Start with Helix
Paste these into Claude Code, Codex or Cursor in order. Each one leaves you with something that runs, so you can stop after any step.
Adaptive fields, and two questions that filter out the rest.
In this Helix project, build me a campaign brief intake app.
Capture the requester and team, the request type, the objective, a
measurable target, the audience, the key message, the channels, the
deliverables, the deadline, the reason for that deadline, the budget, and
any dependencies.
Adapt the fields to the request type. A landing page needs the conversion
goal and where it points. An event needs dates, audience size and the
session detail. One long form for everything produces short answers on
every field.
Then two rules that do most of the work.
Require an objective and a measurable target, and reject a brief where the
objective just restates the deliverable. Say why. "We need a landing page"
is a deliverable. "300 qualified sign-ups by the end of Q3" is an
objective, and it produces different work from the same team.
And require a written reason for the deadline. Most deadlines are
preferences, and it is surprisingly hard to write a justification for a
date you made up.
I sign in through Helix, so do not build a login page. Read the signed-in
user from the runtime. And do not put any key or connection string in the
code: if this needs to reach another system, tell me and I will create the
connection in my workspace.Worth knowing. Requiring a deadline reason removes more artificial urgency than any scoring model.
Scoring, and the capacity line that makes it honest.
Score each brief on strategic fit, expected impact, effort and deadline
pressure, each weighted, from a config file I can edit. Show the
components as well as the total, so a score can be argued with
specifically rather than dismissed generally. Effort is estimated by the
delivery team, not by the requester.
Then build a capacity model: who is on the team, their available hours per
week by discipline, and their current commitments. Rank the queue by score
and draw a line where capacity runs out.
Show what is above and below that line explicitly. A queue with no
capacity model just re-sorts a list that is longer than the team can
deliver, and everybody stays disappointed for a different reason.
Let a leader override the order with a reason, and log every override. The
overrides list is the most honest description of a company's real
priorities that exists anywhere.Worth knowing. Showing the capacity line converts an argument about individual requests into a conversation about how much the team can do.
Visible status, and honest timing.
Build the team queue: in progress, scheduled, and backlog, with owner,
score, deadline and status.
Then the requester's view: their own briefs, their position in the queue,
status, expected start and expected delivery. Most escalation comes from
not knowing where something sits rather than from genuine urgency, so this
reduces interruptions more than it increases arguments.
Let me edit the status list, and include "needs more information", which
returns the brief to the requester with the specific gaps named and pauses
its clock.
Track time in each status, and report time waiting on the requester
separately from time with the team.
Support dependencies between briefs, so a launch needing three pieces
shows as blocked on the slowest one.Outcomes, and the uncomfortable number.
On delivery, record what shipped with links, the date, and the actual effort
against the estimate.
Then record results against the objective in the brief: the metric, the
target, the actual, and when it was measured. Prompt for it a configurable
period after delivery, because nobody comes back on their own.
Report briefs by type, team and quarter. Delivered against requested.
Estimate accuracy by discipline. Time from submission to delivery, split
into time with the team and time waiting. And results against target where
they were recorded.
Rank requesting teams by volume and by results, which is a conversation
worth having once a quarter with the data present.
And flag briefs delivered with no result recorded past the prompt period.
A large number there means the objectives were never real, which is itself
the finding.Worth knowing. The count of delivered briefs with no recorded result is the most useful uncomfortable number in this app.
The step that turns a working prototype into something with your data in it.
Now connect it to the systems we actually run, so it works on real data
rather than the rows you seeded.
Anything in angle brackets is a placeholder. Swap it for whatever we use
instead, and have the app name the connection it wants rather than assume
a vendor, so changing my mind later is a config change and not a rewrite.
<Asana>. Read current commitments to build the capacity model, and push
scheduled briefs into it.
<Okta>. Resolve requesters and their teams from the directory, so a brief
is attributed to a real person without anybody maintaining a list.
<Google Analytics>. Pull results against the objective, which is what
makes next quarter a different argument.
<Slack>. Tell a requester where their brief sits, which removes most of
the escalation.
<Marketo>. Read what actually shipped and what it produced, so results are
not self-reported.
<Google Drive>. Hold the assets and the brief together, rather than a link
to a link.
<Snowflake>. Read pipeline attributed to each campaign, which is the only
honest result field.
Only write where I have said to write. Everything else is read only.
Do not write a key, a token or a connection string anywhere in the code,
and do not ask me to paste one. Tell me which connections you need and I
will create each as an authentication in my Helix workspace. Reference
them by alias.Worth knowing. Every name in angle brackets is a placeholder for whatever you run. Helix holds the credential as a workspace authentication, so the app references an alias and never the secret itself.
The last step of every build: a URL, and the right people on it.
Deploy my app.Worth knowing. Your assistant runs helix deploy underneath and the app comes back as a URL. Budgets, priorities and override reasons are internal, so set Access Control before sharing: requesters see their own briefs, the team sees the queue.
Prioritising against capacity means reading where the team's time is actually going.
Asana
Read current commitments to build the capacity model, and push scheduled briefs into it.
Okta
Resolve requesters and their teams from the directory, so a brief is attributed to a real person without anybody maintaining a list.
Google Analytics
Pull results against the objective, which is what makes next quarter a different argument.
Slack
Tell a requester where their brief sits, which removes most of the escalation.
Marketo
Read what actually shipped and what it produced, so results are not self-reported.
Google Drive
Hold the assets and the brief together, rather than a link to a link.
Snowflake
Read pipeline attributed to each campaign, which is the only honest result field.
Each line says whether the app reads, writes or both. Anything not described as writing should be read only.
Named systems are the ones most teams actually run, not a list of the only ones that work. Swap in whatever you use.
Each connection is an authentication in your Helix workspace, referenced by alias. The app names the connection it wants and never holds the credential, so nothing here ends up in your code and any of it can be rotated or revoked without a redeploy.
The build gets you a working intake app. It holds budget figures and priority decisions across teams, so it needs to be run properly rather than shared as a link.
AI Deployment
One command takes the app from your assistant to a live address, so the people who need it get a link rather than instructions for running it locally.
App Security
Priorities, budgets and override reasons are internal. SSO means people sign in with their existing account, and access is scoped so requesters see their own briefs while the team sees the queue.
App Security
Pulling campaign results and spend from analytics and finance systems to close the loop needs real access. Granting it to the app rather than pasting keys into it means credentials can be rotated or revoked without a redeploy.
App Registry
Every app carries a named owner and an entry IT can see, so the tool does not become nobody's problem when the person who built it changes role.
Cost Management
Per-app spend visibility, with budgets and caps, so an internal tool cannot quietly become a line item nobody can explain.
The objective as a measurable target rather than a deliverable, the audience, the key message, the channels, the deadline and the reason for it, the budget, and any dependencies. Adapt the fields to the request type, because one long form produces short answers on all of them.
Require a written reason for the deadline. Most deadlines are preferences, and people find it hard to write a justification for a date they chose arbitrarily. It removes more artificial urgency than any scoring model.
With a score from strategic fit, expected impact, effort and deadline pressure, ranked against an explicit capacity model. Without the capacity line, prioritisation just re-sorts a list that is longer than the team can deliver.
Because most escalation comes from not knowing where something sits rather than from genuine urgency. Showing position, status and expected start reduces interruptions more than it increases arguments.
Recording outcomes against the objective in the brief. Without them, next quarter's prioritisation is the same argument with the same information. The count of delivered briefs with no recorded result is itself a finding.
Yes. The prompts here are written for Claude Code, Codex or Cursor and stage the build. The judgement calls are your scoring weights and your capacity model.
Marketing
One calendar covering every channel, with review routed by what the content contains rather than by who remembers to ask. Prompts to build it, and what it takes to run it.
Marketing
Track committed spend alongside invoiced spend by programme, so a channel owner knows what they have left before they commit it. Prompts to build it, and what it takes to run it.
Marketing
Run the logistics, capture leads with context, attribute pipeline honestly over a real window, and know before you book again. Prompts to build it, and what it takes to run it.
Finance
Route purchase requests by amount and category, hold an approval trail finance can audit, and stop chasing sign-off in email. Prompts to build it, and what it takes to run it.
Last reviewed September 2026.
Helix is the governed runtime for AI-built apps. Deploy what you build, put SSO in front of it, connect it to your systems with managed credentials, and give it a named owner.
Your private status link is on its way to your inbox.