Co-Pilot

Ask about your process in plain language and get an answer computed from your data — with the filter it applied, the chart it drew, and a link through to the page that shows the same thing. No SQL, no query builder.

What the copilot does

The copilot answers questions about the process in the project you have open. It reads your data, not a summary of it, and everything it says is computed at the moment you ask.

Ask things like

• "Show me orders that took longer than 14 days"
• "How long do orders stay blocked, typically?"
• "How do in-progress orders differ from completed ones?"
• "Which step has the longest wait?"

And it will

• apply a filter that matches the question, which every page in the project then answers to
• run the analysis and give you the numbers
• draw a chart where a chart helps
• suggest what to ask next
• link you through to the page where you can carry on by hand

The map beside the conversation stays in step: apply a filter in the conversation and the map redraws to the same cohort.

What it can work out

The copilot picks from a set of tools rather than writing free-form queries, which is what keeps its answers reproducible.

Filter and focus — build a filter from your question: by duration, by attribute, by event, by path ("orders that went through a block"), by timeframe, and across related objects. Applied filters appear in the Active Filters panel like any other, and you can remove them there.

Change the view — switch the map's lens to a different object type, or overlay events from a related object, so the picture matches what is being measured.

Answer with numbers — headline statistics (counts, percentages, medians and means with the population they were computed over), plus focused analyses:

• volume and processing-time over time
• delay histograms and end-to-end duration distributions
• bottleneck analysis and rework loops
• attribute distributions, and distributions split by another attribute
• top-N rankings, event frequency and variant summaries
• what statistically distinguishes one cohort from another

Draw it — bar charts, histograms, timelines, box plots, density distributions and ranked tables, rendered inline.

Hand off — when the next step is better done on a page than in a conversation, it gives you a link that carries the cohort and lens with it: the object explorer, Explore, Variants, Bottlenecks, Compare or Health.

What an answer looks like

A typical answer has some or all of:

A sentence saying what it is about to do, before it does it.

A filter card, if it applied one, naming the filter in plain language, with controls to copy or remove it.

The answer itself — prose with the numbers in it, bolded where they carry the point. Where a comparison is involved you may get a What makes this group different card: the conditions that are more or less common in this group than in the rest, ranked, with each row clickable to filter to it.

A chart, where the shape of the data is the point rather than a single number. Charts carry a filter badge showing the cohort they were computed over, an information control explaining the measure, a copy control for the underlying data, and a bookmark to pin the chart to the project's Board.

A link card through to a page, labelled with where it goes and what it carries — "Compare · 1 filter carried · Sales Order view".

Follow-up questions, as a short numbered list. They are written for the answer you just got, so they are usually better than the question you would have thought of.

Asking good questions

Patterns that work

Duration — "Show me cases that took longer than 2 weeks", "What's the average time between a block and its release?", "How long does an invoice typically take to clear?"

Comparison — "Compare blocked orders with the ones that were never blocked", "How do high-value orders differ from the rest?"

Investigation — "What makes some blocked orders wait longest to be released?", "Why do some order lines have their quantity changed?"

Filtering — "Show me only EDI orders", "Filter to orders over 50,000 in value", "Show orders from Q1"

Patterns that work less well

Too vague — "Tell me about my process". Ask for something specific: "What's the median cycle time of completed orders?"

Several questions at once — "Show me slow cases and compare high-value vs standard and tell me the bottlenecks". Ask one, then follow up; the context carries.

Things the data cannot answer — the copilot will not predict next month. Ask for the trend over the last six months instead.

Deeply nested conditions — a paragraph of ifs and unlesses is better broken into two or three turns.

Agreeing on definitions

When you ask about a named business metric — "what's our exception rate?" — the copilot does not guess. It proposes a definition in your own vocabulary and asks you to confirm it: what counts, over which population, in what window. Confirmed definitions appear on the project's Metrics page as drafts, and an admin can promote one to be the project's official reading. From then on, anyone asking that question in that project gets the same formula.

The same applies to derived attributes. If an answer needs a value your data does not carry — days late, an invoice's due date — the copilot can propose an enrichment: a formula computed into the data once, then available to every filter, chart and answer afterwards.

Both exist for the same reason: so that two people asking the same question of the same project get the same number.

Working with conversations

Conversation list — every conversation in the project, searchable, with the message count and date. Star the ones worth returning to; delete the ones that were dead ends.

Voice input — the microphone next to the input box takes a spoken question. Useful for long ones, and for demos.

Feedback — you can tell us when an answer was wrong or unhelpful. That feedback is read.

Troubleshooting

The answer is not what you meant

Ask it to explain the filter it applied — the filter card names it in plain language, and the Active Filters panel shows exactly what is in force. Nine times in ten the filter is a reasonable reading of an ambiguous question, and a more specific phrasing fixes it.

It says the data does not support the question

Check the attribute exists: Explore lists every attribute on every object type with its values. If it is genuinely missing, an enrichment may be able to derive it.

It is taking a while

Questions that need several analyses coordinated take longer than a single lookup, and large cohorts take longer than small ones. If a question is slow, narrowing the cohort first usually makes the rest of the conversation quicker too.

Next steps

See the same thing on a page

• Process Map — the filter the copilot applied, drawn
• Process Variants — the paths a cohort takes
• Boards — pin the charts worth watching

Understand the filters

• Filters & Exploration — what the copilot is building when it filters
• Quick Start Guide — the copilot in a first session