Organizing the work: structure and deliverables

12. Organization, teams and people

You come to this part to answer three questions: how my company is laid out in here, who works on what, and where the team's ground rules are agreed. It's three pages and one questionnaire.

Where these screens live

There is no "Settings" menu. The sidebar is a flat list of destinations, and each one is its own entry: Dashboard, Deliverables, Team Plans, Work Plans, Orion, Organization, Users, Teams, Grouping, Reports, Billing and My Profile.

The Users entry only shows up for people whose org role is Admin or HR. Anyone else never sees the people registry — not even the menu item.

The Organization page

This is where your company's identity lives. The page shows for Admin, HR and Audit; a regular member doesn't see it in the menu. Only the Admin edits — HR and Audit see it read-only.

Identity

official name, brand name and logo.

Location & tax

address, country and the tax document in the country's format (CNPJ in Brazil, EIN in the US, RFC in Mexico and so on). The currency is not chosen — it is set by the country.

Contact

website and LinkedIn.

Profile

company size, Consulting mode (turn it on for service firms that bill client work) and Team-level privacy.

People & ownership

the primary contact — the organization's representative for billing and legal notices, chosen from among the Admins — and the list of Admins. The roles themselves are set on each person's profile, not here.

Billing & subscription

plan and status, managed by the billing area.

The switch that changes day-to-day life the most is Team-level privacy. Off (the default), deliverables and deliverables plans are visible to the whole organization. On, a regular member only sees the deliverables and the deliverables plans of the teams they belong to. Admin, HR and Audit keep seeing everything in both cases.

Work plans follow a different rule, independent of this switch: a regular member always sees only their own plan, plus the plans of the teams they manage, assist or observe.

Teams

The Teams page has two panes: on the left the organization's hierarchy (with search and branches you can collapse), on the right the selected team — settings, members and its Combinado (working agreement).

