18 Ways Data Analytics Has Changed COO Decision-Making Strategies

1. I no longer trust an average-based dashboard. Every operational decision at TradingFXVPS that I make now is based on a very small set of raw data: per-server latency percentiles to major broker datacenter locations, CPU steal time, ticket volume by server, and customer churn joined back to the server(s) that customer was running on. If a decision can't be made with that data, then it can wait. Decisions around capacity purchases, server density, where to send new hardware, and what to prioritize with engineering around various support issues all get made with that same set of join data. Gut feel still plays a large role in my decisions, but that has to check against the data first.

2. The average latency that misled us for so long: For years we reported sub-millisecond averages to the broker servers. However, after matching all the cancellations with the corresponding node data, we realized that the customers who were leaving weren't connected to any slow servers most of the time. Rather, they were running on servers that were perfect 99% of the time but spiked hard to high latency for long periods of time - within the first minute or two of NFP, CPI, etc. release times - the London open, etc. Noisy neighbors all firing at once when the traders needed it most. Thus, we reversed our model of capacity planning. We now plan for the worst five minutes of the worst month, not for the typical hour of typical trading. We cap density at levels below what the hardware could technically support, i.e. at lower levels than we could sell. We watch p99 and CPU steal time during scheduled news events, and we rebalance all accounts before each such release. Sure, it costs us more per box of hardware than we could sell it for, but the end result is so much better: so much less churn, and support tickets for such events are near zero.

The most valuable operational metric we track isn't high-level revenue dashboards—it's granular step-by-step latency across our background pipelines.

A few months back, generation times were creeping up and the team was convinced we needed to spend tens of thousands of dollars on dedicated GPU clusters to speed up model inference. Before making that call, we mapped out our full pipeline telemetry.

What we saw was an eye-opener: the model wasn't the problem at all. One of our intermediate services was accidentally generating an entire secondary executive summary on an unseen temporary file before passing it to the final renderer. It was burning 60 to 140 seconds on throwaway work. We killed that redundant step and cut generation latency by nearly 45% in an afternoon, saving huge cloud costs. Looking at raw pipeline data saved us from making a very expensive, totally unnecessary infrastructure purchase.

Most operational decisions used to be settled by whoever argued best in the room. We changed that by making the test the unit of decision. Every significant page or cart change goes live as an experiment with one primary metric fixed in advance, and ship or kill is decided by the number, not by seniority.

The single insight that changed how we operate came from a failure. We added medical certification badges and technical specifications to the product page of an unnamed B2B medical shop, expecting trust and revenue to rise. Instead revenue per user fell 74.01%: control 11.37 EUR, variant 2.96 EUR, 1,779 users over 66 days. We stopped the test and reverted.

Two operating rules came out of that one number. First, our intuition about what reassures a buyer is not reliable, so no opinion ships untested. Second, the metric decides the debate: we grade pages on revenue per user rather than conversion rate, because a change can lift conversions while lowering revenue, and that split is invisible in a conversion rate dashboard.

We also circulate the losers internally on purpose. A team that only sees its wins starts optimizing for approvals instead of outcomes.

The data insight that changed how I ran operations was finding out our problem was not effort, it was paying for work that never got signed off. In my NBN telecom contracting company, every job was captured in the field in our own software and reviewed by an office admin. Once I looked at that data by crew and by job type, I could see that a few contractors were fast but generated rework, and the rework was eating our margin on projects connecting 1,000 to 30,000 homes. Early on I had paid contractors who only cared about money, not quality.

That insight led to the biggest operational change I made. I moved to employees on the legal minimum base plus uncapped performance pay, but only for work that passed review. Quality went up because pay was tied to approved work, and some employees earned around $200,000 a year doing it right. We grew to about 30 staff and around $2.2 million at peak, and that pay structure drew interest from senior project and government people. I still teach owners the same lesson: track the output you actually get paid for, not activity, and let the numbers show you where the leak is before you hire or fire anyone.

The data point that changed how we run ad accounts was a division sum.

