A versioned engagement template
Start onboarding or a monthly pack from a template your firm controls, so every engagement asks for the same things the same way.
New-client onboarding is where mismatched expectations start. Cohesio makes the requirements explicit — and the client-facing checklist consistent — before anyone uploads anything.
Every engagement opens on the requirements list drawn from the template version this client is on. Toggle items for this month only, set the internal owner and due date, and check kickoff tasks. Nothing is sent until you press issue, and the client only ever sees what is currently enabled.

An engagement in Cohesio never starts from a blank page. It starts from a template scoped to a client type — retail, restaurant, ecommerce, professional services, real estate, nonprofit, construction or SaaS — that already lists the document types and questions that client type tends to owe every period. Onboarding a client and issuing this month’s pack both draw from a template; the only difference is which one and how long the requirement list runs.
Each requirement in that list is deliberately narrow: a name, a plain-language instruction the client will actually read, a flag for whether it’s required or optional, and a due date. That specificity is the point. A checklist item that says "upload your March bank statement (checking, ending in the account you used for payroll)" gets answered correctly far more often than a generic request to "send your bank records," because the client isn’t left guessing which account or which month.
Templates carry a version number, and that version matters more than it sounds. Say your firm’s monthly-pack template is on version 3 — you’ve refined it twice since first setting it up, maybe adding a question about a new payment processor. A client whose engagement was issued under version 2 keeps version 2’s requirement list for the engagement already in flight; they don’t get a new item appearing mid-month with no warning. The next time an engagement is drafted for that client — next month, or the next onboarding — it picks up whatever the template currently is, version 3 included.
This separation exists because a requirement list changing under a client partway through a period is exactly the kind of surprise that erodes trust in a checklist. Firms can safely iterate on a template knowing the change rolls forward cleanly instead of retroactively.
Onboarding usually involves internal steps that have nothing to do with what the client submits — confirming the engagement letter is signed, setting up the client in your ledger software, assigning a reviewer. Cohesio tracks these as kickoff tasks attached to the engagement, visible only to staff. They show up in the same queue as document requirements, so nothing internal gets forgotten just because it isn’t client-facing, and an engagement can’t be marked complete while a required kickoff task is still open.
Once requirements and kickoff tasks are set, issuing the engagement sends the client one scoped link — no account creation, no password to invent. What they land on first is a short, named checklist: each outstanding item, its due date, and a plain description of what’s needed. There’s no dashboard to interpret, no unrelated engagement history to scroll past, and no way to see another client’s information, because the link only ever opens the one engagement it was issued for.
Firms migrating an existing roster don’t set clients up one at a time. A CSV import maps a spreadsheet’s columns — client name, contact email, client type — into new client records in one pass, and a QuickBooks Online import pulls the customer list directly, matching by name so existing clients aren’t duplicated. Either path gets a firm from zero to a populated client register in minutes rather than an afternoon of manual entry, which matters most in the first week of adopting a new tool, when the temptation to keep using the old spreadsheet is highest.
Suppose a firm takes on a new client, a fictional two-location restaurant group we’ll call Harbor Table, with a downtown location and a second location that opened eighteen months ago. The owner runs both locations under one entity but keeps separate bank accounts and separate point-of-sale systems for each.
The reviewer starts from the restaurant onboarding template and duplicates the bank-statement and POS-export requirements once per location, renaming each pair ("Downtown — bank statement," "Uptown — bank statement") so the client isn’t left guessing which upload goes where. Kickoff tasks include confirming which entity ID covers both locations in the firm’s ledger software and assigning one reviewer as the engagement owner for both. The client receives a single link listing eight requirements across the two locations, each with its own due date, and the reviewer notes in the engagement that this client structure — two locations, one entity — should carry into next month’s template draft automatically once onboarding closes.
Start onboarding or a monthly pack from a template your firm controls, so every engagement asks for the same things the same way.
Each requirement names the document or answer needed, plain-language instructions, and whether it’s required or optional.
Deadlines live in the checklist itself, not buried in an email thread the client has to search for.
The client gets access to their current engagement only — never a firm-wide account, never another client’s information.
Pull an onboarding or monthly-pack template scoped to the client type in front of you, then adjust the specifics — extra locations, an unusual processor, a seasonal closure — without touching the base template everyone else still uses.

No. A template edit only affects engagements drafted after the change. An engagement already issued keeps the requirement list it was created with, so a mid-month template tweak can’t silently alter what a client already sees as outstanding.
Each engagement has a single owner for edits at any moment, and the workspace shows who has it open. If a second person needs to adjust requirements, they can request it or wait — there’s no silent overwrite of someone else’s changes.
They stay open and visible on the engagement — a due date passing doesn’t close or hide an incomplete internal task. The engagement itself can’t be marked handed off until every required task and requirement has a decision behind it.
No. Importing a CSV or pulling from QuickBooks Online matches on client name and creates new records for anything that doesn’t already exist; it doesn’t merge into or overwrite a client you’ve already set up manually.
Not directly — a client can only submit against what’s currently active, and any wording confusion gets flagged for staff, not edited by the client. If a requirement needs changing, a staff member updates it and the client’s checklist reflects that immediately.
Document collection is where the client actually submits what intake asked for.