The 30-60-90 Onboarding Workflow: How to Automate New Hire and New Client Setup Together
Here's the deal: Employee onboarding and client onboarding are usually treated as completely separate processes owned by different teams, but they share the same structural problem: too many manual handoffs between too many systems. Automating them with the same design principles saves time for both HR and CS.
- SHRM research found that strong employee onboarding improves new hire retention by 82% and productivity by 70%, but most companies still run it as a series of manual emails and calendar invites.
- Employee and client onboarding share the same failure modes: inconsistent handoffs, missing access provisioning, and no system that tracks whether the 60-day milestone happened.
- A well-designed onboarding automation runs for 90 days without requiring manual intervention: triggered at day 0, with scheduled check-ins and escalations built into the sequence.
- The three systems that onboarding automation must connect are: your HRIS or CRM (source of truth for the person), your ticketing or task system (owns the action items), and Slack (the communication layer).
- Use onboarding workflow automation to design the full sequence before picking the tools that implement it.
Employee and client onboarding share the same structural problem
When a new employee joins, HR sends a welcome email, IT gets a request to set up accounts, the manager sets up a first-week calendar, someone adds the person to the right Slack channels, and three different people follow up over the first month with varying levels of consistency. When a new client signs, the sales-to-CS handoff happens in Slack or email, the CS manager creates a project in whatever project tool they use, sends a kickoff invite, and builds a success plan that may or may not get shared with the client in a consistent format.
These two processes look different on the surface. They're run by different teams, for different purposes, using different systems. But they share the same structural failure mode: they're sequences of dependent steps where each step relies on a person remembering to trigger the next one. When that person is busy, the sequence delays. When they leave the company, the process knowledge goes with them.
The design principle for fixing both is the same: define the sequence once, trigger it from a system event, and let the automation handle the scheduling, communications, and escalations. The people involved are decision points in the workflow, not the engine that drives it.
According to SHRM research, companies with structured onboarding programs improve new hire retention by 82% and productivity by more than 70%. The bottleneck isn't the content of the onboarding, it's the consistency of delivery. Onboarding automation makes consistency the default rather than a function of whoever happens to be running the sequence that week.
The employee onboarding sequence: day 0 to day 90
A fully automated employee onboarding sequence is triggered when a new hire record is created in the HRIS (or when a hire is marked as confirmed in your ATS). From that trigger, the sequence runs on a schedule through the first 90 days: with human decision points built in where they're genuinely needed, and automation handling everything else.
Pre-boarding (day −7 to day 0). The week before the new hire starts, automation handles the access provisioning requests: a ticket is created for IT to provision accounts (or the provisioning itself runs automatically if your identity provider is connected), the new hire receives a welcome email with first-day logistics, the manager receives a pre-boarding checklist, and the relevant Slack channels add the new hire to their member list. None of this requires a human to remember to do it: the trigger fires, and the actions run.
Week one (day 1–5). On day 1, the new hire's Slack onboarding bot delivers a structured welcome message with links to key resources, their first-week agenda, and a list of the people they should meet. On day 3, an automated check-in asks whether access to all required tools is working. On day 5, the manager receives a reminder to complete the end-of-week conversation and log any blockers in the HRIS.
30-day checkpoint. An automated survey goes to both the new hire and their manager at day 28: timed to arrive before the 30-day conversation, not during it. The survey asks structured questions: is the new hire clear on their priorities? Do they have what they need? Are there blockers that haven't been surfaced? The responses are compiled automatically and shared with both parties before the 30-day meeting, so the conversation starts with data rather than starting from scratch.
60-day checkpoint. Same pattern. The automation asks whether the new hire has completed their required training, has been introduced to their key stakeholders, and has clarity on their 90-day goals. Any incomplete items generate a follow-up task in the project or ticketing system assigned to the relevant owner: manager, HR, or IT depending on the item.
90-day close. At day 88, the automation triggers the final onboarding review: a summary of what was completed, what was delayed, and any open items from the sequence. This becomes the new hire's first performance documentation and the transition point from onboarding to business-as-usual management.
| Phase | Trigger | Automated actions | Human decision point |
|---|---|---|---|
| Pre-boarding | Hire confirmed in HRIS/ATS | Provision accounts, send welcome email, Slack channel adds | Manager approves access level |
| Week 1 | Start date | Welcome Slack bot, day 3 access check-in, day 5 manager reminder | Manager logs blockers |
| Day 30 | Day 28 schedule | Survey to hire + manager, compiled responses delivered before meeting | 30-day conversation |
| Day 60 | Day 58 schedule | Training completion check, stakeholder intro audit, blocker tasks | 60-day review |
| Day 90 | Day 88 schedule | Onboarding summary generated, open items compiled | 90-day close conversation |
The client onboarding sequence: deal close to first renewal
Client onboarding has the same 30-60-90 structure but different content and different system touchpoints. The trigger is a deal moving to closed-won in the CRM, and the sequence runs through the first 90 days of the client relationship.
Handoff and kickoff (day 0–7). When the deal closes, an AI agent reads the CRM record (deal notes, contract details, stakeholder list, stated use case) and generates a structured handoff brief for the CS team. This brief is posted to a dedicated Slack channel and attached to the account record in the CRM. The CS manager receives a kickoff checklist: schedule kickoff call, share onboarding roadmap, complete technical setup. The client receives a welcome email with their dedicated CS contact, the first-call scheduling link, and what to expect in the first 30 days.
30-day business review setup. At day 25, automation prepares the 30-day business review: it pulls usage data from the product (if available), compiles any support tickets, and generates a progress summary against the initial goals stated at kickoff. This gives the CS manager a factual starting point for the conversation rather than relying on memory of what was discussed at kickoff five weeks ago.
60-day health check. The automation calculates a simple health score at day 55: product engagement (logins, feature adoption), support ticket volume and resolution time, open implementation items from the kickoff, and whether the primary stakeholder has been responsive. A low health score triggers a proactive Slack alert to the CS manager, not a crisis, but an early flag that warrants a check-in before the 60-day call.
90-day close and renewal setup. At day 85, the automation generates the 90-day review package: a summary of what was accomplished, product adoption metrics, open items, and a pre-draft renewal conversation outline. For accounts on an annual contract, this is also the trigger for the first renewal outreach: timed to start 9–10 months before renewal rather than 30 days before. Starting the renewal conversation from the context of a strong 90-day close is a fundamentally different conversation than starting it cold at 11 months.
Describe your onboarding process (employee, client, or both) and get a structured automation spec for the full 90-day sequence.
What both sequences share, and why that matters for the build
Building employee and client onboarding automation in parallel is more efficient than building them separately, because they share the same underlying design principles:
- A single trigger event. Both sequences start from a system event: HRIS record creation for employees, CRM deal close for clients. The trigger is clean and binary; it either happened or it didn't.
- A scheduled sequence with human decision points. Both sequences run on a calendar: day 0, day 1, day 5, day 28, and so on. The automation handles the scheduling; humans handle the conversations that the schedule produces.
- A compiled document at each milestone. Both sequences benefit from AI-generated summaries at each checkpoint: the automated survey compilation for employees, the health score and progress summary for clients. These replace the "let me just remember what we talked about last time" conversations with factual briefings.
- Escalation logic for the things that fall through the cracks. Both sequences need a rule: if X hasn't happened by day Y, alert Z. Access not provisioned by day 1? Alert IT. Client hasn't logged in 14 days into their subscription? Alert CS. The approval and escalation workflows are the safety net that makes the sequence reliable rather than aspirational.
The practical benefit of building both at once: you design the trigger-and-sequence architecture once, the scheduled task system once, and the Slack notification templates once. Implementing the second sequence after the first is mostly content work, not infrastructure work.
Building the automation: what connects to what
The three systems that onboarding automation must connect are: the source-of-truth system (HRIS for employees, CRM for clients), the task system (where action items live and track completion), and the communication layer (Slack, email, or both). Everything else is content that flows between these three.
For employee onboarding, the HRIS (Bamboo, Workday, Rippling) fires the trigger. HR operations automation tools like these have native workflow capabilities that can handle the pre-boarding and week-one steps without requiring an external automation layer. The milestone surveys and 30-60-90 document generation are where an AI-connected workflow adds value on top of what the HRIS can do natively.
For client onboarding, Salesforce or HubSpot fires the trigger at deal close. The CS-facing task system (Asana, Notion, or a dedicated CS platform like Gainsight) receives the handoff checklist. Slack handles the internal alerts and escalations. The AI generation step (the handoff brief, the health summary, the renewal outline) runs via BYOBot's build output, which produces the prompt design for each generation task as part of the overall onboarding spec.
The most common build mistake is trying to connect too many systems at once. Start with the trigger, the first three steps, and the Slack notification. Run that for two weeks and validate it before adding the 30-day milestone layer. The sequence will be more reliable if it's built incrementally than if it's built all at once and tested for the first time in production.
Frequently Asked
Role-based access templates are the cleanest approach. Define the standard access package for each role before automating: which tools, which permission levels, which Slack channels, which training paths. When a new hire enters the workflow, their role triggers the relevant template. This handles 80–90% of hires. The edge cases (a senior hire needing elevated access, or a contractor with a narrower scope) are handled by a manual override step where the hiring manager or IT owner can modify the template before provisioning runs. For teams using Slack for the communication layer, Slack workflow automation covers the channel management and notification steps in detail.
The handoff from sales to CS. This is where the context built during the sales process (the client's goals, the commitments made, the timeline agreed) needs to transfer to the team delivering it. When this handoff is manual, it's inconsistent. Automating the generation of a structured handoff brief at deal close (using CRM data, sales stage notes, and contract details) creates a consistent first document every time. BYOBot's build output for this workflow generates the prompt design for the handoff brief as part of the onboarding automation spec. See also the full onboarding workflow automation guide for the end-to-end sequence.
Both, and they serve different purposes. The automated check-ins (a scheduled survey or structured Slack message at day 30, 60, and 90) are operational: is the person set up? Are they blocked? Do they have what they need? These should be automated because they need to happen consistently regardless of how busy the manager or CS team is. The human-led conversations are strategic: how is the person doing in context? Where do they need support beyond a checklist? The automation creates the conditions for the human conversation to be more focused: you're not spending the 30-day check-in on logistics, you're using the automated data to understand what's going on.
