Building a Notion Role Directory for Organizational Clarity

Hello again. Last time, you separated the company’s operational facts from its coordination work: Shopify or another store platform owns orders, the warehouse system owns physical stock, the payment gateway owns payment events, and Notion owns internal follow-up, decisions, and workflows.

Now we make ownership visible at the human level. A source-of-truth map can tell you that a fulfillment system is authoritative for dispatch events; the role directory answers who is expected to monitor those events, resolve exceptions, and ensure the work continues when that person is unavailable.

By the end of this lesson, you will have a Notion role directory for a realistic eight-person e-commerce company. It will show the org structure, reporting lines, responsibilities, recurring outputs, and practical backup coverage without confusing a role with a particular employee.

---

A role is an operating promise, not a person’s name

A role is the stable position the company needs. An employee is the person currently filling that role.

For example, Fulfillment & Inventory Lead is a role. “Jordan Lee” is its current incumbent. If Jordan changes jobs, takes leave, or moves internally, the company should not need to redesign its operating system. The role remains, its responsibilities remain, and the directory shows who covers it.

This distinction matters especially in a 5–10-person company, where one person may temporarily carry more than one role. “Maya handles everything marketing-related” may be true today, but it is not operationally clear. Does she own campaign planning, product listing quality, email performance, creative production, or all four? Which work can be handed off if demand grows?

A useful role directory makes five things explicit:

1. Purpose: Why does this role exist?
2. Reporting line: Which role provides direction, removes obstacles, and handles people-management escalation?
3. Responsibilities: Which ongoing areas of work does the role own?
4. Recurring outputs: What observable result should repeatedly appear, and how often?
5. Backup coverage: Who can keep essential work moving during absence, overload, or a vacancy?

The distinction between a role and its responsibilities is worth making precise before you build.

A responsibility is an ongoing area of ownership, such as “maintain accurate product listings” or “ensure paid orders are dispatched within the service target.” A task is a specific piece of work, such as “update the navy T-shirt size guide by Friday.” Your future task system will handle the latter; this directory defines the stable responsibility behind it.

Similarly, an output is evidence that a responsibility is being fulfilled. “Monitor fulfillment” is vague. “Daily paid-order exception review completed by 10:00, with delayed orders assigned” is an observable recurring output.

---

Keep the org structure simple—and separate it from workflow handoffs

In a small company, an org chart should be short. It shows line management, not every collaboration path.

For the eight-person e-commerce company used throughout this course, use this starting structure:

Role	Reports to	Primary purpose
Founder / General Manager	—	Sets direction, resolves major trade-offs, and maintains overall company health
E-commerce & Growth Lead	Founder / General Manager	Grows demand and maintains the storefront as a reliable sales channel
Content & Creative Specialist	E-commerce & Growth Lead	Produces approved product and campaign content
Customer Experience Lead	Founder / General Manager	Owns customer-service quality, case resolution, and customer insights
Customer Support Specialist	Customer Experience Lead	Resolves routine customer cases and records useful issue patterns
Fulfillment & Inventory Lead	Founder / General Manager	Keeps stock, purchasing, fulfillment, and delivery performance under control
Fulfillment Associate	Fulfillment & Inventory Lead	Carries out daily fulfillment work and flags physical exceptions quickly
Operations & Finance Manager	Founder / General Manager	Maintains operational control, cash visibility, expense discipline, and financial follow-up

This is deliberately not a departmental chart with many layers. The Founder has four functional leads; three specialist roles report to the lead closest to their day-to-day work.

The structure does not mean that work occurs only vertically. Consider a delayed shipment:

• The Fulfillment Associate notices the problem and records the operational facts.
• The Fulfillment & Inventory Lead owns resolution with the warehouse or carrier.
• The Customer Experience team communicates with the affected customer.
• The Operations & Finance Manager may be involved if compensation, a refund, or a material financial loss is needed.
• The Founder only needs to be involved if the issue is unusually costly, reputationally serious, or repeated.

Those are workflow handoffs, not reporting lines. Your Operating Flow Map from the first lesson shows the handoffs. The role directory shows the stable structure that supports them.

Do not copy a large-company org chart

Shopify’s overview of e-commerce jobs lists roles such as e-commerce manager, customer-service representative, marketing specialist, supply-chain manager, online merchandiser, designer, developer, and analyst. Those are useful capabilities, but a company with eight people cannot usually hire a separate specialist for every capability.