Creating a team asks for two fields: the name and the parent team (or "top level", if there isn't one). Nothing else. The team is born active — activating and deactivating comes later, in the settings of the team once it's selected.

The creation form doesn't ask who the manager is. The manager is designated right after, by adding the person to the team with the manager role. And the member picker only offers people who already exist in the organization: bringing someone in from outside is an Admin act, on the Users page.

There are four team roles — manager, assistant, member and the read-only observer role. The observer role is assigned from the team card, here on the Teams page. Each person has one role per team: picking one clears the previous one automatically.

Use the parent team to group by department ("Marketing", "IT"): the hierarchy feeds the dashboard filters and, as you'll see in chapter 14, a child team inherits the deliverables plan of the team above it.

The guardrails around the structure

Some actions are refused on purpose, so you don't lose history without noticing.

Deleting a team

only possible if it has no sub-teams, no members and is nobody's home team. The screen disables the button and tells you what to move first; the server refuses again, as a safeguard. Work history is preserved.

Changing the parent team

Admin only. And the system refuses any change that would create a loop in the hierarchy (a team becoming its own ancestor).

The last Admin is protected

you can't demote, deactivate or remove the organization's only Admin. Promote someone else to Admin first.

Removing a member from the team takes away the role, not the person: they stay in the organization, and the work they did stays attributed to them.

On the team card you also see its AI workers. They don't show up through member association — they show up through the work plan, which is what actually ties a worker to this team and to its deliverables. In the AI workers block there is an Allocate AI worker button — it doesn't create a member link: it opens work plan creation directly, which is what ties the worker to the team. The button is disabled when every worker in the organization already has a plan on this team. The AI team has a chapter of its own.

Users: one person or a whole list

The Users page is the people registry, restricted to Admin and HR. The invitation is always by email — there is no invite code anywhere in the product.

When you add someone, you can pick the org role, the home team and the role within it all at once. An invitation email goes out immediately.

For whole teams, switch to the Multiple (paste list) tab and paste the lines. The format accepts two forms:

• just the email, one per line; or
• CSV: email, First, Last, OrgRole, Team, TeamRole.

Empty fields use the defaults you set just above the box, and the team is matched by name. The limit is 200 lines per batch. On submit, you get the result line by line — added, reactivated, already members, duplicates, invalid, errors — instead of a generic "done".

One important note about departures: removing a user deactivates them. They lose access immediately, but their contributions (work plans, activities, assessments) stay attributed to them, so the organization's records stay true — and you can restore them. This is not data erasure: the "Delete permanently" option exists and is only unlocked for people with no work-plan history. Deletion/anonymization requests (LGPD/GDPR) are handled as a separate, explicit action.

The Combinado: the house rules, in questionnaire form

There is no free-text field for "team rules". What exists is the Combinado (working agreement): a structured questionnaire of 13 questions, organized into four blocks:

Work Style & Location

primary mode of work and the policy for in-office days (with a weekday picker when the days are fixed).

Synchronous & Asynchronous Work

primary rhythm, recurring synchronous events, minimum notice for booking a meeting and the core availability window (with start and end times when it is fixed).

Communication Protocols

chat platform, channels and their purpose, expected response time for non-urgent messages, how to communicate urgency and after-hours boundaries.

Meeting Culture

the expectation about cameras and the minimum preparation for a meeting.

Each question has ready-made options and an open field, in case your answer isn't on the list.

The Combinado cascades down: organization → team → person. The answer that counts is the one from the most specific level that answered; a level left blank inherits the one above, and the editor shows in gray what you would inherit if you don't answer. That way the company sets the general rule once, the team adjusts what is different for it, and the person only records the real exception.

Each person sees their consolidated Combinado — the three layers already resolved — in My Profile, read-only.

And this is where it stops being paperwork: when a work plan is signed, the three layers of the Combinado in effect are frozen inside the plan. If the organization changes the policy later, what was agreed in that plan doesn't change along with it. You read the frozen text in the footer of the work plan itself.

13. Deliverables

The deliverable is the unit that makes work show up. Without it, the team has tasks; with it, the team has a result — and Orion has something to track, to chase and to narrate for you.

What a deliverable is

A deliverable is the final product or service that results from your team's work. It makes the value generated for the recipient visible and shows real progress toward objectives. When deliverables are clear, everyone understands exactly what has to exist at the end — which increases coordination, communication and motivation.

Examples: "Customer satisfaction survey conducted" (service), "App prototype created" (product).

Tasks and activities are the actions needed to produce the deliverable. The deliverable is the result of those actions. If you can cross an item off the list and nobody on the outside notices a difference, it's probably a task, not a deliverable.

Why insist on this: deliverables remove ambiguity about what is expected (focus), give you a number to track (measurability) and connect the day's work to the tactical and strategic plan (connection).

Projects and processes

A project ends. A process repeats. The platform handles both, and the difference is in the deliverable's status, not in the target type.

There is no "binary" target type. The list of target types comes from the types already used on your organization's deliverables. Until there are any, the platform offers %, unit and $ as a starting point.

Every deliverable marked Recurring is born with a cycle clock on, monthly by default. You change the length on the "Cycle clock" card (weekly, biweekly, monthly, quarterly, semiannual, annual or custom). Within the cycle, each process step is worth a slice sized by its weight; at the end of the cycle the real percentage is registered in the history and the steps reset for the next lap. That's why a process's progress doesn't leak from one month into the next.

Creating a deliverable

Go to Deliverables → ＋ Create deliverable. Only two fields are required:

Deliverable title

write the result, not the activity — "PRD — Backlog features moved to development" works better than "do the PRD".

Owning team

the team that manages this deliverable. Choose carefully — it is immutable in ordinary editing.

The remaining fields are optional at creation and editable later, on the deliverable's page: status, recipient, type, category, grouping, planned start date, planned end date, target type and planned target. Grouping connects the deliverable to the strategic-plan hierarchy (objectives, initiatives, key results) that Admins maintain on the Grouping page.

You can do it through chat too: "create the deliverable 'Customer onboarding revised'". When you don't say the team, Orion uses your home team.

Creating and editing deliverables belongs to the manager or assistant of the owning team (or of the team above it), and to the Admin. A regular member opens the deliverable read-only, with the notice on screen — their contribution shows through task progress.

What locks, and when

Four fields make up the planned baseline: planned start date, planned end date, target type and planned target. They are not fixed from creation — you can adjust them while planning is still open.

What locks them is the arrival of the planned start date. From that date on, those four fields are frozen and the system refuses the edit, showing the notice "🔒 Planned baseline is locked (start date has passed)". From there on you use the parallel fields — updated start date, updated end date and updated target — and it is exactly that difference between planned and updated that shows how much the plan slipped.

The owning team is immutable in ordinary editing. Since July 27, 2026, however, an Admin can reassign the deliverable to another team through a dedicated action — it is no longer a "never".

Deleting a deliverable is refused in three situations, and the message says which one: when some task already has progress, when it belongs to a deliverables plan, or when it is in a work plan. Remove it from the plans (or reset the progress) first. There is also Create a copy, which is the normal way to repeat a similar deliverable in the following period.

Progress, status and what Orion does with it

The deliverable's progress is computed, never typed: it is the average of the tasks' progress, weighted by each one's weight. A task with no weight set counts as weight 1; a task with weight 0 is left out of the calculation on purpose.

Who can touch a task's progress: the Admin, the manager or assistant of the deliverable's team (or of the team above), whoever is flagged as a contributor on the task, and whoever selected that task in their own work plan. The task's planning fields — due date, planned start and predecessor — belong to the team lead.

The status also moves on its own, from the dates and the progress: before the start it is Not started; between start and end it is In progress; if you pushed the end date out, it shows as Overdue between the planned date and the new one; past the effective end, it becomes Completed (progress at 100%) or Not completed. The states you set by hand — Recurring, On hold, Cancelled, Completed, Not completed — the system respects and does not overwrite.

Two things happen on top of this without you asking. The morning brief brings the deliverables at risk, with the reason computed: deadline passed with work still pending, progress behind the pace expected for the slice of time already consumed, or progress stuck for several days. And, on the deliverable's page, the Situation button compiles into text what the work plans linked to it say — useful before a follow-up meeting.

On the deliverable's page you can also attach material under Associated with this deliverable: a link (Drive, Workspace, URL) or an uploaded file — PDF or text (txt, md, csv), up to 25 MB. It's what Orion reads when you ask about that deliverable's content.

14. Team deliverables plans

The deliverables plan is the portfolio the team commits to working on over a period. It exists for a practical reason: it is its signature that releases the building of the individual work plans. With no signed deliverables plan, the team has nothing to lean on — and the system refuses.

What it's for

The deliverables plan defines the team's priorities during its effective period and serves as the reference for the members' work plans. It ensures alignment (daily work pulls the agreed results) and anticipates dependencies and allocation before the period starts.

It belongs to one team. And it holds for the teams below it: a sub-team with no plan of its own leans on the plan of an ancestor team.

Step 1 — Create

Go to Team Plans → Create deliverables plan. There are four fields: title, team, start date and end date. The plan is born as a Draft.

One precaution that saves rework: check all four before creating. Today there is no screen to edit or to delete a deliverables plan once it's created — the title, the team and the period stay as they were saved. What changes afterwards is the content (deliverables come in and out) and the status (through the signature, the calendar or the early close).

Through chat: "create a deliverables plan for the Product team, from September 1 to December 31, called 'Q4 2026 — Product'".

Step 2 — Insert deliverables

On the plan's page, use ＋ Insert deliverables. Search by title, check the ones the team will work on in the period and confirm with Add (n). A deliverable can be removed from the plan later, with the Remove from plan button on its row.

The plan's table shows, for each deliverable: progress, status, target, end date and who has worked on it — with the count of work plans per person. At the top, the plan's deliverables completion bar.

Step 3 — Sign

Once the portfolio is assembled, the ✍ Sign plan (manager) button appears. Signing is a manager's act (or an Admin's) — assistants assemble the plan, but don't sign for it.

