Executive dashboard

Added in v0.235.0 The Executive dashboard answers four questions with data orboto already holds (time entries, tickets, work sessions, review decisions and AI usage), so there is nothing to instrument:

1. How many hours do people and agents put in?
2. What does a closed ticket cost?
3. Did the sites where agents work get faster than the sites where they do not yet?
4. Was the rule for "this worked" written down before the first site went live?

What you set up is the hourly rate, the programs, the day agents go live on each site and the decision rule of each program. The page is for managers who need a comparison, not for tracking single tickets; for one project's charts see Analytics.

Open Executive in the sidebar. The entry appears only for accounts that may see the dashboard (see below).

Words used on this page

Who sees what

Everyone else is refused. The analytics:executive permission was given once, on upgrade, to every project role that already had project:edit; add or remove it per role like any other permission. An API key limited to scopes reaches the project-role path only when analytics:executive is among its scopes.

Two points that change what you see:

• Figures built from tickets (closed tickets, cycle time, throughput, hours, agent outcomes, open, blocker and overdue counts) leave out tickets you may not read: a private ticket, or a ticket in a private milestone you cannot see. Two people with different access can therefore see different numbers for the same site. That is intended.
• AI spend is a cost, not a ticket figure. It is allocated from usage records and is not filtered by ticket access.

The Audit trail block is shown to super-admins and accounts with admin:audit:read; for everyone else the page says it is shown to accounts that may read the audit log.

Changing the settings needs more: programs, decision rules and sites need admin:portfolio:write, the two rates need admin:system:write. The Settings button appears only for accounts that may change something.

Read the page

Added in v0.235.0 The filters at the top are From, To, Period (week or month), Program, Project, and Compare group A and Compare group B.

• The default range is the 182 days up to today. The longest range is 728 days.
• The range is widened to whole periods before anything is read: From moves back to the first day of its period and To forward to the last day of its period (a date after today counts as today). A caption under the filters names the range actually shown, so no period at the edge is a stub.
• The period that contains today has not ended. Its hours, tickets and cost are in the totals, the per-site sums and the cell table, and the page draws it dashed and names it in the caption. It is left out of everything that divides by a number of periods: throughput, velocity, the before and after of a site, the comparison of live and not-yet-live sites, the group comparison and the verdicts of the rules.
• A figure with no closed ticket behind it shows -, never zero.

The sections, top to bottom:

A line under the page repeats the hourly rate used and says that hours are split by the agent-work stamp of each time entry and that figures cover only the tickets you may read.

How the figures are made

Hours. The hours are the time entries booked on tickets in the range, placed in the period of the day they were logged. A time entry carries a stamp that says whether it is agent work; it is set when the time was logged through an agent-flagged API key or by a bot account. Time without the stamp, including everything logged before the stamp existed, counts as human.

Closed tickets, cycle time, throughput.

• Closed counts tickets whose closing date falls in the period. Tickets closed as "won't fix" do not count.
• Cycle time is the days from creation to closing, averaged over the closed tickets.
• Throughput is closed tickets per site and period.
• Hours per closed ticket counts human hours only.

Cost per closed ticket.

(human hours x hourly rate + AI spend) / closed tickets

• The hourly rate is one rate for everybody, on purpose: the dashboard compares groups of sites, not people. It is a workspace setting and starts at 0, in the workspace's default currency.
• AI spend has two parts, both converted into the workspace currency with the factor AI spend: 1 USD = (starts at 1). Agent lane usage is split over the projects of a lane in proportion to the minutes its account logged in each project in that period, evenly when the account logged none. In-app AI usage is split over the projects the user logged time on in that period, in proportion to the minutes.
• Unattributed AI spend is what no project can take: the usage of a lane with no project, and the in-app usage of a user who logged no time in that period. It belongs to no project figure. The page names the amount in a note when it is above 0; for project-scoped accounts it is always 0. With a program or project filter, AI spend that went to a project outside the filter, or outside what you can see, is in no figure, so the workspace total cannot be rebuilt from the answer.

Agent outcomes. Counted over implementation work sessions of bot accounts that started in the range, on tickets you can read:

Project health is the state today, not of the range: open tickets (not closed, not done, not "won't fix"), open blockers, overdue tickets (open and past their due date) and velocity per week (closed tickets of the periods that have ended divided by the weeks in them, - while no period has ended).

Sites with agents compared with sites not yet live

Added in v0.235.0 A site that goes live in the middle of the range could be compared only with itself, before and after. That mixes in everything else that changed over time: a release, a holiday, a new hire. The dashboard therefore compares sites with agents live against sites not yet live in the same periods. Sites go live one after the other, so in every period some are live and some are not. This is the design of a stepped-wedge trial.

Each cell of a site is in one of three states, from its go-live day. The page colours the cells of Sites by period by state; orboto analytics executive sites prints one character per period:

The comparison covers four metrics: human hours per closed ticket, average cycle time, closed tickets per site and period, and cost per closed ticket. For each metric:

1. Cells of the go-live period and of the running period are dropped.
2. Only periods that hold at least one live cell and at least one not-yet-live cell are kept. A period in which every site is live, or none is, says nothing about the effect.
3. The metric is worked out once on all live cells and once on all not-yet-live cells, as a ratio of sums over the pool, not an average of averages, so a busy cell counts more than an empty one.
4. The page shows both values, the difference, the ratio and the improvement in percent. A positive improvement always means the live sites are better: lower for hours per ticket, cycle time and cost per ticket, higher for throughput.

If one side has no closed ticket, its value and everything derived from it show -. The counts (cells, periods and tickets on each side) are shown with the result. Use the wording "compared with sites not yet live", not "before agents": the comparison is across sites in the same periods. The before and after of a single site in the sites table is a simpler view of that one site and is not the comparison.

Group comparison. The two groups A and B take Sites with agents live, Sites not yet live or any program; the default is live against not yet live. A program group pools every finished cell of its sites, whatever their state, and shows how many of its cells were live. Use two programs to compare two rollouts, or one program against Sites not yet live to see one program against the rest. The live group and the not-yet-live group count only the periods the comparison above keeps, so they never mix periods with and without agents. A site that is live now also counted as not yet live in the earlier periods of the comparison, so the comparison's not-yet-live value can differ from the not-yet-live group when sites went live one after the other.

Decision rules

Added in v0.235.0 A rule states what counts as success: one metric, a threshold in percent (0 to 1000) and a minimum number of comparable periods (1 to 104). It is meant to be written before the first site goes live, and the dashboard says whether it was.

A verdict uses the cells of the program's own sites that you can see, from the program's first go-live day (at most 728 days back) up to the last period that has ended. The filters on the page do not change it. If you cannot see all sites of a program, the line says "Based on N of M sites".

Lifecycle.

1. Write the rule in the settings. Time and author are stored with it. Writing again replaces it as long as nothing is locked.
2. Lock. The rule is locked when the first site of the program is live. A program with no rule locks the same way, so a rule cannot be added after the first go-live. The lock is recorded in the audit log.
3. Written before or after go-live. Each rule shows Written before go-live or Written after go-live. It is "after" when the rule was written on or after the day of the first go-live, for example because a go-live day was entered afterwards with a date in the past. A rule written after go-live is still a correct calculation, but it is not a rule set in advance and must not be presented as one.
4. After the lock these are refused: changing or replacing the rule, deleting the program, changing its period, moving a live site to another program, changing or clearing the go-live day of a live site, and setting a new go-live day in the past. Renaming the program and editing its description stay possible. Deleting a program that is not locked sets its sites to no program. Creating or renaming a program to a name that is taken is refused.

Set it up

Added in v0.235.0 On the dashboard, Settings opens Executive dashboard settings. A good order for a rollout: create the program, write the rule, assign the sites, set their go-live days. Go-live days may lie in the future.

Every change is written to the audit log with the previous and the new value. All of it is part of the full backup; a project export carries its program, and an instance without that program reads it as no program.

Export