Instead, bundle related work deliberately:

Larger-company specialty	Eight-person company treatment
E-commerce manager and online merchandiser	E-commerce & Growth Lead
Marketing specialist, copywriter, and graphic designer	E-commerce & Growth Lead plus Content & Creative Specialist
Customer-service representative	Customer Experience Lead plus Customer Support Specialist
Supply-chain manager	Fulfillment & Inventory Lead
Business analyst and basic operations coordination	Operations & Finance Manager, with input from each functional lead
Developer, SEO specialist, or legal adviser	External specialist support when needed, not a permanent internal role by default

Bundling is acceptable. Invisible bundling is the problem. Your directory should state the responsibility explicitly so that capacity gaps become visible before they become missed orders or neglected customers.

---

Build a role directory that survives people changes

Create a top-level page called Company Directory. Inside it, create two databases:

1. Roles — canonical record of the work the company needs.
2. People — current employees or contractors and the role or roles they fill.

Keep the Roles database as the primary system. The People database is useful, but the company should still understand the role when no person is assigned to it.

Roles database: recommended properties

Property	Type	Purpose
Role name	Title	The stable role name, such as “Customer Experience Lead”
Role code	Text	Short reference, such as CX-LEAD or FUL-ASSOC
Role status	Select	Active, Planned, Vacant, or Retiring
Function	Select	Leadership, Growth, Customer Experience, Fulfillment, or Operations & Finance
Current incumbent	Relation to People	Person currently filling the role; leave empty if vacant
Reports to role	Self-relation to Roles	The designed line-management relationship
Direct reports	Reciprocal self-relation	Automatically shows roles reporting to this one
Role purpose	Text	One concise statement of why the role exists
Core processes	Relation to Operating Flow Map	The operating stages where this role has a meaningful ownership or contribution
Recurring outputs	Relation to Recurring Outputs	The repeated results expected from the role
Primary backup role	Self-relation to Roles	The role expected to cover standard work during absence
Coverage readiness	Select	Ready, Partial, Unready, or No viable backup
Coverage last tested	Date	When the backup arrangement was last checked in practice
Boundary / escalation note	Text	What the role does not decide or handle alone, and where it escalates
Role page review date	Date	Prevents the directory from becoming obsolete

Use a self-relation for both “Reports to role” and “Primary backup role.” That keeps the organization model inside one Roles database rather than duplicating role names as text.

A few design rules will keep the directory clean:

• Use role names, not employee names, in reporting and backup fields.
• Use a relation to the Operating Flow Map rather than writing “fulfillment” in several different ways.
• Keep the role purpose short enough to read in a database view.
• Put detailed responsibility notes and handoff guidance inside the role page itself.
• Treat a vacant role as a real record, not as a missing row. Vacancy is useful operating information.

People database: keep it minimal

The People database need not become an HR system yet. For now, use only:

Property	Purpose
Person name	Employee or contractor name
Employment status	Active, On leave, Contractor, or Departed
Primary role	Relation to Roles
Additional roles	Relation to Roles, only when temporary or intentional
Work contact	Work email or communication handle
Start date	Useful later for onboarding records
Notes	Keep non-sensitive operational notes only

Do not put salary, bank information, performance notes, medical information, or interview feedback in this general directory. Those belong in appropriately restricted HR or finance records, which you will design later.

---

Add a third database: Recurring Outputs

Responsibilities can sound clear while still producing no dependable rhythm. A recurring-output database makes the company’s expected operating cadence visible.

Create a database called Recurring Outputs with these properties:

Property	Type	Meaning
Output name	Title	The recurring result, not a vague activity
Owner role	Relation to Roles	The role accountable for making it happen
Cadence	Select	Daily, Weekly, Monthly, Quarterly, or Event-driven
Expected timing	Text or Date	For example, “Weekdays by 10:00” or “First business day of month”
Recipient / user	Text or Relation	Who uses this output
Definition of done	Text	What proves the output is complete
Evidence location	URL or Relation	Linked Notion view, report, file, or system page
Supporting SOP	Relation to SOPs, later	The standard procedure behind the output
Backup owner	Rollup or Text	The backup role available if the owner is absent
Status	Select	Active, Under review, or Retired

