--- title: "Client Onboarding Workflow | Orangescrum" description: "A repeatable client onboarding process for agencies and services firms. The roles, the thirty day plan, the handover from sales to delivery." canonical: https://www.orangescrum.com/use-cases/client-onboarding --- # Client Onboarding Workflow | Orangescrum > For the complete documentation index, see [llms.txt](https://www.orangescrum.com/llms.txt). [Home](/) / [Use cases](/use-cases) / Client onboarding Use case # Client Onboarding That Is _the Same Every Time_ The first thirty days set the tone for the whole engagement. Make them a checklist rather than whatever the account manager happens to remember. Available in[Cloud](/pricing "Cloud - included")[Self-Hosted](/self-hosted "Self-Hosted - included")Open Source [Start Free Trial →](/sign-up?utm_source=website&utm_medium=feature&utm_content=usecase_client-onboarding)[Book a Demo](https://calendly.com/orangescrum) Client management is in Cloud and Self-Hosted · Unlimited users, so clients cost nothing to add ## The scenario Sales closes a deal on a Friday. On Monday the delivery team has a client name, a contract they have not read, and a kickoff call in two days. Some clients get a polished first month, others get chaos, and the difference is which account manager picked it up. A repeatable onboarding turns that into one project, created from the same template, with the same thirty steps every time. Runs Once per new client Typical span 30 days Start from Simple or Task Tracking template Owner Account manager or delivery lead Who is involved ## Who is _involved_ Onboarding fails at the handovers, so name the owner at each one. | Role | What they own | What they see in Orangescrum | | Sales | Everything agreed before signature, handed over accurately | The handover task, with the fields they have to complete | | Account manager | The relationship and the thirty day plan | The onboarding project and the client's other projects | | Delivery lead | The work itself and the team assigned to it | The delivery board and the team's workload | | Finance | Billing setup, the first invoice, and the rate card | Approved timesheets and the invoices raised from them | | The client | Their side of the dependencies, which is usually the bottleneck | Only the project they are invited to, limited by their role | The workflow ## Thirty days in _eight steps_ Days one to five are the handover. The rest is delivery starting properly. 1. 1 ### Make sales complete a real handover A handover is not a forwarded email thread. Make it a task with required fields, so the delivery team gets scope, commercials, contacts, and anything that was promised verbally. - Capture the agreed scope, the rate, the billing cycle, and the named client contacts as fields rather than prose - Anything promised in the sales process that is not written down is the thing that causes the argument in month three Carried by[Custom fields](/custom-fields)[Task management](/task-management) 2. 2 ### Create the client and the onboarding project Set the client up once, then create the onboarding project against them. Every future project for that client hangs off the same record, so you can see the whole relationship rather than a list of unrelated projects. Carried by[Client management](/client-management-software) 3. 3 ### Load the thirty day checklist The same steps, every client. Kickoff scheduled, access granted, tools connected, first deliverable agreed, invoice raised. If it is a checklist, it happens. If it is in someone's head, it happens sometimes. - Build it once as a reusable checklist group and it arrives on every new onboarding task - A completion rule can hold the task open until the required boxes are ticked Carried by[Checklists](/checklists) 4. 4 ### Invite the client, with the right access Bring the client into the project rather than emailing them updates. Roles control what they can see, so they get their project and nothing else. - Unlimited users on every plan means inviting a client costs nothing - Give them a role that lets them comment and approve, not one that lets them see other clients Carried by[User roles and permissions](/user-role-management)[Collaboration](/project-collaboration-software) 5. 5 ### Agree the first deliverable and the dates Put the first four weeks on a timeline the client can see, with the dependencies that sit on their side clearly marked. Most onboarding delays are a client asset that arrived late, and a shared timeline makes that visible before it becomes a problem. Carried by[Gantt chart](/gantt-chart)[Project calendar](/project-calendar) 6. 6 ### Put the documents where they belong Contract, brand guidelines, credentials brief, and the statement of work belong with the project, not in an inbox. Teams that must keep client documents inside their own network can use the self-hosted document management module. - Document management is available in the Self-Hosted edition - Cloud teams attach files to the project and tasks they relate to Carried by[Document management](/document-management)[Wiki](/wiki-management) 7. 7 ### Start tracking time from day one Not from the first invoice. From the first hour. Onboarding time is real cost, and firms that do not track it are usually surprised at how much of the margin it eats. - Log time against the task, so it is attributable rather than a weekly guess - Timesheets get approved and then become the basis of the invoice Carried by[Time tracking](/time-tracking)[Timesheet](/timesheet) 8. 8 ### Raise the first invoice, then review at day thirty Turn approved time into the first invoice while the engagement still feels new. Then hold a short internal review: was the scope what sales sold, is the margin what you assumed, and does anything need renegotiating now rather than in month six. Carried by[Invoicing](/invoice-software)[Budget and cost management](/budget-and-cost-management) Set it up ## Build it _on Monday morning_ One hour to build, then every future client takes ten minutes. 1. 1Create one onboarding project properlyUse the Simple or Task Tracking template, and build the thirty day plan into it as tasks with owners and offsets from day one. 2. 2Write the checklist onceTurn the repeatable steps into a reusable checklist group, so the next client's tasks arrive with the steps already on them. 3. 3Add the handover fieldsScope, rate, billing cycle, client contacts, and anything promised verbally, as custom fields on the handover task. 4. 4Decide the client roleCreate or pick a role that gives clients comment and approval rights on their own project only, and use it every time. 5. 5Set the billing rhythmAgree who approves timesheets and when invoices go out, and put those as recurring tasks so they are not somebody's memory. 6. 6Reuse itFor the next client, create the project the same way and load the same checklist. The point of the exercise is that client eleven gets what client one got. If you run many small engagements at once, put every client's onboarding project under the same client record so you can see the whole book of work in one place. The result ## What good _looks like_ Every client gets the same first month The experience does not depend on which account manager picked up the deal. The handover is complete Delivery starts knowing the scope, the rate, and what was promised, because those were required fields. The client knows what is expected of them Their dependencies are on the shared timeline, so late assets are visible early. Onboarding cost is known Because time was tracked from hour one, you know what winning a client actually costs you. The first invoice goes out on time It comes from approved timesheets rather than a reconstruction at the end of the month. Problems surface at day thirty, not month six The review catches scope drift and margin problems while they are still fixable. Watch out ## Where this _usually goes wrong_ The verbal promise Something agreed on a sales call never reaches delivery, and surfaces as a complaint later. ✓ A required field on the handover task for anything committed verbally. Untracked onboarding time Setup, kickoff, and access wrangling are treated as free and quietly destroy the margin. ✓ Track time from day one, against the onboarding project. The client is emailed, not invited Updates live in inboxes, so nobody has a shared view and every question is a new thread. ✓ Invite the client with a limited role. Unlimited users means it costs nothing. Client dependencies are invisible The project slips waiting for assets, and it looks like your fault. ✓ Put client owned tasks on the shared timeline with their name on them. Onboarding never ends Without a defined finish, the engagement drifts and nobody reviews whether it worked. ✓ A fixed day thirty review, in the calendar, with the margin numbers to hand. Documents scattered The contract is in one inbox and the brand guide is in another. ✓ Attach them to the project. Self-hosted teams can use document management for stricter control. Features used ## Everything this _runs on_ Document management is available in the Self-Hosted edition. The rest is in both Cloud and Self-Hosted. [Client managementEvery project for a client in one place](/client-management-software)[ChecklistsThe same thirty steps for every client](/checklists)[Custom fieldsScope, rate, and contacts as real data](/custom-fields)[User roles and permissionsClients see their project and nothing else](/user-role-management)[Time trackingKnow what onboarding costs you](/time-tracking)[TimesheetApproved time, ready to bill](/timesheet)[InvoicingTurn approved time into the first invoice](/invoice-software)[Document managementClient documents on your own servers, in Self-Hosted](/document-management) Frequently asked questions ## Client onboarding _FAQ_ How long should client onboarding take? Thirty days is a good default for a services engagement. The point is less the length and more that it has a defined end with a review, rather than drifting into business as usual without anyone checking whether it went well. Can I give clients access without paying for extra seats? Yes. Every Orangescrum plan includes unlimited users and pricing is flat, so inviting a client, a contractor, or a stakeholder does not change what you pay. Roles control what each of them can see. Will the client see my other clients? No, provided you set their role correctly. Roles and permissions control project level access, so a client sees only the projects they are a member of. Which project template should I use for onboarding? Simple or Task Tracking. Onboarding is a sequence of tasks with owners and dates rather than an iterative delivery flow, so you do not need the sprint tooling. Where should client contracts live? Attach them to the project so they sit with the work. Firms with stricter requirements, such as those who cannot let client documents leave their network, can run the self-hosted edition, which includes a document management module. Can I bill from the time my team logs? Yes. Time is logged against tasks, timesheets are approved, and invoices are raised from approved time, so billing is a short step rather than a monthly reconstruction. Is there a client portal? There is no separate client portal product. Clients are invited into the project itself with a limited role, which in practice works better because they see the real work rather than a summary somebody had to maintain. Does Orangescrum integrate with our CRM? Orangescrum is not a CRM and does not replace one. The handover into delivery is what this workflow covers, and it is captured as a task with required fields rather than a system integration. ## Make onboarding repeatable Clients, checklists, time, and invoices in one place, with unlimited users on every plan. [Start Free Trial →](/sign-up?utm_source=website&utm_medium=feature&utm_content=usecase_client-onboarding_cta)[Book a Demo](https://calendly.com/orangescrum) ## Related use cases [Campaign launchRun the work you just sold](/use-cases/campaign-launch)[Quarterly planningCheck you can staff the new client](/use-cases/quarterly-planning)[Employee onboardingThe same idea, pointed inward](/use-cases/employee-onboarding)[Simple templateThe project template this starts from](/project-templates/simple) [See all use cases →](/use-cases)