Operational Analytics for Operations Leaders: What It Shows, and What It Misses
Published · Wendy Kinney
Operational analytics is the use of current data from the systems that run your operation to track performance and make day-to-day decisions: throughput, backlog, cycle time, service levels, and unit cost. It tells you what your systems recorded. It does not tell you how the work behind those records actually gets done.
Most operations leaders already have plenty of it. There is a dashboard for claims closed, a report for aged items, a service level trend line on the Monday call. Then the board asks how many of those hours AI could take over, and none of the dashboards can answer, because none of them measured the hours.
This guide covers what operational analytics means (the term has three meanings, and vendors use all of them), the five layers an operation typically runs, and how to match each layer to the decision in front of you. If you are facing that question now, you can also book a 30-minute strategy call and talk it through against your own operation.
Key Takeaways
- Operational analytics turns current system data into day-to-day operating decisions. Databricks defines it as “the use of real-time or near-real-time data to monitor operations and support immediate decisions within day-to-day workflows.”
- An operation usually runs five layers of it: operational reporting, real-time alerting, workforce management analytics, process mining, and activity-level workforce data. Each answers a different question.
- The first four read system records. Much of the working day never becomes a transaction record: Microsoft found the average employee spends 57% of their Microsoft 365 time communicating in meetings, email, and chat.
- Pick the layer by the decision. Backlog and service levels need system data. An AI or headcount decision needs data on the work itself.
What Is Operational Analytics?
Operational analytics is analytics built for running today’s operation. It draws on live or recent data from the systems where work is logged (policy admin, loan origination, ERP, ticketing, work order management) and puts the result in front of the people making daily calls about staffing, priorities, and escalations.
Databricks draws the line against traditional analytics clearly: “Traditional analytics is designed to explain what happened in the past, relying on batch-processed data to produce reports, dashboards and historical insights. Operational analytics, by contrast, deals with what is happening right now.”
Operational analytics vs business intelligence
The two overlap more than the vendor pages suggest. Business intelligence (BI) tools such as Power BI, Tableau, and Looker are usually the delivery layer for operational analytics, so the real difference is purpose and speed. BI answers “how did the quarter go?” for finance and leadership. Operational analytics answers “what needs attention before end of shift?” for the people running the floor.
Not the same as IT operations analytics
Search for the term and half the results are about servers. AWS describes operational analytics as “a solution that gives you a view of the health of your system using several disparate data logs.” That is IT operations analytics: system uptime, latency, and errors. It is useful, and it belongs to IT. When an operations leader says operational analytics, they usually mean the health of the operation itself: work in, work out, and how long it takes.
The Five Layers of Operational Analytics in an Operation
A back office or field operation typically runs up to five layers of operational analytics, and each one reads a different source. In our experience, most operations have the first two, many have the third, fewer have the fourth, and very few have the fifth.
| Layer | What it reads | The question it answers | What it cannot see |
|---|---|---|---|
| 1. Operational reporting (BI) | Transaction records in your core systems | How much work came in, got done, and aged? | How long each item actually took, or why |
| 2. Real-time alerting | Live system events and queues | What needs attention right now? | Anything that has not tripped a threshold |
| 3. Workforce management analytics | Volume forecasts, schedules, adherence | Do we have enough people scheduled for the forecast? | What those people do inside their scheduled time |
| 4. Process mining | Event logs with case IDs and timestamps | Where do cases stall between system steps? | Work that leaves no event: searching, rekeying, email, side spreadsheets |
| 5. Activity-level workforce data | Observed work on the desktop, classified by activity | Where do the hours actually go, task by task? | Nothing in the systems of record that layers 1 to 4 do not already cover |
Layers 1 to 4 are system-level operational analytics. They are built on data that a system wrote down as a by-product of the work. Layer five is different in kind: it measures the work itself.
If you are weighing layers 3 and 4 in detail, we compare them elsewhere: capacity planning software for operations covers the forecasting and staffing layer, and process mining vs workforce intelligence covers what event logs can and cannot reconstruct.
System-Level vs Activity-Level Operational Analytics
System-level operational analytics records outcomes and timestamps. Activity-level data records how the work between those timestamps was done. For most operating decisions the first is enough. For decisions about the work itself, such as what AI should take on, it leaves a hole where the answer sits.
The hole is large. The McKinsey Global Institute found that “the average interaction worker spends an estimated 28 percent of the workweek managing e-mail and nearly 20 percent looking for internal information or tracking down colleagues who can help with specific tasks.” That study is from 2012, and the pattern has not gone away. Microsoft’s 2023 Work Trend Index found that 62% of respondents struggle with too much time spent searching for information, and that across Microsoft 365 apps the average employee spends 57% of their time communicating in meetings, email, and chat.
None of that time appears in a claims system or a loan origination platform. A policy change that took 40 minutes because the adjuster had to find a document, ask underwriting a question, and rekey figures from a spreadsheet shows up in your operational reporting as one completed item with an open and a close timestamp. The dashboard is accurate. It is looking at the wrong unit.
How this looked before anyone could capture it automatically
Our team ran into this long before activity capture software existed. In a back-office engagement with Nationwide, the operation already had reporting: the project replaced 84 manual reports with electronic work tickets. What the reports could not show was how the work was being done across two sites. So the team conducted more than 10,000 side-by-side observations to identify best practices and optimize workflows, and the engagement delivered a 22% reduction in unit costs and $1.6M in savings.
A payments shared services engagement started the same way, with 868 side-by-side observations to get an accurate picture of key activities and baseline processes. Both were consulting engagements, and the observations were done by hand. That is the point. The activity layer has always been the one that settles the argument, and it has always been the expensive one to get.
Match the Analytics to the Decision in Front of You
Start from the decision you have to make, then pick the layer that can answer it. Most operations analytics projects go wrong by asking system data a question it was never built to answer.
| The decision | The layer that answers it |
|---|---|
| Is the backlog growing, and where? | Operational reporting (layer 1) |
| Are we about to miss today’s service level? | Real-time alerting (layer 2) |
| How many people do we need next month? | Workforce management analytics (layer 3) |
| Why do cases wait between approval and payment? | Process mining (layer 4) |
| Which tasks could AI take, and how many hours would that free? | Activity-level data (layer 5), scored with a workforce automation analysis |
| Can we meet a headcount target without breaking service levels? | Layers 1 and 5 together: the volumes and service levels from your systems, the hours by task from the work |
The last two rows are the ones arriving on operations leaders’ desks now. The McKinsey Global Institute estimates that “by 2030, activities that account for up to 30 percent of hours currently worked across the US economy could be automated.” Notice the unit: hours spent on activities. Your transaction data does not count hours by activity, so an estimate built only on it has to borrow someone else’s assumption about how your people spend their day.
An illustration: the same operation through two lenses
This is an illustrative composite, not a client. A loan servicing team of 60 processes about 9,000 payoff requests a month. The operational reporting is solid: average cycle time, aged items over five days, service level against a 48-hour target. By every system measure, the team is stable.
The mandate asks for a 15% capacity reduction through AI. The system data can say how many payoffs there are. It cannot say whether the time goes into calculating payoff figures, chasing lien holders by email, reconciling a spreadsheet the core system does not hold, or answering status questions. Each of those has a different automation answer, and the difference between them is the difference between a 15% target that holds and one that quietly breaks the service level six months later.
What to Look For in Operations Analytics Software
Good operations analytics software makes clear which layer it covers, and does not claim to cover the others. Most tools marketed as operational analytics software are layer 1 or 2: BI and alerting on top of your systems. That is fine, as long as you know it before you ask it an AI question.
When you evaluate options, check six things:
- Its source: Does it read transaction records, event logs, schedules, or the work itself? Ask for the list of data sources it needs before you look at a single dashboard.
- Volume vs effort: Can it tell you how long work took, as well as how much was done? Items completed per day is not the same as hours spent per item.
- Activity, not application: Time in an application is not a task. “Six hours in the claims system” says nothing about whether that time was data entry, research, or waiting.
- A baseline you can re-measure: If AI goes in, you will need to prove what changed. The same measure has to run before and after, which is what makes an AI operations pilot defensible to a board.
- Privacy by design: Anything that observes desktop work should capture as little as possible. Ask what is recorded, what is never recorded, and who owns the data. The difference between intelligence and employee monitoring is largely here.
- Someone who reads it with you: Numbers without operational judgment produce confident wrong answers. Ask who interprets the output and what their operations background is.
For a category-by-category list of tools in the activity layer, see our guide to the best workforce intelligence software.
Where Summit Trails Fits, and Where It Does Not
Summit Trails provides layer 5, activity-level ground truth of how the work is done, for a defined 90-day scope. It does not replace your BI, your workforce management system, or process mining, and it should not. Those layers answer their own questions well.
The Ground Truth AI² Platform captures the region around each click on the desktop, classifies it with vision AI at the activity level, and turns it into time allocation, workflow maps, and automation scoring for every person in scope. It never captures keystrokes or the full screen, and the customer owns the data. You can see how the capture and classification work and the privacy architecture in detail.
What that adds to your existing operational analytics is the missing unit. Instead of “six hours in the claims system”, the output reads as minutes spent entering data, looking up records, and resolving exceptions, which is the level an automation decision needs. The ground truth workforce data that results sits next to your system data rather than on top of it, and our operations consultants read it with you, so the final blueprint reflects how your operation actually runs. See what the output looks like.
If a mandate or an AI program is already on your calendar, book a strategy call before the number is set.
Frequently Asked Questions
What is operational analytics?
Operational analytics is the use of current data from operational systems to track performance and support day-to-day decisions, such as staffing, prioritization, and escalations. It differs from traditional analytics, which explains past results in batch reports. In an operation it usually covers throughput, backlog, cycle time, service levels, and unit cost.
What is the difference between operational analytics and business intelligence?
Business intelligence is the broader discipline and toolset for reporting and analysis. Operational analytics is a use of it: faster, closer to live data, and aimed at the people running the operation today rather than at quarterly review. In practice the same BI tools often deliver both.
Is operational analytics the same as IT operations analytics?
No. IT operations analytics measures the health of systems and infrastructure from logs: uptime, latency, and errors. Operational analytics in the business sense measures the health of the operation: work in, work out, and how long it takes. The same name covers both, which is why search results mix them.
What are examples of operational analytics?
Common examples in back-office operations include a daily backlog and aging report, real-time service level alerts, staffing forecasts against expected volume, bottleneck analysis from process mining, and time allocation by activity. The first four read system records. The last one measures the work itself.
What is operations analytics software?
Operations analytics software collects operational data and presents it as dashboards, alerts, or analysis for operations teams. Most products read transaction or event data from existing systems. A smaller group, including workforce intelligence platforms, measures the work people do across those systems, which system data alone does not record.
What operational data do you need before an AI decision?
You need your volumes and service levels from system data, plus a measure of how the hours are spent by activity. The first shows what the operation must still deliver. The second shows which tasks AI could take on and what that would free up. Without the second, the estimate rests on assumptions about how your people work.
Put the Work Next to the Numbers
Your operational analytics are probably accurate. The question is whether they measure the thing your next decision depends on. For backlog, staffing, and service levels, system data is the right tool. For what AI should take on, and what that means for your people, you need the work itself on the table.
Bring your current operations dashboard to a 30-minute strategy call. We will go through the decision you are facing, which of your existing analytics can support it, and where activity-level data would change the answer. Book a 30-minute strategy call.