The important shift is from verbs to outcomes:

Too vague	Better recurring output
Manage customer service	Daily priority-case review, with every urgent case assigned and given a next action
Track inventory	Weekly replenishment view showing at-risk SKUs, owner, and proposed next action
Run marketing	Weekly campaign performance update with continue, adjust, or stop recommendation
Manage finances	Weekly payout and bank-deposit review, with unexplained differences recorded for investigation
Handle fulfillment	Daily paid-order exception review, including delays, stockouts, and address problems

Later in the course, many of these outputs will be generated by dashboards, task templates, and workflow views. Right now, you are defining what the organization must reliably produce.

---

Populate the eight role pages

Create the eight active role records from the org structure. Then use the following starter content inside each role page. You are not trying to write a legal job description; you are creating an operational reference for a small team.

Role	Core responsibilities	Example recurring outputs	Primary backup role
Founder / General Manager	Set company priorities; resolve major cross-functional trade-offs; review company health and risks	Weekly company priorities; weekly management review notes and follow-up	No full substitute; Operations & Finance Manager can coordinate routine continuity
E-commerce & Growth Lead	Own storefront trading; maintain product listing quality; plan campaigns; monitor demand and conversion	Weekly trading and campaign plan; storefront issues list; campaign decision summary	Content & Creative Specialist for routine publishing and campaign continuity
Content & Creative Specialist	Produce product copy and creative assets; maintain approved brand assets; prepare content for publication	Weekly approved asset batch; product-content update list	E-commerce & Growth Lead
Customer Experience Lead	Set service standards; manage escalations; review customer themes; improve the support workflow	Daily priority-case review; weekly customer issue-themes summary	Customer Support Specialist for routine case operations
Customer Support Specialist	Resolve customer inquiries; document case facts; identify repeat problems; escalate urgent cases	Daily resolved-case and escalation update	Customer Experience Lead
Fulfillment & Inventory Lead	Control purchasing, inventory availability, order dispatch performance, supplier follow-up, and fulfillment exceptions	Daily order-exception review; weekly replenishment actions; supplier delivery status	Fulfillment Associate for standard warehouse coordination
Fulfillment Associate	Prepare and dispatch orders; check physical exceptions; record damaged goods and returns facts	Daily dispatch completion record; damaged/returned stock report	Fulfillment & Inventory Lead
Operations & Finance Manager	Coordinate operating controls; track expenses and cash timing; review payouts and bank deposits; maintain management reporting inputs	Weekly payout-status review; monthly expense and cash update	Founder / General Manager for limited operational escalation

The Founder’s backup is intentionally marked as No full substitute. A backup arrangement should not pretend that another employee can fully replace strategic leadership. Instead, document a continuity note: the Operations & Finance Manager can coordinate routine operations, while major commitments or strategic decisions are deferred or handled under a documented escalation plan.

Write strong responsibility statements

Within each role page, add these headings:

• Role purpose
• Responsible for
• Recurring outputs
• Key handoffs
• Boundary and escalation
• Backup coverage notes
• Systems and records used

For “Responsible for,” use short statements that describe an outcome and a boundary. For example:

Fulfillment & Inventory Lead is responsible for keeping sellable products available, ensuring paid orders are dispatched within the service target, and coordinating supplier and fulfillment exceptions. The role does not manually alter authoritative warehouse quantities in Notion; it investigates mismatches in the warehouse system and records the follow-up in Notion.

That final boundary connects directly to the source-of-truth logic from the previous lesson.

For “Key handoffs,” link to the relevant stages from your Operating Flow Map:

Role	Important handoffs to document
E-commerce & Growth Lead	Campaign demand forecast shared with Fulfillment & Inventory Lead before major promotions
Customer Experience Lead	Repeated delivery complaints turned into an operational issue for Fulfillment & Inventory
Fulfillment & Inventory Lead	Stockout risk shared with E-commerce & Growth before ads or promotions continue
Operations & Finance Manager	Payout or refund anomalies linked to the relevant payment and order references
Content & Creative Specialist	Approved assets handed to E-commerce & Growth for publishing and reuse

This is the point at which the Roles database becomes connected to the company’s actual operating flow, rather than being a static “About the team” page.

---

Make backup coverage real

A listed backup is not automatically useful. It is only credible if the backup person can perform standard work safely and can identify when to escalate.

