Design a week-one onboarding tutor new hires actually use

2026-07-07 · The Alltutors.ai team

The 30-60-90 doc answers questions nobody's asking yet

A new hire's first week usually starts with a document. Company handbook, tool list, org chart, a 30-60-90 template with boxes to check off. It's thorough, someone spent real time on it, and it gets read once, on day one, before any of it has context. By day three the new hire has a specific question, where does this ticket go, who actually owns this decision, what does this acronym mean in practice, and the doc doesn't take questions. So they ask their buddy, or their manager, or they sit on it and guess.

Gallup has measured the gap this leaves: only 12% of employees strongly agree their organization does a great job onboarding new hires (Gallup). That's not a company doing onboarding badly. That's most onboarding, everywhere, running into the same wall: a document can hand over information, but it can't hold a conversation, and starting a new job is mostly questions that only come up once you're actually in it.

What actually eats a manager's week

Ask any manager what onboarding costs them and they won't say "writing the doc." They'll say the follow-up. The same three questions from every new hire, in the same order, every single time someone joins. Where's the design system. Who approves a discount over $500. What's our actual process for a hotfix versus a normal release. None of that is a bad question. It's exactly what a new hire should be asking. It's also exactly the kind of thing that shouldn't require blocking on your manager's calendar to find out.

That's manager time spent narrating, not managing. And it happens once per hire, at exactly the moment the manager is also trying to get a new person ramped on real work. A hiring wave doesn't multiply the value of the doc. It multiplies the number of times someone re-explains the same five things out loud.

What a week-one tutor changes

The material doesn't change. Company handbook, tool walkthroughs, team norms, the org chart, whatever already exists to onboard someone, that's the input either way. What changes is the shape a new hire gets it in. Instead of a document to read start to finish, they get something to ask: "what's the deploy process again," "who do I go to for a design review," "walk me through the expense tool one more time." It answers in order, points back to the source policy when one exists, and doesn't get tired of the fourth person asking the same thing this month.

It also checks, which a document structurally can't. A quiz question or a quick follow-up after a section isn't there to gatekeep the new hire. It's there to catch the gap on day three instead of week six, when it shows up as a mistake in real work instead of a wrong answer in a tutor. Completion isn't competence covers why "they read the handbook" was never proof anyone absorbed it. The same logic applies here: a document that's been opened isn't a document that's been understood, and the only way to tell the difference is to ask.

Building it from what's already in someone's head

Most onboarding material already exists somewhere: a handbook, a wiki, an old slide deck from the last time someone ran a training. Feed that in and it grounds the tutor in your actual policies instead of generic advice. But the material that matters most for onboarding is usually the part nobody wrote down: the "ask Priya, she's been here six years and just knows" knowledge that lives in one person's head and nowhere else.

That's the case a written doc structurally can't solve, because writing it all down was the thing that never happened. If someone senior is leaving, or you're the only person who's answered the same onboarding question forty times, talk through what you know instead of trying to write a doc from scratch. The interview captures it as a conversation, the same way you'd explain it to the new hire directly, and shapes a tutor every future hire can ask, not just the ones who happened to sit near the right person.

What to load for a first week, and what to check

The first two rows are what a doc could technically cover. The tutor's edge there is that it answers on demand instead of once. The third and fourth rows are where a document was never going to be enough on its own, because "who to ask" and "did this actually land" aren't things a PDF can tell you.

What this doesn't replace

None of this is the argument that a new hire's first week should be a person less. The parts of onboarding that actually build belonging, a manager who checks in, a team lunch, someone noticing a new hire looks lost in a meeting and pulling them aside afterward, don't move to a tutor and shouldn't. Remote and hybrid onboarding already struggles to make someone feel welcome without the hallway version of that attention, and a chat window answering policy questions isn't going to fix that on its own.

What it does free up is time. A manager who isn't re-explaining the expense process for the fifth time this quarter has more of the week left for the parts that actually need a human: a real check-in, a conversation about how the first project is landing, the kind of attention that makes someone feel like they joined a team and not a checklist.

What to report back to the manager

The point isn't a tutor a new hire uses once in week one and forgets. It's a signal for the person who owns their ramp. Two things are worth watching, and they're different from each other: whether the new hire is moving through the material at all, and whether the checks along the way are landing. The first tells you they're engaged. The second tells you the onboarding itself is working, not just being read.

If a section's checks consistently come back weak across multiple new hires, that's not a signal about any one person. It's a signal that section needs a rewrite, the same way you'd revise a confusing paragraph in the handbook once three people asked about it. Our guide to rolling tutors out to a team covers how that data reaches a manager once you're onboarding more than one person at a time, roles, invites, and the analytics view itself.

Where to start

You don't need every policy finalized before you build this. Start with whatever already exists, handbook, tool docs, a recorded walkthrough, and add the tribal-knowledge interview for the parts nobody wrote down. The first version doesn't have to be complete. It has to be better than a document nobody asks anything back to.

Start building a week-one tutor from what you already have, or book a walkthrough if you're weighing this against a bigger onboarding rollout across the company.