Employee onboarding is one of those things that every company knows is important and few companies do well. New hires show up, get a laptop, sit through a few meetings, and then figure the rest out on their own. The documentation — when it exists — is either outdated, scattered across a dozen tools, or written for someone who already knows where everything is.
AI can help you create onboarding documentation that is actually useful: structured, specific, and written from the new hire's perspective rather than the company's. These patterns produce documents that answer the questions new employees actually have.
These five patterns cover the core onboarding documentation needs: welcome guides, role-specific training plans, process documentation, team introductions, and 30-60-90 day plans.
Pattern 1: The New Hire Welcome Guide
The welcome guide is the first document a new employee reads. It should answer immediate practical questions and set expectations for the first week.
The Template
code
You are an HR specialist creating a new hire welcome guide.
Company context:
- Company name: [name]
- Industry: [what you do]
- Company size: [approximate headcount]
- Work setup: [remote, hybrid, in-office — include location if relevant]
- Culture in a sentence: [how would an employee describe what it is like to work here]
New hire details:
- Department: [which team they are joining]
- Start date considerations: [anything special about their first day or week]
Create a welcome guide with:
1. Welcome message: A warm, genuine opening (3-4 sentences — not corporate boilerplate)
2. First day checklist: Everything they need to do on day one, in order, with specific instructions
- Where to go / how to log in (remote vs. in-person specifics)
- Systems to set up (list each tool with access instructions)
- People to meet on day one (name and role, or "your manager will introduce you to...")
3. First week overview: What each day of the first week looks like — specific enough to reduce anxiety
4. Key contacts: Who to reach out to for IT issues, HR questions, team questions, and general "I am lost" moments
5. Practical essentials:
- Communication norms (how the company uses Slack/email/meetings)
- Working hours expectations
- How to request time off
- Where to find key documents
6. Unwritten rules: 3-5 things that are not in any official policy but that every employee figures out eventually (e.g., "meetings start 2-3 minutes late — nobody will judge you for joining at 10:02")
Constraints:
- Write from the new hire's perspective — answer the questions they are actually thinking, not the ones HR thinks they should ask
- Be specific: "Set up Slack — download at slack.com, your workspace is [name].slack.com" not "Set up communication tools"
- Keep the tone welcoming but practical — not overly enthusiastic or corporate
- If I have not provided enough detail for a section, include placeholder text with [FILL IN] markers
- Total length: aim for a document that takes 10-15 minutes to readWhy It Works
The "unwritten rules" section is what separates a useful welcome guide from a generic HR document. Every company has norms that new hires learn through awkward trial and error — response time expectations, meeting culture, how decisions actually get made. Including these upfront accelerates the new hire's integration.
Example Output
For a 60-person remote SaaS company:
## Welcome to [Company Name]
>
You are joining a team of 60 people who build [product description]. We are remote-first, which means we have thought carefully about how to work well without an office — and we will help you get comfortable with that setup.
>
This guide covers everything you need for your first week. If something is missing or confusing, tell us — this document gets better every time a new hire points out what we forgot.
>
### Day One Checklist
>
Before your first meeting (do these in order):
1. Check your personal email for an invite from Google Workspace — accept it to activate your @[company].com email
2. Log in to Google Workspace and verify you can access Gmail, Calendar, and Drive
3. Download Slack (desktop app recommended) and join the workspace: [company].slack.com. Your account has been pre-created — sign in with your company email.
4. Say hello in #general — a simple "Hi, I'm [name], joining the [team] team today" is perfect. People will respond warmly.
5. Join your first meeting at [time] — your manager will send a Google Meet link. This is a casual welcome call, not a test.
>
Systems to set up today:
- Slack (primary communication — most things happen here)
- Notion (where documentation and project plans live — you will get a walkthrough)
- GitHub (if you are on the engineering team — your manager will assign access)
- [HR platform] (payroll, benefits, PTO requests — HR will send setup instructions)
>
People you will meet on day one:
- Your manager: [FILL IN] — welcome call at [time]
- Your onboarding buddy: [FILL IN] — this person is your "no question is too small" resource for the first month
- IT contact: [FILL IN] — if any setup goes wrong, message them in Slack
>
### First Week Overview
>
Monday: Setup, welcome call, onboarding buddy intro, Notion tour
Tuesday: Team standup (you will observe, not present), product walkthrough with [role]
Wednesday: Deep dive into your team's current projects — your manager walks you through what is in progress
Thursday: Self-guided product exploration — use the product as a customer would (your onboarding buddy will give you a sandbox account)
Friday: End-of-week check-in with your manager — how is it going, what questions do you have, what do you need
>
### Unwritten Rules
>
- Slack response time: For non-urgent messages, responding within a few hours is normal. Nobody expects instant replies. If something is urgent, people will say "urgent" or call.
- Cameras on meetings: Most people have cameras on during small team meetings and off during all-hands. Follow what others do.
- Asking questions: There is no penalty for asking questions, even basic ones. The team genuinely prefers a quick question over someone struggling silently for two hours.
- Documentation over memory: If you learn something that was not documented, add it to Notion. This is how our docs stay current — new hires are the best editors because they notice what is missing.
- Friday afternoons: Most people wind down after 3 PM on Fridays. Do not schedule meetings then unless it is truly necessary.
Pattern 2: The Role-Specific Training Plan
Beyond general onboarding, every role needs a training plan that takes a new hire from "just starting" to "fully productive." This pattern creates a structured ramp-up plan.
The Template
code
You are a learning and development specialist creating a role-specific training plan.
Role details:
- Job title: [title]
- Department: [team]
- Key responsibilities: [list the main things this person will do day-to-day]
- Tools and systems they need to learn: [specific software, platforms, or internal tools]
- Skills required: [technical and soft skills the role demands]
- What "fully productive" looks like: [what does success look like at 30, 60, and 90 days]
Team context:
- Who they will work with most: [collaborators, stakeholders]
- Existing documentation or training resources: [what already exists that they can use]
- Common mistakes new hires make in this role: [patterns you have seen]
Create a training plan with:
1. Week 1-2: Foundation
- What to learn (prioritized — most critical first)
- Activities (not just "read docs" — include hands-on tasks, shadowing, and practice)
- Checkpoint: How to verify the new hire is ready to move on
2. Week 3-4: Guided practice
- First real tasks with support (describe the type of work, not specific assignments)
- Who to shadow or pair with
- Checkpoint: What they should be able to do independently by end of week 4
3. Month 2: Increasing independence
- Types of work they should be handling with minimal oversight
- Areas where they should still seek review or guidance
- Checkpoint: Measurable indicators of progress
4. Month 3: Full integration
- Expected contribution level
- Remaining learning areas to develop over time
- Checkpoint: How manager and new hire assess readiness together
For each phase, also include:
- One potential pitfall and how to avoid it
- One conversation the manager should proactively initiate
Constraints:
- Be realistic about ramp-up time — do not overload the first two weeks
- Include relationship-building, not just task learning — meeting stakeholders and understanding team dynamics matter
- Each checkpoint should be specific enough that both the manager and new hire can agree on whether it has been met
- Account for the common mistakes you mentioned — build in safeguards
- Tone: supportive and structuredWhy It Works
The checkpoint system at each phase prevents the common problem of new hires who "seem fine" but are actually struggling silently. The pitfall-and-conversation prompts for each phase ensure the manager stays engaged in the onboarding rather than treating it as a self-guided process after day one.
Example Output
For a new customer success manager at a SaaS company:
### Week 1-2: Foundation
>
What to learn (in priority order):
1. The product — complete the internal product certification course and use the product as a customer would for at least 4 hours
2. Customer segments — review the customer segmentation doc to understand who our customers are and what they care about
3. CSM tools — learn to navigate the CRM, ticketing system, and health score dashboard
4. Team processes — understand the cadence (weekly team sync, monthly account reviews, quarterly business reviews)
>
Activities:
- Shadow 3-4 customer calls with a senior CSM — observe how they open calls, handle questions, and close with action items
- Complete the product certification quiz (target: 85% or higher)
- Set up your CRM views and health score dashboard with help from your onboarding buddy
- Have a 30-minute intro coffee chat (virtual or in-person) with each team member
>
Checkpoint: Can you explain our product's core value proposition in 2-3 sentences? Can you navigate the CRM to find key customer data without assistance? If yes, proceed to phase two.
>
Pitfall: Trying to learn every product feature in the first two weeks. Focus on the features your customer segment uses most — your manager can provide a priority list.
>
Manager conversation: At the end of week 2, ask: "What has been confusing so far that we could explain better?" This surfaces documentation gaps and misunderstandings early.
>
### Week 3-4: Guided Practice
>
First real tasks:
- Co-lead 2-3 customer calls with a senior CSM (you lead the agenda, they handle escalations)
- Draft your first customer health review for your assigned accounts — have a senior CSM review it before it goes to anyone
- Respond to 3-5 customer support tickets that have been pre-screened as straightforward
>
Checkpoint: Can you run a standard customer check-in call and document the outcomes without real-time support? Can you identify at-risk accounts in the health dashboard and explain why they are at risk?
>
Pitfall: Over-promising to customers. New CSMs often say "yes" to requests they are not sure the product can fulfill. When in doubt, say "Let me confirm that with my team and get back to you by [time]."
>
Manager conversation: Review the first customer calls together. Focus on what went well first, then discuss one specific area to improve for next time.
Pattern 3: The Process Documentation Template
New hires need to follow processes they have never seen before. This pattern creates process docs that are clear enough to follow on the first try.
The Template
code
You are a technical writer creating process documentation for internal use.
Process details:
- Process name: [what it is called]
- Purpose: [what this process accomplishes and why it exists]
- Who performs it: [which role or team]
- How often: [daily, weekly, per-event, etc.]
- Tools involved: [software, systems, or platforms used]
- Inputs: [what you need before you start]
- Outputs: [what the finished result looks like]
Document the process with:
1. Purpose statement: Why this process exists and what happens if it is not followed (2-3 sentences)
2. Prerequisites: What you need before starting (access, information, approvals)
3. Step-by-step instructions: Numbered steps with enough detail that someone doing this for the first time can follow without asking questions
- For each step that involves a tool, include the specific path or clicks (e.g., "In Salesforce, go to Reports > My Reports > Click 'New Report'")
- For each decision point, explain the criteria for each path
4. Common mistakes: 3-5 things people get wrong and how to avoid them
5. Troubleshooting: What to do when something goes wrong at each critical step
6. Who to ask: The right person to contact when this document does not cover your situation
Constraints:
- Write for someone who has never done this before — do not skip "obvious" steps
- Include screenshots placeholders [SCREENSHOT: description] where a visual would help
- Decision points should be clear — if the answer is "it depends," explain what it depends on
- Keep language simple — avoid internal jargon without defining it first
- Test the document mentally: could you follow it step by step without prior knowledge?Why It Works
The "never skip obvious steps" instruction addresses the biggest problem with internal process docs: they are written by people who already know the process. What is "obvious" to the author is invisible to the new hire. The troubleshooting section acknowledges that things go wrong and provides a safety net instead of leaving the new hire stranded.
Example Output
For a monthly expense report submission process:
## Monthly Expense Report Submission
>
Purpose: This process ensures all business expenses are documented, approved, and reimbursed within 10 business days. Submitting late or incomplete reports delays your reimbursement and creates problems for the finance team's monthly close.
>
Prerequisites:
- Access to Expensify (if you do not have access, message #it-help in Slack)
- Receipts for all expenses over $25 (digital photos are fine)
- Your manager's name (they are the default approver)
>
Steps:
>
1. Log in to Expensify at app.expensify.com using your company email
2. Click Create Report in the top right corner
3. Name the report: "[Your Name] — [Month Year]" (e.g., "Jane Smith — April 2026")
4. For each expense, click Add Expense and fill in:
- Date: When the expense occurred
- Merchant: The company or vendor name
- Amount: The total including tax and tip
- Category: Select from the dropdown. Common categories:
- Travel — flights, hotels, rideshare
- Meals — client meals, team meals (note who attended)
- Software — subscriptions or tools purchased for work
- If you are unsure which category, use "Other" and add a note — finance will reclassify it
- Receipt: Upload a photo or PDF. [SCREENSHOT: the receipt upload button location]
5. After adding all expenses, click Submit Report
6. Select your manager as the approver (their name should auto-populate)
7. Add a note if any expense needs explanation (e.g., "Client dinner with [name] from [company]")
8. Click Submit
>
Deadline: Reports are due by the 5th of the following month. Submit your April expenses by May 5th.
>
Common mistakes:
- Missing receipts: Expenses over $25 without receipts will be rejected. Take a photo of the receipt the day of the expense — chasing receipts later is miserable.
- Wrong category: Not a big deal — finance will reclassify. But choosing "Travel" for a software subscription slows down approval.
- Submitting expenses from a previous month in the current report: Keep each month's report separate. Do not bundle March and April expenses in one report.
>
Troubleshooting:
- "My manager is not showing as an approver": Your manager may not be set up in Expensify yet. Message #finance in Slack with your manager's name and they will fix it within a day.
- "I lost a receipt": For expenses under $75, a detailed written description of the expense (date, vendor, amount, purpose) is accepted as a substitute. Over $75 requires a receipt — contact the vendor for a duplicate.
>
Who to ask: For Expensify technical issues, message #it-help. For expense policy questions, message #finance. For approval delays, ask your manager directly.
Pattern 4: The Team Introduction Document
New hires need to know who their teammates are, what each person does, and who to go to for what. This pattern creates a team directory that is more useful than an org chart.
The Template
code
You are an onboarding specialist creating a team introduction document.
Team context:
- Team name: [name]
- Team purpose: [what this team does in the organization]
- Team size: [number of people]
- How the team works: [meeting cadence, communication style, collaboration tools]
Team members:
[For each member, provide: name, title, key responsibilities, and one relevant detail — how long they have been here, their specialty, or what new hires most often need from them]
Create a team introduction document with:
1. Team overview: What the team does, how it fits into the company, and the team's current focus (3-4 sentences)
2. For each team member:
- Name, title, and how long they have been on the team
- What they do in one sentence (their actual day-to-day, not their job description)
- When you would go to them: Specific scenarios where the new hire should reach out to this person
- Best way to reach them: Their preferred communication method (Slack DM, email, scheduled meeting)
3. Team working agreements: The norms the team follows (meeting expectations, response times, code review turnaround, etc.)
4. Helpful context: 2-3 things about the team's history or current priorities that help a new hire understand why things are the way they are
Constraints:
- "When you would go to them" should be scenario-based — "when you need to understand why a feature was built a certain way" not "for technical questions"
- Keep each person's entry to 3-4 lines — this is a quick reference, not a biography
- Include the team's current priorities so the new hire understands what they are walking into
- Tone: friendly and practical — like a colleague introducing you to everyone at a team lunchWhy It Works
The "when you would go to them" field is the most useful part. Org charts tell you reporting lines; this tells you who actually has the knowledge you need. The scenario-based framing helps new hires build a mental model of the team's expertise distribution, which dramatically reduces the time spent asking the wrong person.
Example Output
For an engineering team:
## Engineering Team — Your People Guide
>
The engineering team builds and maintains the core product. We are currently focused on the v3 platform migration and improving reliability. The team runs on two-week sprints with daily standups at 9:30 AM (15 minutes, cameras optional).
>
---
>
Sarah Chen — Senior Backend Engineer (3 years on team)
Day-to-day: Owns the API layer and database architecture. Currently leading the database migration for v3.
Go to Sarah when: You need to understand how the API is structured, why a certain database schema decision was made, or when you are debugging a performance issue on the backend.
Best way to reach: Slack DM. She checks messages between tasks and usually responds within an hour.
>
Marcus Rivera — Frontend Engineer (1 year on team)
Day-to-day: Builds the customer-facing dashboard UI. Works closely with the design team on new features.
Go to Marcus when: You need to understand the frontend component library, figure out how state management works, or pair on a UI bug.
Best way to reach: Slack in #frontend channel. He prefers questions in the channel so others can benefit from the answers.
>
Priya Patel — DevOps / Platform (2 years on team)
Day-to-day: Manages CI/CD pipeline, infrastructure, and monitoring. The person who gets paged at 3 AM.
Go to Priya when: You need access to a staging environment, your deployment is failing, or you want to understand how monitoring and alerts work.
Best way to reach: Slack DM for non-urgent. For deployment issues during a release, tag @priya in #deployments.
>
---
>
Team working agreements:
- Code reviews: Expect a review within 24 hours of opening a PR. If you need it faster, ask in #engineering.
- Standups: Share what you are working on and flag blockers. Keep it under 2 minutes per person.
- Deep work: Most of the team blocks 2-4 PM as focus time. Avoid scheduling meetings during this window unless necessary.
>
Helpful context:
- The team started the v3 migration six months ago. Some parts of the codebase are mid-transition, which means you will see v2 patterns and v3 patterns coexisting. Ask before refactoring — there is usually a reason something has not been migrated yet.
- The team adopted TypeScript last year. Older parts of the codebase are still in JavaScript and are being migrated incrementally.
Pattern 5: The 30-60-90 Day Plan
A 30-60-90 day plan gives both the new hire and their manager a shared roadmap for the first three months. This pattern creates a plan with clear milestones and accountability.
The Template
code
You are a people operations consultant creating a 30-60-90 day plan.
Role context:
- Job title: [title]
- Department: [team]
- Manager: [their title, not name]
- Key responsibilities: [the main outcomes this role is accountable for]
- Team expectations: [what the team needs from this person and when they need it]
- Known ramp-up challenges: [what usually takes longest to learn in this role]
Create a 30-60-90 day plan with:
**First 30 days — Learn:**
- Primary focus: Understanding the product, team, and processes
- 5-7 specific goals with clear success criteria
- Relationships to build (specific people or roles to meet and why)
- What to avoid: Things new hires should not try to do yet
- 30-day check-in agenda: Questions for the manager to ask, and questions the new hire should prepare
**Days 31-60 — Contribute:**
- Primary focus: Beginning to deliver real work with support
- 5-7 specific goals that build on month one
- Areas where they should start taking ownership
- Where they should still seek guidance before acting
- 60-day check-in agenda: Progress assessment and course corrections
**Days 61-90 — Own:**
- Primary focus: Operating at or near full capacity
- 5-7 specific goals that demonstrate independent contribution
- Stretch goal: One ambitious but achievable target
- 90-day check-in agenda: Formal assessment of onboarding success and discussion of longer-term development
Constraints:
- Goals must be specific and measurable — "understand the product" is not a goal, "complete the product certification and demo the core workflow to your manager" is a goal
- Each phase should build on the previous one — no goals in month 2 that require skills not covered in month 1
- Be realistic about what a new hire can accomplish — do not front-load critical deliverables in the first 30 days
- Include at least one relationship goal per phase — onboarding is about people, not just tasks
- Tone: clear, motivating, and honest about what is hardWhy It Works
The "what to avoid" section in the first 30 days is especially valuable. New hires often feel pressure to prove themselves immediately and take on work they are not yet equipped to handle. Explicitly stating what to wait on gives them permission to focus on learning without anxiety. The structured check-in agendas ensure the plan does not just exist on paper — it drives real conversations.
Example Output
For a new product manager:
## 30-60-90 Day Plan: Product Manager
>
### First 30 Days — Learn
>
Focus: Understand the product, the customers, and how the team works before forming opinions.
>
Goals:
1. Complete the product walkthrough and be able to demo the core user journey to your manager without notes
2. Read the last 3 months of customer feedback (support tickets, NPS comments, sales call notes) and identify the top 5 recurring themes
3. Attend 5 customer calls as an observer — take notes, do not present
4. Map the current product development process from idea to release — document it as you understand it
5. Have 1:1 meetings with every engineer on your team and at least 3 stakeholders from sales, support, and marketing
6. Review the current product roadmap and be able to explain the rationale behind each initiative
>
Relationships to build:
- Engineering lead — understand their priorities and constraints
- Head of Customer Success — understand what customers are struggling with
- Designer assigned to your team — understand the design process and current projects
>
What to avoid:
- Do not propose roadmap changes yet. You do not have enough context, and premature suggestions can undermine trust.
- Do not reorganize the backlog. Learn how the team prioritizes before suggesting changes.
>
30-day check-in agenda:
Manager asks: "What has surprised you about the product or the team? What do you think you understand well, and where are you still uncertain?"
New hire prepares: A summary of the top 5 customer themes and initial observations about the product development process.
>
### Days 31-60 — Contribute
>
Focus: Start making real contributions while continuing to learn the nuances.
>
Goals:
1. Write your first product spec for a small improvement — take it through the team's review process
2. Lead your first sprint planning session with engineering support
3. Present your customer feedback analysis to the team with 3 prioritized recommendations
4. Run one customer interview independently and share the findings
5. Identify one process improvement for how the team works — propose it to your manager before implementing
>
Take ownership of:
- Sprint planning and backlog grooming for your product area
- Writing specs for small to medium features
>
Seek guidance on:
- Anything that affects pricing, partnerships, or commitments to large customers
- Cross-team dependencies — your manager can help navigate internal politics
>
60-day check-in agenda:
Manager asks: "Where do you feel confident operating independently? Where do you still want support?"
New hire prepares: Self-assessment against these goals and a draft of their priorities for month three.
>
### Days 61-90 — Own
>
Focus: Operating as a fully contributing product manager.
>
Goals:
1. Own the product roadmap for your area and present it to the broader team
2. Lead a complete feature from spec through launch — including the go-to-market coordination
3. Build a regular cadence of customer conversations (at least 2 per month)
4. Deliver a data-informed recommendation on a significant product decision
5. Contribute to quarterly planning with a proposed set of priorities for next quarter
>
Stretch goal: Identify one opportunity — a feature, market, or improvement — that the team has not considered. Build a lightweight case for it.
>
90-day check-in agenda:
Manager asks: "How would you assess your first 90 days? What do you want to focus on developing over the next 6 months?"
New hire prepares: A self-assessment, their proposed priorities for next quarter, and any support or resources they need.
Quick Tips for Onboarding Documentation Prompts
- Write from the new hire's perspective. Every section should answer the question a new hire would actually ask, not the information HR wants to communicate.
- Include the messy reality. Perfect onboarding docs describe how things actually work, not how they are supposed to work. If the process has quirks, document them.
- Update after every new hire. Ask each new hire to note what was missing or confusing. Make those updates before the next hire starts.
- Keep documents short. A 20-page onboarding guide will not be read. Break it into separate, focused documents (welcome guide, training plan, process docs) that can be consumed individually.
- Make it findable. The best documentation is useless if the new hire cannot find it. Put everything in one place with a clear table of contents.
When to Use Templates vs. Freeform Prompts
Use these templates when you are building or overhauling your onboarding program and need consistent, structured documents. The patterns ensure completeness and make it easy to maintain the documents over time.
Go freeform when you need to handle a unique onboarding situation — a senior hire who needs a different ramp-up plan, a cross-team transfer, or a role that has never existed before. For those, use the CRAFT framework from our prompt writing guide to provide enough context for a tailored response.
For instant prompt generation without building templates manually, SurePrompts' AI Prompt Generator can structure your onboarding documentation requests automatically.