Project intake software for agencies: route by request class, not one form

Project intake software for agencies does four jobs: it captures a request, classifies what kind of request it is, routes it to an owner with a response deadline, and hands a complete brief to whoever does the work. Most tools sold into this category handle the first job and the fourth. Classification and routing are where agency intake quietly breaks, because a new-client enquiry, a change request on a live build, a retainer task and a tyre-kicker all arrive through the same form and land in the same queue — where a project manager sorts them by hand, again, every Monday.

So the question to bring to a demo is not "does it have custom forms." Everything has custom forms. The question is whether one entry point can produce four different field sets, four different owners and four different destinations, without asking the client to guess which form applies to them.

The four request classes one intake form usually collapses

Agencies rarely receive one type of request. They receive four, and each has a different cost of being wrong.

The routing decision should be made by the form, not by a person. One branching question at the top — "Is this about a project we are already building for you?" — separates the two highest-volume classes. A second question about whether an agreement is already signed separates the other two. Two questions, four paths.

Here is the test that matters: count the humans standing between "request arrives" and "request sits in the correct queue with an owner." If the answer is more than zero for routine classes, your intake software is a collection form, and the routing is still being done by a person who has other work.

The 14 fields: eight that block kickoff, six that do not

Long forms are not the problem. Undifferentiated forms are. Split every field into one of two buckets and treat them differently.

Blocking — no kickoff date without these eight:

1. The single decision-maker, by name and email. Not "the marketing team." 2. A fixed date and what it is tied to: a trade fair, a campaign launch, a contract end. A date with no anchor is a preference. 3. A scope count: how many pages, templates, screens or deliverables. A number, not "a small site." 4. Budget band or an approved figure. 5. Content ownership: who writes the copy, who supplies photography, and by when. 6. Access: domain and DNS, hosting, CMS, analytics — and who currently holds those credentials. 7. Brand assets: logo in vector, font files plus who holds the licence, colour values. 8. Success in one sentence, written by the client, in their words.

Deferrable — useful, but they never justify holding a start date:

9. Reference sites, with a note on what specifically they like about each. 10. Tone and voice notes. 11. Integrations wish-list. 12. Any accessibility or legal requirements the client's side believes apply, plus who on their side confirms them. 13. Internal stakeholders who will comment on drafts. 14. Post-launch maintenance expectation.

The reason for the split is behavioural. A client staring at 34 mandatory fields at 6pm does not answer them badly — they close the tab, and you record that as "they went quiet." Eight required fields with six optional ones underneath produces a form a busy person can finish in one sitting and improve later. If you want the longer version of what belongs in the brief itself, see project briefing software for designers: a practical selection guide.

The start rule you can actually enforce

Three states, one rule, applied by whoever owns intake that week:

• Green: 8/8 blocking fields plus at least 4 of the 6 deferrable. Book the kickoff.
• Amber: 8/8 blocking, fewer than 4 deferrable. Book discovery only — no production hours, no designer assigned.
• Red: any blocking field missing. No calendar slot exists. The missing field gets a named owner on the client side and a date.

The value of writing this down is not precision. It is that the decision stops depending on who is most optimistic on a Friday afternoon, and starts depending on a count anyone can verify in ten seconds.

Intake latency budget: where ten working days go

Most agencies measure intake as one number — "about two weeks" — which hides the stage that is actually broken. Budget it per stage instead.

Ten working days, and each stage has an owner who can be asked about it. Track the median of stage three across your last ten projects. If it sits above four days, the cause is usually one of two things: the form asks for material the client cannot produce alone (credentials held by their IT provider, vector logos held by an ex-agency), or it asks for the same thing in two places.

What one missing blocking field costs: a model with your own numbers

This is arithmetic, not a research finding. Substitute your inputs; the structure is what transfers.

Take a five-person studio running 14 projects per quarter. Assume each missing blocking field triggers one chase cycle, and cost that cycle at:

• writing the chase email: 6 minutes
• the reminder three days later: 3 minutes
• reading the reply and filing the answer: 4 minutes

That is 13 minutes of coordination per missing field. Assume 2.3 missing blocking fields per project — do not take my number, count it: open your last ten kickoff threads and tally the messages asking for something the intake form already requested.

At those inputs, one project carries roughly 30 minutes of chasing, and a quarter carries about 7 hours of coordination across 14 projects. Chases run in parallel, so treat the calendar effect as the longest single wait rather than the sum: at an average 3.5 working days per answer, that is 49 project-days of slip spread across the quarter.

