Client intake vs client onboarding: choosing the right workflow
Compare client intake and client onboarding using the same source packet, distinct useful outputs, and a reviewable Righthand brief.
Quick answer
Use client intake to establish what a prospective engagement needs. Use onboarding to prepare a confirmed client to begin work with the agreed people, documents, and access.
The practical test is the question your reviewer needs answered. Start both workflows from the same dated input packet, then judge the usefulness of their different outputs. Righthand can help prepare either draft from owner-provided records or an approved read view; the reviewer retains authority over decisions and external actions.
Compare the same input
Use this shared packet: One client's submitted request, approved scope, contact list, signed engagement status, and supplied setup checklist. Keep stable identifiers, source links, and a cutoff so another person can reproduce the comparison. Missing information stays explicitly unknown rather than becoming an invented fact.
| Workflow | Useful output | Review owner |
|---|---|---|
| Client intake | Missing requirements, scope questions, and a recommended intake disposition | The client services lead |
| Client onboarding | An ordered setup plan with owners, prerequisites, and readiness checks | The client services lead |
Asana's onboarding template uses forms to standardize incoming client information and organize onboarding work. The official Asana client onboarding reference supports this specific distinction; the rest of the example is a suggested operating practice, not a universal provider feature or requirement.
Illustrative worked comparison
Illustratively, the client requests a website refresh but has not confirmed the launch window or domain owner. Intake highlights those questions. Onboarding can prepare a provisional access checklist, but it cannot mark setup ready while the engagement and required access remain unconfirmed.
Evaluate both drafts against that packet before introducing more sources. Changing the input halfway through makes it difficult to tell whether the workflow or newly available evidence caused the difference. Keep assumptions next to the conclusions they affect, and make the next requested decision visible to the reviewer.
Delegation brief for both workflows
Use only the approved input packet described above, with its recorded cutoff. First, prepare an intake summary with known requirements, contradictions, missing answers, and questions for the client lead. Separately, prepare a provisional onboarding checklist using only approved scope, assigning prerequisites and readiness evidence. Use America/Los_Angeles for the review deadline and preserve the original dates and time zones. Run this comparison once and return both drafts in this conversation by Friday at 3 PM Pacific for The client services lead to review. Include source IDs, missing inputs, assumptions, and a next step with an owner. Do not send messages, modify records, make purchases, or approve decisions. If access is unavailable or the packet contradicts itself, report that limitation before completing the affected section.
Check the result
Check that the onboarding tasks trace to the accepted scope. A request for access is incomplete until the correct account and agreed permission have been confirmed.
A completed draft is evidence of preparation, not evidence that its recommended action occurred. The owner should accept or revise the outputs before any separate execution request. For a recurring version, specify the next input window, review deadline, and destination rather than reusing an old snapshot silently.
Failure and recovery
A submitted inquiry may be treated as a won engagement. Retain the actual engagement status and separate proposed setup tasks from work the client has authorized.
Do not invent client consent, contract acceptance, or account access. The client and account owners approve scope and authorize connections.
FAQ
Should I use both workflows?
Use both when the outputs answer distinct questions that are currently useful. Start with the smaller deliverable when review capacity is limited; preserve the shared source packet so the second can be prepared later without guessing.
Does delegation require a native integration?
An approved export or owner-prepared packet can support the first comparison. A live read or later write requires verified connection tools and the appropriate permission; a catalog entry alone does not establish either.
Use Righthand Docs for delegation and permission guidance, check available integrations, and review Pricing before expanding the task.