An agency client onboarding checklist should verify the current agreement, accepted delivery ownership, usable client inputs, appropriate access and readiness for the next stage. Assign an owner and completion evidence to each check. Keep unresolved items visible, and adapt the template to the actual service and start conditions.
An onboarding checklist is useful when it records what the next owner needs to verify. A series of checked boxes is less useful if nobody can explain which agreement applies or what is still missing.
This is a starting template for a marketing agency engagement. Adapt it to the service and the actual agreement. For the workflow design behind it, read the onboarding automation blueprint. That guide explains how records, triggers and exceptions connect; this page gives you the review checklist itself.
- Current agreementThe scope and actual start conditions are clear.
- Usable inputsThe team has reviewed what the next stage needs.
- Appropriate accessRequired accounts and permissions have been checked.
- Accepted ownershipDelivery owns the next step; open items have owners.
These are parallel checks. The delivery owner decides which defined next step can proceed.
Use the checklist with an owner and evidence
Give each item an owner, a status and a reference to the evidence. Useful statuses include not started, waiting, ready for review, accepted and not applicable. Record why an item is not applicable rather than leaving the reviewer to guess.
- Named ownerSomeone is responsible for the item.
- Evidence referenceLink supporting information for review.
- Status chosenUse not started, waiting, review, accepted, or not applicable.
- Reason recordedExplain why an item is not applicable.
Created tasks and delivered emails are not evidence that a requirement was met.
An item is accepted when its reviewer has checked the relevant information. A task being created or an email being delivered does not establish that the underlying requirement has been met.
You can download the editable checklist as a CSV. Add your own owner, status and evidence references. The file is a general planning template and contains no client data.
Before you invite the client into delivery
| Check | Completion evidence | Suggested owner |
|---|---|---|
| Identify the engagement | Current client and engagement reference | Account owner |
| Confirm the accepted scope | Link to the current agreed version | Commercial owner |
| Check start conditions | The engagement's actual signature and billing conditions are satisfied | Authorized start owner |
| Name the delivery owner | A person has accepted the next delivery responsibility | Delivery owner |
| Resolve commercial ambiguity | Any conflicting promise or exclusion has a recorded decision | Commercial owner |
The exact start conditions depend on your engagement. Do not turn this template into a new contractual condition or assume that every service begins at the same billing event. The sales-to-delivery handoff guide explains how to accept the commitment before creating delivery instructions.
Collect and review the inputs
| Check | Completion evidence | Suggested owner |
|---|---|---|
| Request the relevant intake | Client receives questions needed for the next stage | Onboarding owner |
| Review the submitted answers | Required inputs are usable; contradictions have been checked | Delivery reviewer |
| Identify the approval contact | Named client contact has the relevant decision authority | Account owner |
| Locate approved assets | Current files and their source locations are recorded | Delivery reviewer |
| Record dependencies | Each unresolved dependency has an owner and next action | Delivery owner |
| Separate blockers from later inputs | The team knows what stops kickoff and what can follow later | Delivery owner |
Use the client onboarding questionnaire to collect information. Keep the original answers available and record clarifications separately. If the client supplies a different understanding of the scope, return that question to the commercial owner before delivery treats it as a new requirement.
- Required inputCheck whether it is usable.
- Dependency ownerAssign a next action.
- Kickoff blockerStops the next stage.
- Later inputCan follow after kickoff.
Return scope differences from intake to the commercial owner before delivery treats them as requirements.
Check account access and project setup
| Check | Completion evidence | Suggested owner |
|---|---|---|
| Request the right account access | Account, recipient and permission level are specified | Access owner |
| Verify granted access | The intended person can perform the required work | Access reviewer |
| Create or match the project | The engagement points to the right project without an unwanted duplicate | Project owner |
| Prepare the delivery brief | The brief reflects the accepted commitment and relevant inputs | Delivery owner |
| Set the communication route | Client and team know where questions and decisions belong | Account owner |
Handle access through the appropriate provider invitation or approved sharing process. Keep passwords out of the general intake and this checklist. A received invitation may still grant the wrong account or level of permission, so record verification separately from receipt.
Accept readiness and explain the next step
| Check | Completion evidence | Suggested owner |
|---|---|---|
| Review kickoff readiness | Scope, necessary inputs, appropriate access and start conditions have been checked | Delivery owner |
| Assign every open item | Each unresolved item has an owner and a defined effect on the next stage | Onboarding owner |
| Confirm the next client action | The client knows what happens next and what is needed from them | Account owner |
| Record the exception path | The team knows who handles an incomplete handoff or failed action | Workflow owner |
Readiness can be conditional when the team clearly defines which next step is allowed. For an illustrative website engagement, discovery might proceed while a later content input remains open. That does not authorize publishing, change the approved scope or mean every missing access item can wait.
- Allowed next stepDefine what may proceed.
- Open later inputKeep its owner and status visible.
- Unavailable accessDo not assume every access item can wait.
- Delivery decisionRecord the readiness judgment.
Conditional readiness does not change scope or authorize publishing.
Improve the checklist from completed engagements
After a few engagements, review the items that repeatedly remain open or are checked without useful evidence. Ask delivery whether the checklist helped them begin the agreed work. Remove redundant checks and clarify vague ones.
Measure the handoff rather than the appearance of completion. Track avoidable clarification, duplicate projects, missing access and unresolved decisions. Keep changes dated so the team can understand which checklist applied to an engagement.
If you want help evaluating the process, bring a sanitized example to the ScaleAxis operations audit. Confirm the engagement scope and supported systems before making an implementation commitment.
Questions and answers
What should a client onboarding checklist include?
Include the current agreement, start conditions, delivery owner, relevant intake, required assets, access verification, project setup and the readiness decision. Give unresolved items an owner and identify whether they block the next stage.
Is a client onboarding checklist the same as a questionnaire?
A questionnaire collects information from the client. A checklist records whether the engagement requirements have been reviewed and accepted. Link them, but do not treat a submitted questionnaire as proof that the project is ready.
Can we use the same checklist for every agency service?
Start with shared checks, then adapt the inputs, access, owners and readiness conditions to each service. Remove irrelevant items or mark them not applicable with a reason. A discovery engagement and a production project can need different checks.