# The Company OS: five connected responsibilities

> Checked · 20 October 2026 · Wiki version 2026.10.20.2

Managing, Selling, Planning, Delivering, and Learning are operational concepts for seeing the same company picture. They are not an invented staff chart.

## Purpose
Make the responsibilities, records, tasks, and knowledge handovers understandable without needing to know internal implementation details.

## Diagram text alternative
Managing guides Selling, Planning, and Delivering. Delivering produces observations for Learning, and Learning informs Managing. Every area uses records, tasks, and knowledge.

## Current / proposed status
- Current: Checked — the five-area model and its responsibility descriptions are drawn from the approved handbook.
- Proposed: Use a named owner only when a current record or decision establishes one; the model alone does not assign people.

## Safe example
### From record to next action
A reservation is a record: it says something about a stay. “Confirm the cleaning evidence before the next arrival” is a task: it has a responsible person, due time, and verifiable outcome. The approved turnover procedure is knowledge: it explains how to do that task.

## Responsibilities
- Managing makes priorities, decisions, and review rhythm visible.
- Selling understands owner needs and property fit.
- Planning prepares commitments, finance, subscriptions, and projects.
- Delivering runs stays, turnover, maintenance, charges, and settlements.
- Learning maintains SOPs, incident understanding, reports, and shared knowledge.

## Checklist
- State which area owns the next decision, not just which screen displays it.
- Give every task a responsible person, due point, and verifiable outcome.
- Preserve a record’s identity and source rather than relying on a familiar display name.
- Link a learning item back to the incident, report, or repeated exception that prompted it.

<a id="operating-areas"></a>

## The areas are a shared map, not a staff chart

**Status:** Checked

Managing holds objectives, key results, decisions, meetings, and company rhythm. Selling covers owner relationships, leads, service catalogue work, and property intake. Planning handles finance, commitments, subscriptions, revenue planning, and projects.
Delivering covers reservations, turnover, cleaning, maintenance, charges, and settlements. Learning turns SOPs, incidents, reports, and company knowledge into a better next way of working. The names help a teammate ask the right question; they do not prove a particular person or team exists for each label.

**Current / proposed status**
- Current: Checked — these are documented operating responsibilities, not asserted job titles or reporting lines.
- Proposed: Assign a named owner in the relevant current task or decision record, then show the handover explicitly.

**Expected outcome**
Work can be routed by responsibility without inventing organisational facts.

**Meaningful tests**
- Check each area has a plain-language question and a linked diagram node.
- Review the page for wording that could be mistaken for an employment or reporting claim.

<a id="shared-objects"></a>

## Records, tasks, and knowledge answer different questions

**Status:** Checked

A record describes something that exists or occurred, such as a property, owner relationship, reservation, or subscription. Its identity and source matter. A task is an accountable next action with a responsible person, due time, and outcome another person can verify.
Knowledge is a reusable explanation: an SOP, incident lesson, report interpretation, or decision note. Keeping these separate prevents a record from being treated as an instruction, or an instruction from being treated as evidence that work happened.

**Current / proposed status**
- Current: Checked — the distinctions match the operating model in the handoff.
- Proposed: Add links between these objects at the handover: source record → task → accepted outcome → learning.

**Expected outcome**
A team member can tell whether they need to inspect a fact, perform an action, or follow a procedure.

**Meaningful tests**
- Check the example distinguishes a reservation record from a turnover task and SOP.
- Check the context export includes only this section’s prose when this section is selected.

<a id="handovers"></a>

## A handover is useful when it preserves both context and accountability

**Status:** Checked

A handover should identify the source record, what is known, the next decision or action, who owns it, when it matters, and what evidence closes it. “Please look at this” is not enough because it loses the decision boundary.
For example, Selling can hand a qualified owner enquiry to Planning with property identity and agreed next step. Planning can make a commitment visible to Delivering. Learning can turn a repeated exception into a reviewed SOP improvement.

**Current / proposed status**
- Current: Checked — this is a practical interpretation of the documented areas and shared records.
- Proposed: Use a clear exception owner when a handover cannot be completed with the available evidence.

**Expected outcome**
The next person receives a specific, supported action instead of a vague transfer of responsibility.

**Meaningful tests**
- Check handover examples name a source, action, and expected evidence.
- Check related links lead to lifecycle and learning pages rather than an unscoped technical guide.

## Related pages
- [Property lifecycle: from enquiry to review](/workflows/property-lifecycle/) — A property service lifecycle connects owner needs, identity, stays, readiness, settlement, and learning. It is a model to validate, not a claim that every handover is automated.
- [SOP learning: turn observations into a better next step](/workflows/sop-learning/) — Learning connects incidents, reports, and repeated exceptions to a reviewed procedure. It prevents a useful lesson from being stranded in a one-off conversation.
- [Dashboard and passive TV: shared views, not source authority](/systems/dashboard-and-tv/) — The staff dashboard and passive TV surfaces make a shared operating picture visible. They consume projections; they do not become the authoritative writer for company state.

## Source pointers
- Handoff / pages/organisation.html
- Handoff / START-HERE.html

## Context export
- Page context: ./exports/company-os.context.json