For each role, record four things in the Backup coverage notes section:

1. Standard work covered: What can the backup do without waiting for the primary owner?
2. Escalation threshold: Which situations must be escalated immediately?
3. Required context: Which SOP, dashboard, queue, or source system must the backup consult?
4. Access confirmed: Does the backup have the appropriate operational access, or does an access owner need to provision it?

For instance, the Customer Support Specialist may cover the Customer Experience Lead’s normal priority-case review. But the specialist should escalate a legal threat, a suspected payment fraud case, or a high-value customer complaint according to the documented service policy.

Use the following readiness labels consistently:

Coverage readiness	Meaning
Ready	Backup has context, appropriate access, and has handled the standard process successfully
Partial	Backup can keep routine work moving but must escalate defined exceptions
Unready	A backup is named but has not been trained or lacks access
No viable backup	The company accepts a known single-point-of-failure risk and needs a continuity plan

Do not assign the Founder as the nominal backup for every role. That arrangement fails precisely when the company is busy or under pressure. If the backup is unable to spend time on the work, access the required system, or make the permitted routine judgment, the coverage is not real.

A practical first test is to have each primary owner take one normal recurring output and explain, in ten minutes, how their backup would complete it. Update Coverage readiness based on what actually happens, not what the team assumes.

---

Create views that make the directory useful

Because you already work comfortably with Notion databases and relations, focus on views that support an operating decision rather than on decorative layouts.

Create these linked views on the Company Directory page:

1. Organization view

Use a table or board grouped by Reports to role. Show:

• Role name
• Current incumbent
• Role status
• Function
• Primary backup role

This is the fastest view for noticing a vacant role, an overloaded manager, or unclear reporting.

2. Role coverage risks

Filter for roles where:

• Primary backup role is empty, or
• Coverage readiness is Unready, or
• Coverage readiness is No viable backup, or
• Coverage last tested is older than your chosen threshold.

For a young company, review this view monthly. It identifies operational fragility, not employee failure.

3. Recurring-output calendar

Create a calendar or timeline from Recurring Outputs. Display:

• Output name
• Owner role
• Cadence
• Expected timing
• Status

At first, you can use this as a reference schedule. In the next module, it will become more connected to meeting rhythms, projects, requests, and tasks.

4. Role-to-flow matrix

Create a linked view of your Operating Flow Map. Show each flow stage alongside its linked primary role and operational backup. This is a useful completeness check:

• Does every critical flow stage have a clear owner?
• Does any one role own too many time-sensitive stages?
• Does a handoff point have no obvious recipient?
• Does a recurring exception have a named role to resolve it?

---

A short build sequence for this lesson

Complete the work in this order:

1. Create Roles, People, and Recurring Outputs databases under Company Directory.
2. Add the core properties and relations, especially the self-relations for reporting lines and backup roles.
3. Enter the eight role records and their reporting structure before assigning named people.
4. Create at least two recurring outputs for each role, using outcome-based names.
5. Link each role to the relevant stages in the Operating Flow Map you created earlier.
6. Add a primary backup role and an honest coverage-readiness label for each essential role.
7. Build the Organization view and Role Coverage Risks view.
8. Review the directory with the company’s daily flow in mind; add a role, responsibility, or backup only where a genuine gap exists.

Avoid trying to make the directory complete by adding every imaginable responsibility. A good small-company directory is concise enough to be consulted during real work, but specific enough to prevent the recurring question: “I assumed someone else owned that.”

---

Key takeaways

Your role directory is the human layer of the company operating system:

• A role is a stable organizational position; a person is the current incumbent.
• Reporting lines show management and escalation structure, while the Operating Flow Map shows cross-team handoffs.
• Responsibilities define ongoing ownership; recurring outputs make that ownership observable.
• An eight-person e-commerce company can bundle specialist capabilities, provided the resulting responsibilities are explicit.
• A named backup is only meaningful when coverage, context, access, and escalation limits have been checked.
• The Roles database should connect to operating-flow stages, recurring outputs, and eventually SOPs, tasks, hiring, access, and dashboards.

In the next lesson, you will build on this directory to assign decision rights for recurring company decisions. That will clarify a different but related question: not just who does the work, but who recommends, approves, or needs to be consulted when a decision is required.