Designing a Hire-to-Onboard Workflow

Welcome back. In the previous lesson, you connected the company’s weekly rhythm to metrics, decisions, and follow-up actions. Hiring belongs in that same operating system: opening a role affects budget and workload; choosing a candidate is a meaningful decision; and onboarding is a coordinated set of commitments rather than an informal welcome message.

This lesson completes the people-operations layer for your eight-person e-commerce company. You will build a lightweight Notion workflow that begins with an approved vacancy and ends with a new colleague who has the right role context, access, first-week plan, and accountable support. Notion will coordinate the work, while payroll, identity, and other specialist systems remain authoritative for sensitive records and actual account access.

---

Start with the business logic: a role is not a vacancy

The Role Directory from an earlier lesson describes the company’s ongoing design: what each role is responsible for, who it reports to, its recurring outputs, and its backup coverage.

A vacancy is a temporary request to fill one of those roles. It answers a different question:

Do we need permission to spend money and time to fill this role now?

For example, your company may already have a defined Customer Experience Associate role. But opening a vacancy for it still requires a decision: perhaps support volume has risen, the current employee is leaving, or the company wants weekend coverage.

Keep these two records distinct:

Record	Meaning	Typical owner	When it changes
Role	An enduring job design: purpose, manager, responsibilities, expected outputs, backup	Founder or functional lead	When company structure or responsibilities change
Vacancy	A request to hire one person into an approved role, with a business reason and timing	Hiring manager	When a role needs to be filled, paused, cancelled, or filled
Candidate	A person being considered for one vacancy	Hiring manager or People & Operations owner	As they move through hiring stages
Onboarding plan	A coordinated plan to prepare and support one accepted hire	Hiring manager	After offer acceptance through the first week

This distinction prevents a common Notion-system failure: one “Hiring” database that mixes job descriptions, applicants, hiring approvals, interview notes, signed offers, and onboarding tasks in a single page. It becomes difficult to see what is actually waiting for a decision.

For a company of this size, use a simple approval rule:

• A replacement hire within an already approved budget may be approved by the Founder/GM.
• A new or additional role should first be added to the Role Directory and approved as part of the company structure, then receive vacancy approval.
• The hiring manager drives the request and process; they should not silently approve their own new headcount.

The requisition flowchart below shows the essential control: the hiring manager requests the vacancy, the appropriate manager approves or rejects it, and only approved requests move into candidate search.

For your company, replace “General Manager” with the real approver from your Decision Rights Catalog. That may be the Founder, GM, or budget owner. The important point is that the person who needs a hire is not automatically the person allowed to commit the company to payroll cost.

---

Build a linked hiring model, not one large hiring page

Create a private People Operations area in Notion. This should be accessible only to the people who genuinely need hiring information, such as the Founder/GM, hiring manager, and People & Operations owner.

Do not treat a filtered view as security. A view that hides salary, candidate contact details, or interview notes from most people is still based on a database they may be able to access. Keep sensitive databases in an appropriately restricted teamspace from the beginning. You will design the full permission model later in the course.

Also keep the source-of-truth boundaries clear:

• Notion is the workflow and management record: requisition status, interview responsibilities, decision evidence, onboarding coordination, and task completion.
• An ATS or recruiting inbox may be the authoritative location for applications and candidate correspondence.
• Your HR/payroll system is authoritative for employment contracts, tax forms, bank details, legal name, home address, and payroll setup.
• Your identity provider or application admin console is authoritative for whether an account actually exists and what access it has.

Never put passwords, identity-document images, banking details, tax forms, or broad personal background notes in Notion.

1. Create the Vacancies database

Each vacancy is one approved attempt to fill one role. Create a database called Vacancies and connect it to your existing Roles, People, and Decision Log databases.

Property	Type	Purpose
Vacancy title	Title	Example: “VAC-2026-04 — Customer Experience Associate”
Role	Relation to Roles, one record	The role being filled; required
Hiring manager	Relation to People, one record	Owns the need and day-to-day hiring process
Vacancy type	Select	Replacement, Growth hire, Temporary/contract
Business reason	Text or page content	The demand, capability gap, or replacement rationale
Target start date	Date	A planning target, not a promise to candidates
Employment arrangement	Select	Full-time, Part-time, Contractor; tailor to your business
Status	Select	Draft, Awaiting approval, Approved, Sourcing, Interviewing, Offer pending, Filled, Paused, Cancelled
Approval decision	Relation to Decision Log	The formal approval instance
Approver	Relation to People, one record	The person with authority to approve this vacancy
Candidates	Relation to Candidates	All candidates considered
Hiring stages	Relation to Hiring Stages	The interview plan for this vacancy
Selected candidate	Relation to Candidates, one record	Filled only after acceptance
Onboarding plan	Relation to Onboarding Plans	Created after acceptance
Restricted offer reference	URL or text	Link to the approved offer record in the appropriate restricted system

