Client intake

How to Standardize Client Intake With a Reusable Request Template

Build the request once and reuse it for every client of that type. Define the set of documents or fields you always need as a template, then create each client's request from it, with the protection and branding set once at the project level.

Build the request once, then reuse it for every client of that type. Define the exact set of documents, credentials, or fields you always need as a template, and create each client's request from it in seconds instead of rebuilding the checklist by hand. Keep the protection and the branding at the project level, so every request made from the template inherits the client's access controls and your branding automatically.

The checklist is the reusable part

Most intake work is the same work repeated. The onboarding for a new client of a given type asks for the same documents, the same logins, the same details, every time. Rebuilding that from scratch for each client is slow and inconsistent, and inconsistency is where things get missed. A template fixes the what: the field set you always collect, defined once. Standardizing intake this way cuts the back-and-forth, gets you legible submissions, and makes onboarding predictable across clients.

Template vs project: what each holds

A request is created inside a project, so it inherits that project's defaults and branding automatically. The template keeps the checklist consistent, the project keeps the protection and the look consistent.

How to standardize your intake

1. Write the field set once. List exactly what a given engagement type always needs, and save it as a template.
2. Set the project up right. Configure the client's project with your branding and its access-control defaults, locked where the level has to be guaranteed.
3. Create each request from the template, inside the client's project, so it inherits both.
4. Adjust per client only where needed, rather than rebuilding from scratch.
5. Keep templates current. When your standard intake changes, update the template so the whole team uses the new version.

Where doconvoy fits

In doconvoy you define an intake template of the fields you always collect and reuse it across clients. Each request is created inside a client's project, so it automatically carries that project's branding and its access-control defaults. You build the checklist once, and the protection and the look are set per client and applied for you. The template keeps the what consistent, and the project keeps the how consistent.

Related: How to collect documents from clients without email attachments · Secure Requests · Workspaces & Projects · Receive client credentials · For consultants

Common questions

What does a reusable request template actually include?

In doconvoy, a template captures the fields and checklist you ask for. The access controls and branding aren't stored in the template. They're set on the client's project, and every request created there inherits them.

Can each client still have different security and branding?

Yes. The template holds the checklist, and each project holds its own access-control defaults and branding. The same checklist can go out under different clients' protection and branding without rebuilding it.

How does a template save time?

You define the intake once instead of rebuilding the checklist for every client, which keeps onboarding consistent, produces legible submissions, and leaves less room for mistakes.