An ecommerce client we ran Meta Ads for was getting about 44 attributed purchases a month, spread over roughly 12 campaigns, because a new pair of campaigns was built every Monday for that week's promotion and the old pair was switched off. Divided out, that is three to four purchases per campaign. Meta's delivery system needs a steady flow of results inside one campaign to learn whom to show ads to, so none of those campaigns ever got there. Every week started from zero.

Nobody had spotted it because each campaign looked acceptable in its own report. The pattern only appeared when we counted purchases per campaign across the whole account.

It changed my first question in any audit. Before asking whether an ad is good, I ask how many results each campaign gets and whether it lives long enough to use them. Our recommendation for that account was to consolidate into one broad campaign and move the weekly promotions into a separate side campaign instead of rebuilding everything each Monday.

As a COO, I have learned that data becomes valuable when it explains why something is happening, not just what is happening. In professional training, tracking enrollment numbers and course completion rates is useful, but examining assessment results, learner feedback, and certification outcomes provides a clearer picture of whether training is delivering real value. LinkedIn's 2024 Workplace Learning Report found that 90% of organizations were concerned about employee retention, highlighting the importance of career development and learning opportunities. One insight that changed my approach was recognizing that high participation does not automatically mean high impact. A program can attract many learners yet fail to close critical skill gaps. That realization strengthened the focus on connecting operational metrics with measurable learning outcomes, helping identify where programs need improvement and where resources can create the greatest value. At Invensis Learning, this outcome-focused mindset is especially relevant as organizations seek to build capabilities in project management, IT service management, agile, and cybersecurity. Ultimately, better operational decisions come from measuring progress by the skills and performance improvements achieved, rather than activity alone.

As the owner of The Monterey Company I am responsible for operations along with sales and marketing, so I can speak to how data shapes those decisions.

I lean on CRM and sales data more than platform dashboards, since the dashboards tell me what happened on the ad or the website while the CRM tells me what happened to the business. I look at where leads come from, how many turn into customers, average order value, and revenue by channel, and I use that to decide where time and money go next.

The insight that changed my approach most is that lead volume and revenue do not always move together. A channel can look like it is working on activity alone while the sales team spends its time on inquiries that never close. Once I started judging channels by qualified leads and closed business instead of raw numbers, it changed where we put our effort and how we measure whether marketing is paying off.

We collect data on pretty much any and everything. One of our biggest operations goals is always to optimize efficiency, and that is one area in particular where I have found data analytics to be especially helpful. Gathering data on things like how long particular processes take and ROI on specific processes really help give us insight into what kind of improvements can and should be made if the goal is optimizing efficiency. Not only that, but then when we implement changes, we can then compare new data analytics to what was assessed prior to see if our changes were helpful in the way we needed them to be.

The data that's changed how I make operational decisions is cost data broken down to a level I can act on. As CEO, I'm not the AWS engineer anymore, and my hands-on expertise isn't as deep as it used to be. When I opened our Amazon Web Services bill, I couldn't find what we were spending on EC2 storage. All I saw was a line item called "EC2-Other," which told me almost nothing.

Our own platform's cost report breaks that same spend out by resource type, so storage and other charges show up as separate line items. Instead of running reports in the AWS console or asking an engineer to dig, I can see everything in one place and ask a specific question about a specific number.

The insight for me is that data only drives decisions when it's broken down to a level the decision-maker can act on. A number that's rolled up so far that only an engineer can explain it doesn't help the person running operations, no matter how accurate it is.

The insight was that 70 percent of our support work was not support.

Before we automated anything, I exported one month of tickets, about 1,300, and tagged each one by hand: what the customer wanted, and whether answering it needed a decision or just a lookup. Seventy percent were lookups. Where is my order, send the invoice, which accessory fits this machine. Every answer already existed in the ERP or the product database. A person was the bridge, and the bridge was the bottleneck.

That changed the approach completely. The plan had been to hire for the seasonal peak. The data said hiring would add more bridges. We connected the helpdesk to the order system instead, kept the humans on the decisions, and the team now handles spring without seasonal staff.