Seven hours is annoying. The 3.5 days is the part that hurts, because it lands inside a ten-day intake budget you have already sold to the client as "we start next week." Recovering it is not a matter of chasing faster; it is a matter of the field being unmissable at the point of collection.

Buy, build, or stay in a document: thresholds by volume

Software is not free even when the licence is. Someone maintains the templates, the routing rules and the permissions. My rule of thumb, based on where that maintenance overhead stops exceeding the cost of manual sorting:

• Under 6 qualified intakes per quarter: a templated document and one shared folder per client. A dedicated tool adds admin you will not amortise.
• 6 to 25 per quarter: a dedicated intake portal earns its place — one link per project, structured templates per project type, and an export you can hand to whoever builds the thing.
• Over 25 per quarter, or three request classes running at once: intake belongs inside the system of record, with a client-facing portal as the front end. Two disconnected sources of project truth cost more than either tool.

Cross-check against a second variable before deciding: how many people touch a request before it is assigned. Even at four intakes a quarter, three touchers means the coordination is the work, and a tool pays for itself. Volume alone under-counts the problem in agencies where the founder still forwards every enquiry. The broader operational picture is covered in design agency workflow software: streamline client intake.

Eight checks that separate intake software from a form builder

Score each 0, 1 or 2 for a 16-point total. Run the test, do not read the feature page.

Below 10 points, you are looking at a form builder with a portal skin — workable for one request class, fragile across four. Between 10 and 13, it will hold a single class well. At 14 or above, it can carry mixed intake. For a deeper walkthrough of the portal-specific criteria, see how to choose client portal software for your agency.

Two trial tests worth more than a feature comparison

Run one real project through the trial, not a test project you invent — a fake client answers every field perfectly and teaches you nothing.

The outsider test: export the finished brief and hand it to a freelancer who was in none of the calls. Give them 20 minutes and ask what they would build. If they come back with questions the brief should have answered, the template is short a field, and you now know exactly which one.

The difficult-client test: send the link to the client who replies in fragments and forwards things from their phone. Intake tools are easy to evaluate against organised clients. The disorganised ones are the reason you are buying software.

Where intake setups fail

The interrogation. Sixty fields sent to someone who has never written a brief. The failure shows up as silence, and silence gets logged as a slow client rather than a form problem. Early sign: your completion rate on the deferrable half is below a third.

Nobody owns a stalled intake. A form sitting at 40% for nine days belongs to no one. Assign stalled intakes to a person by name, with a day number that triggers a call.

Intake data that does not travel. The brief lives in the form tool, the project lives somewhere else, and on day two the designer asks the client something the client already typed. This is the single most common reason intake software gets blamed for not working — the data was collected and then stranded. No email chains at the start is worthless if the answers never reach production.

Two sources of scope truth. The intake form says eight pages, the signed proposal says six. Decide in advance which document governs, and write that sentence into the form itself so the client sees it at the moment they answer.

Common questions

What is a project intake?

Project intake is the process between a request arriving and work being scheduled: capturing the request, classifying it, deciding whether it proceeds, collecting the inputs the team needs, and assigning an owner. It is distinct from onboarding, which happens after a project is approved and covers contracts, access and introductions.

How is intake software different from a CRM?

A CRM tracks the relationship and the pipeline — who they are, what stage the deal is at, what it might be worth. Intake software collects the inputs required to start work, and increasingly the files that go with them. They overlap on exactly one of the four request classes: the unqualified enquiry. If a tool is being sold to you as both, check where a 200 MB asset folder actually lives.

How should agencies choose project management software without relying on a ranking?

Shortlist on two variables rather than a league table: how many distinct request classes you handle, and whether the intake data lands in the same system where the work is tracked. An agency running one class, all new-build projects, can pair a light intake portal with almost anything. An agency running change requests against live retainers needs intake and execution in one place, or someone will spend their week copying fields between tools. Ranking lists cannot know which of those you are.

Is there a free option for project intake?

Free tiers of general form builders can carry a single request class, and some client portals include a starter plan. Two things to verify on the vendor's own pricing and documentation pages before you rely on one: the file size and storage limits, since brand assets and video are what break free tiers first, and whether structured export is included or reserved for paid plans. Limits change, so check the current page rather than a comparison article.

What does "structured export" mean in practice?

That the brief leaves the tool as data, not as a PDF someone has to retype: a machine-readable file with the field values, a readable summary for humans, and the client's uploads organised in folders — produced in one action. The test is whether a new team member can be handed that archive and start.

Before you book a demo, do the count. Open your last ten kickoff threads and mark every message that asks for something your intake already requested. That number, and which of the eight blocking fields it clusters around, tells you more about which tool you need than any feature grid will.