Client onboarding automation: from signed deal to a project folder that is already full
The stretch between a client saying yes and the work actually starting is mostly the same four steps on every project: decide what you need from them, ask for it, follow up until it arrives, and hand it to whoever builds. None of those four steps requires a human to do them by hand every time — and the difference between doing them by hand and automating them is the difference between a kickoff that waits on a logo file and one that starts with everything already in the folder.
This guide is tool-agnostic. It covers what is actually worth automating in this stretch, what BriefGate does with each piece, and which of four routes — the dashboard, Zapier, n8n, or your own code against the API — fits your shop. The three linked guides at the end go deep on each specific tool; this one is the map.
What is actually worth automating
Two of the four steps above are mechanical and repeat identically across projects: asking (send the same kind of request, in the same shape, every time a deal closes) and following up (send reminders until it's done, stop the moment it is). Both are pure overhead — there is no judgment call in sending a reminder email, and doing it by hand mostly means someone forgets to.
The other two steps are not mechanical, and automating them past a point makes the intake worse, not better. Deciding what you need still requires a person to think about the specific project — a template gets you most of the way, not all of it. Reviewing what comes back — is this logo actually usable, is this copy actually final — is a judgment call a client-facing person should make, not a rule engine. BriefGate's own review step reflects this split: a submitted item auto-approves after a set number of hours if nobody acts on it, but nothing stops you from opening the item and requesting a revision first (see Dashboard quickstart).
So the useful automation target is narrower than "the whole onboarding process": define the request once, send it without writing an email, chase it without writing a reminder, and hand off what comes back in a form the next step can use directly. That is also exactly the shape of what BriefGate does.
Start from a reusable request, not a blank page
Every BriefGate item has a type — text, longtext, file, file_list, image, color_list, select, multiselect, boolean, url, secret, or structured — twelve in total, each with its own constraints (minimum image width, a JSON Schema for structured facts like opening hours, allowed file formats). See Item types for the full reference. Typed items mean the portal validates the client's answer before it can be submitted, and whoever reads the result gets a usable value, not a screenshot to eyeball.
The part that actually saves the re-typing is a template: a saved item list you point a new intake at instead of rebuilding it. Three public templates — a restaurant website, an advisor's site, and a club site — ship on every plan including Free, and Solo ($29/month) and up can save their own. On Agency plans, templates any seat member creates are visible to the whole team, so the list only has to be built once per project type. See Templates for the full built-in item sets and how overriding one item while keeping the rest works.
Sending it without writing an email
Once the request exists — from scratch, from a template, or from an AI coding agent calling define_intake — sending it does not mean composing an email. BriefGate emails the client a personal link to their portal: no account, no password, nothing to install. The client sees a branded page (on paid plans) listing what is still needed and what is already done, and nothing on that page mentions how the request was built — dashboard or agent look identical to the client. See What is BriefGate? for what that portal experience actually looks like.
One detail worth knowing if you're wiring this into your own code: the portal_url an intake returns does not, by itself, open the portal — it needs a one-time sign-in token that the API never returns. The client's emailed link carries that token; a link you construct yourself from portal_url alone will not work.
The follow-up cadence running on its own
This is the piece that turns "send once and hope" into "send once and it gets done." You pick a cadence when the intake is created (or change it afterward without re-sending the invitation) and BriefGate handles timing, deduplication, and quiet hours from there — see Chase engine for the complete reference.
| Schedule | Reminders |
|---|---|
default |
T+2 days, T+5 days, T+9 days, then weekly |
gentle |
T+3 days, T+8 days, then every 14 days (also skips weekends) |
aggressive |
T+1 day, T+3 days, T+5 days, then every other day |
custom |
Every interval you set — defaults to every 3 days if left unspecified, bounded between 5 minutes and 90 days |
off |
No automatic reminders |
Reminders are held outside the client's local 8:00–19:00 window unless you explicitly turn quiet hours off, and every schedule except gentle still sends on weekends. The chase engine stops the moment the client finishes, and stops permanently — marking the intake stalled and firing a webhook — once it hits the reminder cap (three attempts by default), so it hands the problem back to you instead of nagging forever. On the Free plan, only default and off are available; the other cadences need Solo and up.
The handover at the end
When the intake completes, there are two shapes the result can take, and which one you want depends on who's on the receiving end.
If a human is going to open the result — a designer picking through photos, an account manager reviewing what came in — Download everything (ZIP) on the intake page bundles every file plus a podklady.pdf and podklady.md summary into one download, organized into one subfolder per item, exactly as the client uploaded it. See ZIP download for the full contents and the size limit.
If code is going to consume the result — your own script, a Zapier or n8n step, an AI coding agent — get_intake_results (or GET /v1/intakes/:id/results) returns typed JSON: signed URLs with checksums for files, a validated object for structured items, plain values for everything else, and a missing array naming anything still outstanding.
Either way, a secret item (a password or API key the client entered) is encrypted on the server on receipt and released once — never end-to-end encrypted, never zero-knowledge, and never rendered on any screen more than that one time. ZIP downloads leave secrets out by default so the one-time reveal stays available; including them consumes it, same as reading them through the API.
Which of the four routes fits your shop
All four routes end up defining the same request, sending the same portal link, and running the same chase engine underneath — what differs is where the "when this happens, do that" logic lives.
The dashboard, by hand. No code, nothing to connect. You build the intake, send it, and watch it come in from the browser. Right for a shop running a handful of intakes at a time where a person is already looking at the dashboard anyway. See Dashboard quickstart.
Zapier. You already have deals, files, and notifications flowing through Zapier and want intake to be one more step in that chain — a CRM "deal won" trigger starting an intake, a completed intake dropping files into Drive. Right for a shop whose stack is already built on no-code connectors. See Zapier client intake automation.
n8n. The same building blocks as Zapier, self-hosted, plus the option to hand BriefGate to an AI Agent node as a tool it decides to call on its own. Right for a shop that wants Zapier-style automation without a third party holding the workflow, or that is already building agentic workflows in n8n. See n8n client intake automation.
Your own code, against the API and webhooks. Full control: a custom agent loop, a CI pipeline, a backend service reacting to intake.completed in real time instead of polling. Right for a shop with engineering capacity that wants intake wired directly into its own systems rather than through a third-party automation platform. See Client intake webhooks guide, the REST API reference, and Webhooks.
Whichever route you pick, the mechanical middle — the request, the send, the chase — is the same. What you're really choosing is where the rest of your business logic already lives, and connecting BriefGate to that instead of building a fifth place for it.