Make the Role, Hiring manager, Business reason, Target start date, and Approver required in your Vacancy template. A vague request such as “Need another person for support” is not enough to make a good hiring decision.

2. Use your existing decision framework for approval

You already built a Decision Rights Catalog and Decision Log. Add a decision type such as Open vacancy to the catalog.

For a growth hire, the decision record might look like this:

Decision-right field	Example
Decision	Approve a Customer Experience Associate vacancy
Driver	Customer Experience Lead
Approver	Founder / GM
Contributors	Operations & Finance Manager, Fulfillment Lead
Evidence	Open-case volume, response-time performance, projected payroll cost, seasonal demand
Decision outcome	Approved for a part-time hire starting before the holiday campaign
Linked vacancy	VAC-2026-04

The vacancy remains Awaiting approval until the Decision Log records an outcome. Do not let a “Yes” in a chat message become the only record of a payroll commitment.

3. Create a minimal Candidates database

Use one Candidate record per person per vacancy. At your current scale, a candidate who applies for two distinct roles can have two records, each connected to the relevant vacancy. This keeps the evaluation tied to the actual job being considered.

Property	Type	Purpose
Candidate reference	Title	Use a clear name only in the restricted workspace
Vacancy	Relation to Vacancies, one record	Which approved role they are being considered for
Current stage	Select	Applied, Screen, Work sample, Hiring manager interview, Team interview, Decision pending, Offer, Hired, Rejected, Withdrawn
Process owner	Relation to People, one record	Keeps communication and progress moving
Application source	Select	Referral, careers page, agency, direct outreach, other
Candidate-system link	URL	Link to the application or ATS record
Interview evaluations	Relation to Interview Evaluations	Evidence from each completed stage
Recommendation	Select	Advance, Hold, Do not advance, Finalist
Final decision	Relation to Decision Log	The hire/no-hire decision for a finalist
Offer status	Select	Not applicable, Preparing, Sent, Accepted, Declined, Expired
Proposed start date	Date	Populate only after acceptance

A candidate’s Current stage is a coordination signal. It is not the evidence behind a decision. That evidence belongs in structured interview evaluations.

---

Make each interview stage purposeful and owned

Small companies often make two opposite mistakes:

1. Everyone casually interviews the candidate, asking overlapping questions.
2. One manager makes a decision from instinct after an unstructured conversation.

A lightweight middle ground is to decide, before sourcing begins:

• What must this person be able to do?
• Which stage tests each capability?
• Who owns that stage?
• What evidence should they record?
• Who makes the final hiring decision?

For a Customer Experience Associate, do not use a generic “culture fit” interview. You need evidence relevant to the role: clear customer writing, calm judgment under an escalation, ability to learn product information, comfort with e-commerce tools, and reliable handoffs to fulfillment.

Create a Hiring Stages database

A Hiring Stage is a planned step for one vacancy, not an individual candidate’s result. Create a new record from a template whenever a vacancy becomes approved.

Property	Type	Purpose
Stage	Title	Example: “Customer Experience Associate — Team interview”
Vacancy	Relation to Vacancies	The hiring process this stage belongs to
Sequence	Number	The intended order
Stage type	Select	Screen, Work sample, Hiring manager interview, Team interview, Reference check, Final decision
Purpose	Text	What this stage is meant to learn
Responsible interviewer	Relation to People	One person accountable for running it
Additional interviewers	Relation to People	Include only people with a defined contribution
Evaluation criteria	Text or page content	The questions and evidence expected
Required	Checkbox	Whether a candidate must complete it to be considered
Evaluation records	Relation to Interview Evaluations	Completed candidate-stage evaluations

For a small company, use no more than three or four genuine assessment stages for most roles. An appropriate plan for the Customer Experience Associate might be:

Sequence	Stage	Owner	What it establishes
1	Initial screen	People & Operations owner	Availability, practical requirements, relevant experience, candidate questions
2	Short written customer-response exercise	Customer Experience Lead	Clarity, tone, reasoning, and escalation judgment
3	Hiring-manager interview	Customer Experience Lead	Role-specific experience, working approach, expectations
4	Cross-functional conversation	Fulfillment & Inventory Lead	Quality of handoffs, understanding of delivery and stock problems
5	Final decision	Founder/GM	Confirmation of evidence, constraints, and hiring decision

Do not create a work sample simply because it sounds rigorous. Use it only if it resembles real job work, is reasonable in size, and does not produce unpaid work that the business will use. Local employment laws vary, so obtain appropriate local advice when setting hiring and pre-start practices.

Create the Interview Evaluations database

This database creates accountability after an interview. One record represents one candidate’s evaluation for one stage.

Property	Type	Purpose
Evaluation title	Title	Example: “Candidate A — Customer-response exercise”
Candidate	Relation to Candidates	The person evaluated
Hiring stage	Relation to Hiring Stages	The planned stage and its purpose
Interviewer	Relation to People, one record	The person submitting this evaluation
Interview date	Date	When the interaction occurred
Status	Select	Scheduled, Completed, Scorecard due, Submitted, Cancelled
Evidence and notes	Page content	Role-relevant observations and examples
Criteria ratings	Number/select fields or page content	Ratings against defined criteria
Recommendation	Select	Advance, Hold, Do not advance
Concerns to test	Text	Specific unresolved questions for the next stage
Submitted date	Date	Enables a view for missing feedback

Use a scorecard template inside each evaluation page:

## Evidence against the role criteria

### Criterion 1: [for example, clear written customer communication]
Evidence:
Rating:
Reason for rating:

### Criterion 2: [for example, judgment in an order-delay escalation]
Evidence:
Rating:
Reason for rating:

### Criterion 3: [for example, cross-team handoffs]
Evidence:
Rating:
Reason for rating:

## Recommendation

- [Advance / Hold / Do not advance]
- Evidence supporting this recommendation:
- Specific question the next stage should test:

The rule is simple: record observable evidence, not labels.

“Candidate explained how they would verify carrier status before promising a delivery date, then described when they would escalate a stock discrepancy” is useful evidence.

“Great personality,” “not our type,” or “seems too quiet” is not useful evidence. It also risks turning preference or bias into a hiring criterion.

---

Turn the final choice into a recorded hiring decision

When a finalist completes the required stages, the hiring manager should summarize the evidence and open a Hire candidate decision in your existing Decision Log.

The hiring manager is usually the Driver. The Founder/GM is often the Approver in a small company, because the decision commits the company to pay, management capacity, and access to systems. Other interviewers contribute evidence; they do not each have an independent veto unless your decision-right policy explicitly gives them one.

Add these relations to your Decision Log if you have not already done so:

New property	Type	Purpose
Decision type	Select	Include Hire candidate
Related vacancy	Relation to Vacancies	Which approved vacancy is being filled
Candidate	Relation to Candidates	The candidate under consideration
Evidence summary	Page content	Concise synthesis of scorecards, not copied interview transcripts
Offer approval status	Select	Not needed, Preparing, Approved, Sent, Accepted, Declined

A concise decision record could state:

Decision: Hire Candidate A for VAC-2026-04, Customer Experience Associate.
Evidence: Strong written exercise; demonstrated a disciplined approach to delivery-delay cases; cross-functional interviewer confirmed clear escalation thinking.
Known development need: Limited experience with the company’s helpdesk and inventory tools.
Mitigation: Include tool training and supervised ticket review in the first-week checklist.
Approver outcome: Approved, subject to accepted written offer and completion of required employment steps.

Notice the distinction: a development need is not automatically a rejection reason. It may become a specific onboarding responsibility.

Keep compensation, contracts, required employment documents, and sensitive offer details in the restricted HR/payroll process. In Notion, record only what the wider workflow needs: whether the offer has been approved, sent, accepted, declined, and the intended start date.

---

Make onboarding a role-based handoff

Offer acceptance is the point where recruiting becomes an operations workflow. The company is no longer deciding whether to hire; it is preparing the person to do useful work safely and confidently.

The most reliable design has two connected parts:

1. A role-level access and onboarding template, defined once.
2. A person-specific onboarding plan, created for each accepted hire.

Add onboarding relationships to the Role Directory

Extend each Role record with:

Property	Type	Purpose
Default access requirements	Relation to Access Requirements	The systems and access levels normally needed for this role
Default onboarding template	Relation to Onboarding Task Templates	The standard first-week tasks for the role
Onboarding owner	Relation to People or Role	Usually the direct manager
Buddy role	Relation to Roles	A colleague who helps with practical questions
First-week success outcome	Text	What the new person should be able to do by Friday

For the Customer Experience Associate role, the first-week success outcome might be:

“Can independently resolve standard delivery-status and order-change cases using the support workflow, and knows when to escalate stock, carrier, refund, or product-quality issues.”

That is more useful than “Complete onboarding.” It describes a visible operating capability.

Create an Access Requirements database

An access requirement describes what a role normally needs. It is not proof that someone has actually been granted access.

Property	Type	Purpose
Access requirement	Title	Example: “Customer Experience Associate — Helpdesk standard access”
Role	Relation to Roles	The role that needs this access
System	Select or relation	Email suite, helpdesk, Notion, Shopify, inventory system, shared drive
Access level	Select	View, Standard user, Editor, Admin; tailor to the system
Business reason	Text	Why the role needs this access
System owner	Relation to People	Person responsible for granting or verifying access
Approval needed	Checkbox	Whether an additional owner must authorize it
Default	Checkbox	Whether it should be provisioned for every person in the role

A Customer Experience Associate may need standard access to the helpdesk, order lookup, approved customer-response documentation, and a limited view of relevant order information. They should not receive administrator access to the payment gateway simply because they may need to help a customer with a refund question.

This is the practical version of least privilege: give only the access required to do the role, at the lowest sensible level.

Create Onboarding Plans and Onboarding Tasks

Create an Onboarding Plans database. Each record represents one accepted hire’s coordinated first-week plan.

Property	Type	Purpose
Onboarding plan	Title	Example: “Candidate A — Customer Experience onboarding”
New hire	Relation to People	Create a restricted People record with status Pre-start after acceptance
Role	Relation to Roles	Pulls in the approved role context
Vacancy	Relation to Vacancies	Preserves the reason this hire exists
Hiring decision	Relation to Decision Log	Connects acceptance to the approved decision
Manager	Relation to People	Accountable for role integration
Buddy	Relation to People	Day-to-day practical support
Start date	Date	Drives due dates
Status	Select	Preparing, Pre-start ready, Week one active, Complete, Blocked
Access tasks	Relation to Onboarding Tasks	Provisioning and verification work
First-week tasks	Relation to Onboarding Tasks	Role, people, and workflow integration work
Readiness check	Formula or select	Ready, At risk, Blocked

Then create Onboarding Tasks. Use this database temporarily for onboarding-specific work; in the next module, you will build a company-wide task system and can connect or migrate these records without losing their relations.

Property	Type	Purpose
Task	Title	A verifiable action
Onboarding plan	Relation to Onboarding Plans	The person and start date it supports
Task category	Select	Access, Equipment, HR/payroll, Welcome, Role training, First-week outcome
Owner	Relation to People, one record	The person accountable for completion
Due date	Date	Usually relative to the start date
Status	Select	Not started, In progress, Waiting, Done, Not applicable
Access requirement	Relation to Access Requirements	Use for access-related tasks
Completion evidence	Text or URL	Confirmation, ticket link, or short note
Blocked reason	Text	What is preventing completion

For every accepted hire, create tasks from the role’s access requirements and default onboarding template. This can be done manually with a Notion template at first. Because hiring is infrequent in a small company, a consistent manual process is better than a fragile automation.

The video below demonstrates why onboarding preparation should include account provisioning, a clear task list, and eventual offboarding controls—not merely an orientation meeting.

---

Use a first-week checklist that creates operating capability

A good first-week checklist has multiple owners. The manager should not be expected to set up email accounts; the system owner should not be expected to teach the role’s customer-service judgment.

For a new Customer Experience Associate, create a Customer Experience first-week template with tasks such as these:

Timing	Task	Owner	Completion evidence
Before start	Confirm employment and payroll setup in the HR/payroll system	People & Operations owner	Restricted system confirmation
Before start	Create company email and helpdesk access at the approved level	System owner	Account active and access tested
Before start	Prepare device, workspace, or remote-equipment delivery	Operations owner	Equipment received or ready
Before start	Send first-day agenda and introduce buddy	Hiring manager	Calendar invitation and message sent
Day 1	Welcome, team introductions, role purpose, and reporting line	Hiring manager	Meeting completed
Day 1	Review company handbook, policies, and required agreements	People & Operations owner	Required acknowledgement completed in the correct system
Day 1	Explain the order-to-support operating flow and escalation paths	Customer Experience Lead	New hire can identify the right escalation owner
Days 2–3	Read and practice the support SOPs for delivery delays, address changes, refunds, and stockouts	Buddy and new hire	Guided case review completed
Days 3–4	Shadow real customer cases and draft responses for review	Buddy	Feedback recorded
Day 5	Handle a small set of standard cases under supervision	Customer Experience Lead	Quality check completed
Day 5	Hold first-week check-in against the role’s success outcome	Hiring manager	Next learning priorities recorded

A useful checklist task describes an outcome that can be checked. “Train on customer service” is vague. “Complete two supervised delayed-shipment cases using the documented escalation process” is observable.

Create one readiness view before the start date

On your People Operations home page, create a linked view called Starting Soon — Readiness:

• Filter Onboarding Plans to start dates within the next 14 days.
• Show only plans where Status is Preparing, Pre-start ready, or Blocked.
• Display open access tasks, equipment tasks, manager, buddy, and blocked reason.
• Sort by start date.

The manager should review this view at least several business days before a start date. If the hire begins Monday but cannot access email, the helpdesk, or the documented support process until Wednesday, that is not a new-hire failure; it is a failed company handoff.

Also create these practical operational views:

• Vacancies awaiting approval: Status is Awaiting approval.
• Interview scorecards due: Evaluation Status is Completed or Scorecard due.
• Finalists awaiting decision: Candidate stage is Decision pending.
• Offers awaiting response: Offer status is Sent.
• My onboarding tasks: Owner is the current person and task is not Done or Not applicable.
• Access at risk: Start date is approaching and an Access task remains open.

---

Build and test the workflow in one pass

Build this system in the following order:

1. Extend the existing Role Directory with default access requirements, onboarding template, onboarding owner, buddy role, and first-week success outcome.
2. Create Vacancies and link each vacancy to exactly one approved Role record and its approval decision.
3. Add Candidates, Hiring Stages, and Interview Evaluations so each stage has a purpose, owner, and evidence record.
4. Extend the Decision Log with related vacancy and candidate relations for final hire/no-hire decisions.
5. Create Access Requirements and define the least-privilege access profile for one role first.
6. Create Onboarding Plans and Onboarding Tasks, then build a role-specific onboarding template.
7. Create the six operational views above.
8. Test the workflow with one realistic scenario: the company approves a replacement Customer Experience Associate, selects a finalist, the offer is accepted, helpdesk access is delayed, and the manager must see and resolve the resulting readiness risk before day one.

Do not attempt to automate everything initially. First prove that each handoff has one clear owner, a visible due date, and completion evidence. Once the workflow works manually, automations can remove repetitive creation work without hiding accountability.

---

Key takeaways

A lightweight hire-to-onboard workflow makes hiring an accountable company process rather than a set of disconnected conversations.

• A Role defines an ongoing job; a Vacancy requests permission to fill it now.
• Every vacancy should link to an approved role, business reason, hiring manager, approver, and decision record.
• Hiring stages should have a specific purpose, named interviewer, and structured evidence—not overlapping informal conversations.
• Interview scorecards should document role-relevant facts and reasoning, not vague impressions or personal assumptions.
• The final hiring choice belongs in the existing Decision Log, linked to the candidate and vacancy.
• After offer acceptance, create a person-specific onboarding plan from the role’s access and first-week templates.
• Notion coordinates preparation and accountability; HR/payroll and access-management systems remain authoritative for sensitive personal data and actual permissions.
• A first-week checklist should produce a concrete ability to perform the role’s basic work, not merely a list of orientation activities.

You have now completed the foundational operating layer for the company: workflows, data ownership, roles, decision rights, cadence, and lightweight people operations. In the next module, you will begin coordinating longer-lived work by building a project portfolio that connects company initiatives to objectives, owners, timelines, status, and expected results.