This post. An illustrative worked example, not a client result. The services firm and every number are assumptions. It shows how an internal ops bot in Slack can route and approve access requests for new hires, with each action logged.
Assume a 40-person professional-services firm. The team, the process and the figures are assumptions for the walkthrough, not measurements from a client.
The old process is not broken because people are slow. It is broken because a new hire needs accounts, tool access, and equipment, and each request lives in a different inbox. The ops lead chases approvals by hand. For illustration, assume it takes about three business days from the start of day one to a working laptop.
#What eats the time in a manual onboarding?
Not the clicking. The waiting. A request for a GitHub seat sits until a manager sees the email. A request for the finance tool waits on a different approver. Nobody owns the handoff, so every step pauses at a person. The hands-on work is a small fraction of the elapsed time.
How does AI automate employee onboarding without becoming another chatbot?
It routes and approves, it does not just summarize. An ops bot reads each new-hire access request in Slack, checks it against a role-to-access map, then either approves low-risk items itself or routes higher-risk ones to the named owner with one-click approve. Every action is logged. The measure to watch is elapsed time from request to working access.
#So what does the design look like?
A bot that lives where the work already happens. When a hire is added, it opens one Slack thread per person. It reads the role, maps it to a defined access list, and moves each item. Accounts and low-risk tool seats it grants on rules the client set. Anything sensitive, like the finance system, it routes to the named owner with an approve or deny button.
- One thread per new hire, so the whole request is in one place, not five inboxes.
- Role-to-access map owned by the client, so the rules are theirs and auditable.
- One-click approve for the owner, so a decision takes seconds, not a day of email.
- An offboarding trigger that revokes the same access on a hire's last day.
The last item matters more than the onboarding speed. Revoking a departed hire's access is the step everyone forgets. In this design it fires from the same map that granted it, so offboarding is as reliable as onboarding, and missed revocations become something you can count.
We are
Stennir ships an approve-and-route ops bot that takes an action and logs it against a client-owned rule map.
We aren't
It is not a summary bot that reads a request and hands you a paragraph you still have to act on.
#How do you trust a bot to approve access?
You scope what it can decide. The bot auto-approves only the items the client marked low-risk in its own map. Everything else routes to a human with full context in the thread. Every grant, route, and revoke is logged. So the ops lead can answer who got access to what, and when, without opening five tools. That is the governance part, and we build it in from day one, not after.
Picture the first Monday it runs: a new analyst has a working laptop and every login before lunch, where that used to be a Wednesday problem. That is the outcome to design for and to measure, not a result we are reporting.
In a real engagement the code is owned by the client. It maps to the internal-ops-bot use case under AI implementation, and it is the same shape as the logistics and finance worked examples in the journal. Same pattern, different department: read the request, check the rule, take the action, log it.
If your onboarding is a stack of inboxes and a person doing the chasing, that is the exact shape this fixes. Tell us what you're building and we will tell you whether an ops bot is the right call or a two-line automation would do. tell us what you're building.