The method, if it helps anyone: count real work items before you draw a process map. The map will show one box labelled "answer ticket". The count shows where the volume lives.

The report, which I focus on most closely, is Google Search Console. One of the metrics in it influenced my content creation strategy. On the cfomatrix.in blog, we began to publish new content regularly, but the number of indexed pages was about the same as the number of pages found by crawlers. Adding new resources would have no value, and we had to solve the technical problems of structured data, 404s, and canonical tags.

Now we control this situation, and I monitor the proportion of found and indexed pages in Google Search Console weekly. If the metric is low, it means we have technical issues on the site rather than a need to create more content.

This metric seems useless to me, and I am not sure if it has helped my blog's growth. However, I would rather have an honest answer about the current capacity of the blog than an assumption based on guesswork.

Decision-making moves from just responding to situations to being proactive in interventions when we no longer see data as just a reporting mechanism for performance indicators but also for health diagnostics for our teams. For my experience of being involved in the establishment of the global delivery teams, I have realized the importance of having analytics as a tool to track the relationships between resource usage and delivery speed. This allows us not only to make decisions on scaling based on the quantitative data about how many resources will be able to absorb this load while maintaining quality but also to make a very fundamental conclusion that peak resource utilization is not an essential indicator for sustainable success. During the first years of my career, I thought that working at full capacity means operational effectiveness. However, there are long-term statistics collected all over multiple engagements with clients that show that when the utilization is too high, there are both stagnating delivery speed and a large number of escalations. With data, I understood that if there is not buffer, the team is simply unable to think or solve any difficult problems. This approach made me change my attitude towards capacity planning completely. Instead of waiting until the team is maximally utilized before hiring newcomers, I initiate the hiring process as soon as the indicators reach their leading values. In this way, we secure a healthy buffer to keep the pace of deliveries and to avoid burning out. By concentrating on the delivery speed rather than the number of hours worked, we develop a system that supports long-term stability instead of chasing the short-term success.

We treat data as the backbone of operational choices: sales, inventory, fulfillment and website UX decisions are driven by customer behavior and order flow analysis rather than gut feeling. We track product-level demand, shipping times, return reasons and onsite conversion signals to prioritise stock allocation, supplier cadence and site updates.

One insight that changed how we operate was recognising that conversion drops were tied less to price and more to delivery predictability. After linking shipping performance to on-site messaging and inventory placement, we shifted to prioritising in-stock visibility and clearer delivery ETAs, which aligned customer expectations with fulfilment capacity and reduced avoidable cancellations.

Data analytics makes operational decision-making more effective by replacing assumptions with measurable insights into costs, efficiency, supplier performance, and resource allocation. I would prioritize tracking procurement lead times, inventory turnover, delivery reliability, and operating expenses to identify problems before they affect business performance. One particularly valuable insight is that the lowest purchase price does not always translate into the lowest operational cost. For example, a supplier offering hardware at 10% less may ultimately cost more if delayed deliveries, compatibility issues, or replacement requirements disrupt operations. This changes the decision-making approach from focusing primarily on upfront savings to evaluating total cost of ownership and long-term reliability. I recommend using centralized dashboards, reviewing performance trends monthly, and comparing supplier performance against clearly defined benchmarks. Data should also guide inventory planning by identifying frequently requested products and potential supply shortages. The real value of operational analytics is not collecting more information, but identifying the decisions that improve efficiency, reduce risk, and protect profitability.

I run operations at a marketing agency for service businesses, and the number I watch most is the gap between a lead arriving and the first reply going out. That one metric changed how I structure work.

MIT research found you're 21x more likely to qualify a lead if you respond within five minutes. Once I took that seriously, follow-up became a timed step in the workflow, with an owner and a clock on it. Before that I'd have filed it under tasks someone handles when the inbox clears.

It also changed what I open first on any report. Traffic and rankings come second now. The first thing I look for is the time between a form fill and the first touch. In the service businesses I see, that gap often runs to hours, and nobody notices because the CRM only shows that a lead exists.

