iKPI
See where work waits, and where improvement could pay
iKPI is designed to follow an order, request or task across your departments, separate waiting time from active work, and turn each finding into an improvement action with an owner and a date to measure it again.
Does this sound familiar?
An order passes from Sales to Finance to Operations to Delivery, and the delay only shows at the end. Managers cannot tell whether it waited in a queue or took real work, who owned the next step, or how to compare teams fairly when their workloads differ.
What it costs the business
Meetings are spent assembling figures and debating whose fault a delay was, while the same queue, the same rework and the same manual chasing come back the following month.
Built for
- Chief executives and business owners who need to see what holds delivery back
- Operations leaders responsible for orders and requests that cross departments
- Department managers who agree targets and own improvement actions
From problem to gain
What changes when the work moves into one place.
The situation
- Meetings are spent assembling figures and debating whose fault a delay was, while the same queue, the same rework and the same manual chasing come back the following month.
What your team does
- Agreed metric definitions
- Targets and scorecards
- Order and request journeys
What it produces
- A journey view that separates waiting from active work at each stage
- An exception against an agreed target, with the evidence behind it
- An improvement action with an owner, a due date and a measure for the next period
What you gain
- Know where to investigate a delay, not just that it happened
- Give every improvement an owner and a measured result
- Spend less time compiling performance reports
The difference it makes
Know where to investigate a delay, not just that it happened
How
Each recorded stage of the journey is designed to show its waiting time and its active time separately, against a target your managers have agreed.
Give every improvement an owner and a measured result
How
A finding is designed to become an improvement action with an owner, a due date and the same measure reviewed again in a later period.
Spend less time compiling performance reports
How
Department and role scorecards are designed to be calculated from approved metric definitions and your recorded events, instead of being rebuilt by hand.
How it fits together
What it does
- Agreed metric definitions
- Targets and scorecards
- Order and request journeys
What your team gets
- A journey view that separates waiting from active work at each stage
- An exception against an agreed target, with the evidence behind it
- An improvement action with an owner, a due date and a measure for the next period
How your team uses it
Operations leader
Agrees the metric definitions and targets for a process that crosses departments
- Output
- Approved, versioned measures
- Next owner
- Department managers
Department manager
Reviews an exception and the recorded journey behind it
- Output
- An investigation focused on the stage where work waited
- Next owner
- The owner of the improvement action
Action owner
Makes the agreed change and records it
- Output
- The same measure reviewed again in the next period
- Next owner
- Operations leader
Inside iKPI
Agreed metric definitions
Each measure is designed to have a written, versioned definition that a person approves before it is used, so everyone reads the same figure the same way.
Targets and scorecards
Designed for agreed targets with executive, department and role scorecards, so performance is compared with what was agreed rather than with an impression.
Order and request journeys
Designed to follow one order, request or task through every recorded stage, with the owner of each stage, its queue time and its active time. A missing event would be shown as missing, never as zero.
Bottlenecks and rework
Designed to find the stage where work repeatedly waits and the cases that come back for rework, so the investigation starts in the right place.
Improvement actions
Designed to turn a finding into an action with an owner, a due date and the measure that will show whether the change worked.
Evidence summaries with AI
AI is designed to summarise the evidence and suggest questions to investigate. Agreed definitions and recorded events determine every measure, and managers decide.
Fair people measures
Employee and team views are designed to weigh role, workload, task complexity and quality. Waiting time alone never shows that a person is at fault.
Illustrative example — assumed inputs, not a customer result
One order, four departments
Assumed inputs
- Sales stage
- 0.5 business hours
- Finance stage
- 8.5 business hours: 8 waiting in the queue, 0.5 of recorded activity
- Operations stage
- 1.5 business hours
- Delivery stage
- 2.5 business hours, active time unknown (no start event recorded)
What the assumptions give
13 business hours end to end, 8 of them waiting in the Finance queue. This shows where to investigate first, starting with the approval requirement and the capacity available. It does not show a cause or an individual fault.
What a pilot would measure
Queue time by stage, on-time completion and rework cases in a comparable workload, reviewed again after an agreed change.
How to start / What this requires
By design, iKPI works from your own recorded events, so it does not depend on other iConnect offerings. It needs reliable event data and processes configured with you.
First step
Start with a tailored demoWe walk through your own workflow with you and confirm which of the requirements below apply to your team.
What needs to be in place
- Recorded events from your processes, such as orders, requests, tasks and approvals, from validated event files or an approved API connection.
- Processes configured with you: the stages, the owner of each stage and the business calendar used to count waiting time.
- Metric definitions and targets agreed and approved by your managers.
- For sector-specific measures: configuration for your process and suitable source data.
- People to decide: AI summaries suggest, and authorised managers make every attribution and coaching decision.
What you gain by connecting it
Selected combinations, not every possible pair. Each connection shows how far it has been proven, so you can tell what has been shown working from what is still planned.
How to read the connection labels
- Demonstrated in testing
- Shown working in our testing, on code that is not yet released to customers.
- Configured per deployment
- Depends on setup for your deployment, such as a connected channel or approved knowledge.
- Planned
- Not built yet. Shown to explain the intended workflow.
Performance summaries in iSight (Roadmap)
A pinned iKPI summary is designed to appear in the leadership view of iSight (Roadmap), so executives see the exception without rebuilding the report. So far this has been shown on demonstration data.
Works with
iSight (10)RoadmapSee the full workflowConnections
- iKPIiSight
- Pinned performance summary
- Demonstrated in testing
Visit records from iField (Controlled beta)
Visit records from iField (Controlled beta) are designed to feed field performance measures, so a manager sees where field work waits. So far this has been shown on demonstration data.
Works with
iField (4)Controlled betaSee the full workflowConnections
- iFieldiKPI
- Visit records for performance measures
- Demonstrated in testing
Approved actions through iFlow (Roadmap)
An approved improvement action would be routed to the responsible person through iFlow (Roadmap), and workflow timings would feed the measure.
Works with
iFlow (8)RoadmapSee the full workflowConnections
- iFlowiKPI
- Workflow timings for measurement
- Planned
- iKPIiFlow
- Approved improvement action
- Planned
Suggested solutions
Complete workflows this product takes part in.
Related pages
- iSight (10)Roadmap
- iField (4)Controlled beta
- iFlow (8)Roadmap
Good to know
We would rather you knew the current limits before a demo than after it.
- Roadmap: iKPI is not yet offered. Request a demo to discuss where work waits in your business.
- Its connections to other iConnect offerings are planned or demonstrated in testing only. None is released.
- Sector measures are not ready-made: each one needs configuration and suitable source data.
- It does not rank employees or make employment decisions. Waiting time alone does not show that a person is at fault.
- It does not forecast results. It measures recorded work against agreed targets.
- It does not replace your accounting, payroll or workflow systems, which keep their own records.
Technical details
For technical evaluators: records, roles, inputs and setup, as far as current evidence supports them.
Show the technical details
- Inputs
- Validated event files or an approved API. Each event records what happened, to which order, request or task, and when.
- Calculation
- Measures are designed to follow versioned definitions. Queue time and active time would be counted separately on the configured business calendar, and a missing timestamp flagged rather than counted as zero.
- Permissions
- People measures are designed to be visible only to authorised roles. Summaries shared with other offerings are limited to what your organisation permits.
- Role of AI
- AI is designed to summarise evidence and suggest questions. It would not calculate measures, rank employees or make decisions.
- Delivery status
- Roadmap. Parts of the design have been built and demonstrated in testing on demonstration data. Nothing is released, and no real client data has been used.
Questions and answers
How does iKPI differ from leadership reporting?
iKPI defines and calculates measures and investigates the recorded journey of work. iSight (Roadmap) presents permitted results and exceptions for leadership. Where both are included, iSight is designed to show an iKPI summary; this is demonstrated in testing on sample data only.
How does iKPI differ from workflow routing and conversation quality review?
iKPI shows where to investigate and measures the change. iFlow (Roadmap) routes a configured action or approval, and finding a queue does not by itself authorise changing the process. iQuality (Roadmap) evaluates conversation quality and coaching; sharing its results with iKPI is a planned connection that is not built yet, and it would be separately governed.
Do we need other iConnect offerings to use iKPI?
By design, no. iKPI reads your own validated event files or an approved API connection. Connections to other iConnect offerings are optional, and the starting point is agreed with you in a tailored demo.
Will iKPI tell us which employee caused a delay?
No. A long wait in a queue does not show who caused it. Employee views are designed to weigh role, workload, task complexity and quality, and authorised managers make every attribution and coaching decision.
Is iKPI available now?
No. iKPI is on the roadmap. Request a demo to discuss where work waits in your business and how it would be measured.
Discuss where work waits in your business
Tell us which order, request or task crosses your departments and where it slows down. We will reply to arrange a tailored walkthrough.