The signature picks between two states, depending on the date:

Planned

the period hasn't started yet. It isn't a draft — it's a commitment already reviewed, waiting for the date. You can already build work plans on top of it; that is exactly why this state exists.

In progress

the period has already started (or starts today).

From there on the clock takes care of the rest. Every 30 minutes the system promotes Planned → In progress on the start date, and In progress → Finished when the period ends. On closing, whoever manages the team gets an invitation to record the period's lessons — a short retrospective that becomes precedent for the next cycle.

The on-screen notice after signing says the essential: "✓ Signed — work plans can now be built against this plan." This is also where the ✨ Generate work plans for the team shortcut sits, which splits the plan's deliverables across the active members for you to review before anything is created (chapter 15).

Closing early

Sometimes the period changes shape halfway through: the team is reassigned, the priority drops, the project ends sooner. The Close early button exists for that, and it sits at the same level as the signature — whoever opened the commitment is the one who closes it (manager or Admin).

Before anything else, the system runs a preflight: it computes and shows the real consequences, not a generic warning.

• how many days before the planned end you are closing;
• which deliverables stay live and end up with no deliverables plan — with each one's progress;
• how many work plans keep running (cycles and assessments do not stop);
• which AI workers are blocked from renewing a plan on those deliverables until they belong to a new signed plan;
• which teams end up with no source plan, which blocks the creation of new work plans — for people too, not just for the AI.

After that, closing requires a justification of at least 15 characters. It isn't bureaucracy: it is recorded as a decision on the plan and it's what the next period will read. Only then is the confirmation accepted, and the action is irreversible through the interface.

Two things that do not happen, because that's the real question of whoever clicks: the deliverables and the work plans are not closed along with it. They stay live, with their cycles and their assessments. Open deliverables can go into another plan later — and that doesn't have to be decided now.

The same contract holds through chat. If you say "close the Product team's deliverables plan", Orion first gives you back the list of consequences computed by the server, word for word, asks for the reason in your own words and only closes after your explicit yes. It never invents the justification.

Once closed this way, the plan shows the Closed early badge, with the date, who closed it and the justification visible on the page itself.

What you still can't do

Worth saying plainly, so you can plan around it: there is no editing of the plan after it's created (title, team, period), there is no deleting a plan, and the signature is not reversible — the way to undo a signed commitment is the early close, with a recorded justification.