• Cell table (CSV) has one row per site and period with raw values: project key and name, program, go-live day, period start, state, human and agent minutes, closed tickets, average cycle days, hours per closed ticket, cost per task, AI spend, human cost and whether the period is still running (its counts are partial). Use it in a spreadsheet or a statistics tool, so a second analysis does not need the API.
• PDF renders the summary (figures, comparison, rules, group comparison, audit status) and the sites table, up to 200 sites, in the language and date format of the person who exports. If the PDF engine is not available on the instance, the export is refused with a service-unavailable error.

Both take the same filters as the page and contain only what you may see.

Command line and other surfaces

orboto analytics executive                                   # key figures, comparison, rules, groups, audit status
orboto analytics executive --period month --program Rollout  # one program, by name or id
orboto analytics executive --group-a program:Rollout --group-b not_live --json
orboto analytics executive sites --projects ACME,WEB --all   # per site: go-live, hours, cost, before and after, strip
orboto analytics executive csv --out cells.csv
orboto analytics executive pdf --out executive.pdf
orboto analytics executive config
orboto analytics executive settings set --hourly-rate 85 --ai-usd-rate 0.92
orboto analytics executive program create "Q4 rollout" --period week
orboto analytics executive program rule "Q4 rollout" --metric cycle_time_days --threshold 20 --min-periods 8
orboto analytics executive site set ACME --program "Q4 rollout" --live-since 2026-12-01

Programs are picked by id or exact name, projects by key or id. --json prints the API object unchanged. Exit codes: 0 done, 1 the API refused or a name did not resolve, 2 a flag was wrong and nothing was sent. orboto help executive-dashboard prints the same overview.

An MCP client finds the routes with orboto_api_search and calls them with orboto_api_call. The in-app chat answers questions from it with a read-only summary tool (orboto_executive_summary). On the personal Dashboard, four widgets for accounts that may see the executive dashboard show hours, the comparison, cost per task and the audit status.

Reading the numbers honestly

• A comparison is an observation over the cells that exist. With few sites, few closed tickets or few comparable periods, treat it as a hint. The number of live and not-yet-live cells, comparable periods and tickets is shown with each result for that reason.
• The split into people and agents depends on the stamp. If agents work through API keys that are not flagged as agent keys, their hours count as human. Check the agent share of each site before you compare hours.
• A rule protects you only if it was written before the first go-live and is locked. Check "Written before go-live" before you quote a verdict. A rule marked "written after go-live" was written when data could already exist. Do not read a missed rule as a reason to write a new one for the same program.
• Cost per closed ticket mixes periods. It divides the hours and AI spend of a period by the tickets closed in the same period, but the hours were booked on tickets that may close in another period. A single cell can swing when work and closing fall in different periods (the CSV shows it cell by cell). Pooled figures over several periods settle; quote the comparison and the group figures, not one cell.
• The running period is partial and is left out of rates and comparisons. Do not compare it with finished periods.
• Different viewers can see different numbers. Tickets you may not read are left out of ticket figures, and a program's verdict can rest on part of its sites.
• "Last verification" in the audit block is the time of someone's run, not of your page view. The dashboard never verifies by itself. Only a run over the whole chain reads as intact; a run over a range, or one recorded by a release before 0.235.0, reads as a partial check. A run that held but could not prove entries of deleted accounts reads as "Intact, entries not provable", and a broken one as "Broken at link N". See Audit log and tamper evidence.

Troubleshooting

• There is no Executive entry in the sidebar. Your account has neither the admin:portfolio:read permission nor a project role with analytics:executive, or it is an external account.
• Cost per closed ticket is - or 0 for people. The hourly rate starts at 0; set it under Rates. A figure with no closed ticket behind it is -.
• The comparison shows no result or "Not enough data". It needs periods that have ended and hold both live and not-yet-live sites. Check that the sites have go-live days and that a program has at least the minimum number of comparable periods.
• A rule, a program or a go-live day cannot be changed. The program is locked because a site of it is live.
• The AI spend does not add up to the workspace total. Part of it may be unattributed, or may belong to projects outside your filter or outside what you can see.
• The PDF export fails. The PDF engine is not available on this instance; ask an administrator.