The setup is small. Track two timestamps, lead created and first reply sent, and review the median every week. Automate a text and email inside a minute, then have a person pick up the conversation. Once that median is on the page, decisions about ad spend, staffing, and office hours get a lot easier to defend.

Most operating reviews I sit in treat data as a report card rather than a decision tool. Teams collect dozens of measures and act on none of them, because no measure is tied to a decision someone owns. Data becomes decoration once that link is missing.

The insight that reshaped my approach was simple. A metric only earns its place when a specific threshold triggers a specific action by a named owner. I now build every dashboard backward from the decisions it must support, and I remove any measure that cannot change one.

That discipline shrinks the dashboard and sharpens the conversation. Weekly reviews stop debating what the numbers mean and start confirming what happens next. The first recurring decision with a clear trigger usually proves the model faster than any dashboard redesign.

My rule for analytics is that a metric has to change a decision, or it shouldn't be on the dashboard. Most operational reporting tells you what happened. The useful question is what you'll do differently because of it. When I started applying that test, about half of what we tracked turned out to be reassurance rather than information.

The insight that changed my approach came from cost data, not growth data. Software spend in a growing company behaves like a subscription nobody remembers signing up for. Every team adds tools, nobody owns the decision to remove them, and the bill grows quietly because no single line item looks alarming. When we compared what we were paying for against what people actually used, the gap was large enough to matter. Cutting it saved roughly $2M a year in SaaS costs, without removing anything teams relied on.

The lesson I took from that is that costs deserve the same analytical attention as revenue, and usually get far less. Growth metrics have champions. Spend metrics have nobody, so they drift.

The same discipline applies to the funnel. Lead volume is the number everyone celebrates, but on its own it tells you very little. Lifting leads 27% matters, but improving free-trial conversion 12% often matters more, because it compounds on every lead you already have. I'd rather fix the leak than pour in more water.

Data doesn't make decisions. It makes the expensive ones harder to avoid.

I build the analytics infrastructure that operations leaders depend on. I don't make the decisions, but I see which data actually changes behavior and which just sits in a dashboard. The gap between those two is bigger than most people think.

At Softline Solutions I manage a GCP data platform covering 1,437 client accounts. BigQuery, Kafka, Flink, Airflow. Before I got involved, operations teams pulled numbers from batch reports that ran overnight. A manager would ask a question at 9am and maybe get an answer by lunch. That's not analytics, that's archeology.

We moved core ETL from Airflow batch to Flink streaming. Reports that took 2-3 hours now show up in under 10 minutes. Pipeline failures dropped from 15 per week to under 2. And here's what matters: when leaders get a number in minutes instead of hours, they actually use it. They check before a meeting instead of guessing. They catch a billing anomaly on Tuesday instead of finding it in the Friday report.

But the one insight that changed my thinking came from MyTona, where I worked on data pipelines for Cooking Diary (mobile game, 22M+ downloads). We built anomaly detection for player spending. The system flagged unusual drops in in-app purchases. Operations and product leads had the same alerts, same Grafana dashboards.

The product team acted on those alerts within hours. Operations mostly ignored them. Same data, same alerts, completely different response.

It came down to something simple. Product alerts were tied to a specific action (adjust a promotion, tweak a price point, push a notification). The operations alerts just said "something looks weird." No clear next step baked in.

That changed how I build systems now. At Softline, every alert has what I call an "action line." Not just "Kafka consumer lag is up 40%." Instead: "Consumer lag up 40%, likely cause: [X], action: scale consumer group in cluster Y." Small design choice. But it turned monitoring from something people glanced at into something they acted on.

I also learned that reducing noise matters more than adding signal. We cut PagerDuty alerts by 60% and response times got faster. People stopped ignoring them because the ones left were real.

So my answer is this: the data that changes operational decisions isn't the fanciest. It's data that arrives fast, points at a specific problem, and tells you what to do next. Everything else is just a report nobody reads.