Measuring Copilot Value: Adoption Metrics That Go Beyond Active Users

M365 FM - Measuring Copilot Value - Adoption Metrics That Go Beyond Active Users 00:00:00 Speaker: An executive asks a simple question how's copilot going? The answer comes back fast. Seventy two percent active users. Everyone nods. The slide gets a green arrow. The meeting moves on, but look at what that number actually says. Active means someone opened it. Someone clicked something once, somewhere inside a window of time. It doesn't say the work got faster. It doesn't say the work got better. It doesn't say anything changed at all. So today we're building the whole chain. We start with usage, then move to impact, then to cost per outcome and end with a report an executive can actually act on. And if you're tired of reporting licenses instead of value, subscribe to M365 FM. This is that kind of show. But before we measure anything new, look at what the Standard Model really counts. Sponsor segment. Stellar Migrator for exchange. A quick word from today's sponsor. And it connects to this topic more than you'd think. Copilot doesn't create value out of nothing. It works on what you already have your mail, your files, your meetings, your chats. If that data is scattered, half migrated, or sitting in old systems, copilot has less to work with. And then the results look weak and people blame the tool. Mailboxes are a big part of that. Email is where a huge share of daily work lives. So a migration that stalls or never really finishes quietly limits what copilot can find and summarize. Stellar migrator for exchange is built for this kind of job. It's a tool for exchange migrations, helping teams move mailboxes between environments. If you're stuck in the middle of a move, it's worth a look before you judge copilot by its output. Okay, back to the problem and why the first metric breaks the model behind active users. Let's start with the definition. Most people never actually read it. An active user in the standard Model is someone who performed at least one copilot enabled action inside a twenty eight day window. One action. That's the bar. An action can be a prompt in teams, a chat in copilot, a rewrite in word, a summary, and outlook. If it happened once in those twenty eight days, that person counts so that seventy two percent from the opening. It doesn't mean seventy two percent of your people work differently now. It means seventy two percent touched it at least one time. Why does everyone use this number? Because it's easy. The data is already sitting there. Nobody has to build a survey or time a task or sit next to anyone. It shows up on a chart the moment the licenses go live. Easy to collect, easy to chart, easy to defend because it's a fact. Nobody can argue the number is wrong. They can only ask what it means. And that's a much harder question. So most meetings never get there. That's the first problem. The metric survives because it's safe, not because it's useful. But there's a second problem and it sits one level deeper inside. The active user number is an assumption, a quiet one. The assumption is that activity equals value. If someone used it, it helped. If more people used it, it helped more. If usage goes up, the investment is working. That change sounds reasonable, but every link in it is a guess. Think about measuring how much work happened by counting badge swipes at the door. Everyone swipes in. The number looks great, ninety five percent attendance, but a badge swipe tells you a person entered the building. It doesn't tell you what they did at their desk. It doesn't tell you if the project moved. It doesn't tell you if they sat through four meetings, that should have been emails. Nobody would run a business that way. Nobody would hand the board a badge report and call it productivity. And yet that's the exact structure of the active user metric. It counts entry. It doesn't count work. The model confuses presence with progress. And because the number is clean, the confusion hides. Here's what makes it worse. The metric can only go one direction. In a rollout. You assign licenses, people click, the line rises. Almost any rollout produces a rising line, good or bad, a metric that rises no matter what can't tell you whether you're winning. So what does a leader do when active users hits eighty percent and nothing else moves? Why usage is not impact. Here's the answer. You stop treating the number as one thing because is copilot working is really three questions stacked on top of each other, and each one has its own evidence. Layer one is adoption. Did people use it? That's what active users tries to answer. Layer two is behavior change. Did the way people work shift? Do they draft differently? Prepare for meetings differently? Search differently. Layer three is business outcome. Did something the company cares about move cycle time, cost, revenue, error rates, customer response times. Each layer sits on top of the one below it, and that's why people assume they travel together. If adoption rises, behavior must follow. If behavior shifts, outcomes must follow. But in reality, they don't. Each layer can move on its own. Adoption can climb while behavior stays exactly where it was. Behavior can change while no outcome improves and an outcome can improve for reasons that have nothing to do with copilot, like a slow season ending or a new hire finally ramping up. So the layers are linked by hope, not by mechanics. Every step up has to be shown, not assumed. Let's make that concrete picture. A user in operations. She opens copilot every morning, every single day, without fail. She asks it to summarize her inbox. Long threads, short threads, newsletters, the lot on the dashboard. She's a model user. High frequency, steady habit, the kind of person you'd feature in a success story. Now ask what actually changed? Half those threads were never going to need a reply. Some were distribution lists she'd have skimmed for two seconds. The summary didn't save her an hour. It gave her a nicer way to read things she didn't need to read. She's active, she's loyal, and the work is the same because the summaries covered email nobody needed summarized in the first place. Adoption layer. Green behavior layer one. New habit. No new result outcome layer nothing. Now flip it. Take a finance analyst who uses copilot twice a week, but only for one thing. First drafts of variants. Commentary in the monthly close. That task used to eat most of the day. Now it takes an hour and the review step catches the errors on the dashboard. He looks like a light user. Maybe he even falls below a threshold someone set for engaged. But he's the one who moved the clothes by a full day. So the person your chart celebrates may be doing nothing useful, and the person your chart ignores may be carrying the whole business case. That's what happens when the layers come apart. The metric can't tell them apart, so you can't either. And this isn't just a reporting problem, it becomes a money problem. In most organizations, the license renewal conversation arrives about a year after rollout. Someone builds a deck, someone needs evidence, and what's sitting there ready to go is the adoption data seventy something percent active usage up every month. So the renewal case gets built on layer one. Then the budget gets approved on layer one. Then the expansion to the next ten thousand seats gets justified on layer one. And nobody ever checked layers two and three. That's the real cost. Not that the metric is wrong, it's that real decisions with real budgets get made on evidence that can't support them. And when finance comes back later and asks what the money bought, there's no answer. Only an old chart that still points up worse, the opposite can happen to a team with strong layer three results, but modest usage numbers can lose licenses in a cleanup because the only thing anyone looked at was activity. Both mistakes come from the same place, confusing the layers. So to separate them, you need to know what each tool can show you and where it stops. And the first place to look is the one most admins already have open. The copilot dashboard. Copilot dashboard. What it actually shows. Start with where it lives. The copilot dashboard sits inside Viva Insights. You can reach it from the Viva Insights app in teams or from the web. Most people never go looking for it because nobody told them it was there. Who can see it? Two groups, mostly individual users with a copilot license, can see their own view, and leaders and admins can see the aggregated view for the organization. That second view has gates on it. The person needs a Viva Insights license or the right access through the copilot license itself, plus the right role. Usually that's something like insights business leader or an admin who assigns that access. Microsoft changes these details over time, so check the current documentation before you promise anyone access. And one more gate. The data has to be there. The dashboard needs enough licensed users in a group before it shows anything for that group. Small teams often see nothing at all. That's by design and we'll come back to why. Now what's inside? Three core views readiness. Adoption impact readiness comes first. It looks at the setup around copilot who's licensed, who's using the copilot depends on and whether your people are already working in the right places. It's a before view. It answers a simple question are we set up for this to work? Adoption is the one most people live in. This is where the usage numbers sit, and impact is the view that tries to connect copilot use to how people work. It compares users to similar non-users looking at things like meeting time and email time. It's a first step to what layer two. Now the metrics themselves, because this is where the dashboard earns its keep active users. The one we already took apart enabled users and how many of them did something in the window actions per user. This one adds depth instead of did they touch it? It asks how many times someone with two actions a month and someone with sixty don't look the same here. App level usage. This splits activity by where it happened teams, outlook, word, Excel, PowerPoint, and the chat experience so you can see where people actually reach for it and retention. This shows how many people who used copilot in one period came back in the next. It's the closest thing the dashboard has to a habit signal. Those four give you real texture, not just a count, but a shape where people use it, how often and whether they stay. So what is the dashboard designed to answer? It's designed to answer questions about adoption. Who's using it where, how much, whether it sticks. And it gives you a starting view of whether copilot users work a bit differently from people who don't. That's a genuine job, a useful one. If your rollout is stalling in one region, this is where you see it. But here's what it isn't built to do. It can't tell you what the work was. A summary of a board paper and a summary of a lunch invite count the same. It can't tell you if the output was good. It can't tell you if a person saved ten minutes or lost ten. And it can't tell you what happened to the business cycle. Time cost per case errors in the final document. None of that lives here. The dashboard counts actions. It was never meant to judge them. That distinction matters because the dashboard is polished, the charts look finished, and a finished looking chart invites people to read it like a verdict when it's closer to a first draft of one. So treat it as what it is, the first layer delivered well, but even the first layer has weak spots, definitions that shift, populations that blur, and numbers that mean less than they seem to. So the next question is how reliable it really is and how to read it without fooling yourself. Reading the adoption metrics without fooling yourself. Start with a trap hiding in the first number. There are three populations on that dashboard and they get mixed up constantly. Assigned licenses enabled users. Active users. Assigned licenses is what you bought and handed out. Enabled users is who can actually use copilot right now because the license is switched on and the apps are set up, active users is who did something in the window. Those three numbers can be far apart, and when someone says seventy two percent, you have to ask seventy two percent of which one. If it's seventy two percent of enabled users, that sounds great, but if half your assigned licenses never got enabled, the real story is different. Now the question is how many of the people you paid for are doing anything at all? Same chart, very different meeting. So always write down the denominator every time a percentage without a base is a mood, not a measurement. Now let's go one level deeper. Say the population is clear. What does active hide inside it? This is where frequency and depth come in. Actions per user is the first signal. A person with three actions in a month and a person with ninety are both counted as one active user, but they're not the same person and they're not the same investment. So look at the spread, not the average. An average of twenty actions can mean everyone does about twenty. Or it can mean five people do two hundred and everyone else does almost nothing. The average hides that completely. And the second picture is a very different rollout. Then there's rhythm. How many days per week does someone use it? Two actions in one day is a burst. Two actions on two separate days starts to look like a habit. And habit is the thing that matters. Because work isn't one off. A tool changes how someone works when it shows up in the normal flow week after week without a reminder. Someone who uses it three or four days a week has probably found a place for it. Someone who uses it once a month is still experimenting or has given up quietly. Next, the app level split. This one tells you more than most people expect. In a lot of organizations, the pattern looks the same. Teams and outlook are heavy. Meeting recaps, email summaries, chat questions, word and Excel are light. PowerPoint is somewhere in between. What does that signal? Teams and outlook are the easy places. The prompts are short, the payoff is quick, and the risk is low. Summarizing a meeting costs you nothing if it's slightly off. Word and Excel are harder. They need better prompts, cleaner data, and more trust in the output. A draft contract or a financial model isn't something you accept on faith, so light use there often means people haven't learned the workflow or don't trust the results enough yet. And here's the part that matters for value. The heavy apps and the valuable apps aren't always the same. If most of your usage sits in quick summaries, you may be paying for convenience. While the tasks that eat real hours go untouched, the distribution doesn't tell you which is right, it tells you where to look. Last piece retention. Retention shows who came back and the shape of it is revealing. Plot. The people who used copilot in month one. Then see how many used it in month two. Then month three. A healthy curve drops a bit, then flattens a core group, settles in a week curve keeps sliding. People try it once, maybe twice, and disappear. That sliding group is easy to miss because they still count in the early numbers. They were active in the first window. They showed up in the launch spike, then they left and the cumulative chart still looks fine. So the question isn't how many people tried it, it's how many are still there after the novelty wore off. That's the number that predicts whether the rollout holds. But look at what all of this gives you. who used it, how often in which apps and whether they stayed. That's a clear picture of who it's not yet a picture of where in the organization, or why it differs from team to team. And a company wide view smooths all of that into one calm line. So adoption tells you who, and the next thing to ask is where and why. Segmenting adoption by role. Org and manager. Take the company wide line and ask what it's made of. It's an average, and an average is a blend of everything underneath it the good, the dead, the strange seventy two percent active could mean every team sits near seventy two. Or it could mean one division is at ninety five and another is at thirty, and the math just lands in the middle. Those two companies need completely different next steps, but on the chart they look identical. That's the floor. The average hides every useful signal because the useful signals live in the differences where it works, where it doesn't, and what separates the two. So you cut the data and there are four cuts worth making. First function sales, finance, legal support, engineering, HR, different functions do different work so copilot lands differently in each. If support is flat and legal is climbing, that's not noise. That's a clue about which kinds of tasks fit level. Individual contributors, managers, directors, executives, executives often have the licenses and the lowest usage. Their calendars are full, and their work is mostly conversation. That's worth knowing before you use their numbers as a signal for anyone else. Location, region, country office language support, time zones, local training, and even local data rules can shape how much people reach for it. A dip in one country might be a language issue, not a motivation issue. And manager. This is the cut people skip and it's the one that explains the most. Because here's what shows up again and again. When you slice by manager usage clusters around teams, not around roles, not around departments, around the person in charge. Teams follow what leaders model. If a manager opens copilot in a team meeting, asks it a question out loud, shares a prompt that worked. Then the people around them try it. It becomes normal if a manager never mentions it. The licenses sit there and nobody wants to be the first to look like they're experimenting on company time. So two teams with the same role, the same tools, the same training session can end up at opposite ends of the chart. The difference isn't the software, it's whether anyone with authority made it feel ordinary. That changes how you read a low number. A cold team may not have a tool problem at all. It may have a permission problem, an unspoken one when nobody told them it was okay. Now, once you've cut the data, you're looking for two kinds of pockets. The first is high value. Use a group where actions per user are strong, retention holds and the pattern is steady across weeks. These are your best leads, not because they prove business value, yet they don't, but because they're where it's most likely to be hiding. So go talk to them. Ask what they do with it. Ask which task changed. You'll often find the one workflow that's worth copying across the company. The second is the Dead License, a group where people were assigned seats and almost nobody touches them month after month flat near zero. And that's not a failure of the people. It's information. Maybe the seats went out by seniority instead of by workload. Maybe the teams work lives in a system copilot can't reach. Maybe nobody explained what it was for. Whatever the cause, those licenses cost the same as the busy ones. And they return nothing while they sit idle. Seeing both pockets side by side is what the average never allows. You find where to invest more and where to stop paying or fix something first. But notice what segmentation gives you. It points. it says, look here, look at that team. Look at this manager. What it can't tell you is what happened inside those teams. A busy group is still just a busy group. The cut shows where activity clusters, not whether the work itself got any different. And that's the real question, not who is using it and not even where. What changed in their work? For that, you need a different kind of data, one that watches behavior instead of clicks. Viva insights. The behavioral layer. The copilot dashboard counts, clicks. Viva insights counts how people spend their working week. That's the shift. Same product. Family. Different question. Viva insights is built on collaboration signals from Microsoft three hundred sixty five email, meetings, chats, calendar, and from those signals, it builds a picture of how work gets done for areas matter most here, collaboration, who people work with, how much time goes into messages and meetings, and how wide or narrow that network is. Meeting load, how many hours sit on the calendar, how long the meetings run, and how many were back to back with no gap focus time. The uninterrupted blocks where someone can actually do deep work, writing, analysis, that kind of thing, and after hours work emails sent at night meetings that run into the evening weekend activity. 00:16:25 Speaker: Notice what these have in common. None of them is a co-pilot number, their work numbers. And that's exactly why they matter. If copilot changes how someone works, these are the places the change should leave a mark. Less time in email, shorter meeting prep. More focus time because the drafting got faster. Now, a point that trips people up. There are two ways into this data and they aren't the same thing. The first is the copilot dashboard we just covered. It's the ready made view, curated charts, fixed definitions, and a short list of questions it was built to answer. A leader can open it without any training. The second is the Viva Insights Analyst workspace, and this one is a different animal. Here you build the question yourself. You pick the population, the time window, and the metrics. You define a group of copilot users define a comparison group and run the query. You can filter by organization, by role by region, and then pull the results into power BI. If you want to go further, the copilot dashboard gives you the answer someone else decided you'd need. The analyst workspace lets you ask your own for measuring value. That difference is huge. A fixed chart can't match your pilot cohort against a matched control. The workspace can, but it comes with gates and the gates are on purpose. Running advanced queries usually takes a specific role in most setups. That's the insights analyst role assigned by an admin. Not everyone gets it, and nobody should get it. By default, roles and licensing requirements shift over time, so confirm the current rules before you plan around them. Why so strict? Because this data describes people how many hours someone spent in meetings when they send email, how often they worked at night in the wrong hands. That stops being insight and starts being monitoring. So Viva insights builds in privacy controls. Results are aggregated, small groups get suppressed, which is why a tiny team might see blank charts. Names are de-identified in most analyst views. The point is that you can learn how a population behaves without learning what one person did on a Tuesday. That isn't a limit on measurement, it's the condition that makes measurement acceptable. If employees believe the tool watches them individually, they stop trusting it, and then they stop using anything you roll out. Will spend real time on that later. Now, where does copilot itself show up in all this? Viva insights includes copilot specific metrics, things like the number of copilot actions, the apps, where they happened and which kinds of activity copilot assisted with meeting summaries, email drafting, chat use document work. And here's the useful part. Those usage metrics can sit right next to the metrics. So you can ask a pointed question for people who use copilot in outlook four days a week. Did time spent in email change for people who lean on meeting recaps? Did they skip meetings or shorten the ones they attended? Did focus time grow? That's the bridge between layer one and layer two. Usage on one side, behavior on the other in the same data set for the same people. But there's a catch and it's a big one. A behavior number on its own means almost nothing. Say your copilot uses average eleven hours of meetings a week. Is that good? Is it down? Down from what? You can't tell without knowing where they started. Any figure you pull is a snapshot of one day and you'll find a story in it. Whether it's true or not. Behavior data is only as useful as the before picture, and most organizations don't have one. Baselines. The step everyone skips. Here's what usually happens. The rollout goes. Live. Licenses get assigned. Three months later, someone pulls the Viva Insights numbers and finds that copilot users spent nine hours a week in meetings. Someone else says that seems low and a story starts, but low compared to what Nobody knows. There's no earlier number. So the conversation turns into opinion and the opinion with the best slide wins. That's what measuring after launch gives you. Stories, not evidence. A number with no starting point can't show change. It can only show a state. And a state can be explained any way you like. If meeting time is down, co-pilot did it. If it's up, people are busier and co-pilot is helping them cope. Both stories fit because nothing anchors either one. A baseline is the anchor. It's the picture of how work looked before the tool arrived. Taken the same way, you'll take the picture afterward. Same people, same metrics, same definitions. Then any difference you see is at least a candidate for change instead of a guess. So what do you capture? Start with the signals. Viva insights already tracks meeting hours per week email volume both sent and received, and the time spent in IT focus time, meaning the uninterrupted blocks after hours work. If that's a concern for your people, then add the ones Viva can't give you. Document turnaround is the best example. How long does a proposal take from first draft to approval? How long from a customer question to a sent answer? Those timestamps live in your own systems. SharePoint, a ticketing tool, a CRM, and they matter because they sit closer to layer three, the business outcome than any calendar metric ever will capture them for the exact groups you plan to license, not the whole company, the pilot cohort, and whoever you'll compare them with. Now, how long a window a single week is a snapshot and snapshots lie. One week might hold a product, launch a holiday, or a re-org announcement. So you want several weeks at least enough that the normal rhythm shows through the noise. Four to eight weeks is a reasonable range for most teams. And then there's the calendar problem, which catches almost everyone. Work isn't flat across the year. Finance gets crushed at quarter end sales sprints before the deadline, support spikes after a release, and nearly everyone slows down in the summer and again in December. So picture the mistake you capture your baseline in the last weeks of a quarter. When meeting loads are brutal, you roll out copilot and measure again in a quiet stretch in August, meeting time drops by a third. Great news. Except the season did that. Not the tool. The fix is simple if tedious. Compare like with like quarter end to quarter end summer to summer. If your window is short, check what else was happening in those weeks. Or better use a year of history so you can see the seasonal pattern and subtract it. Now the awkward case. The rollout already happened. Licenses went out six months ago. Nobody captured anything. And you're being asked for results next week. You can't go back and observe, but you can often rebuild. Viva insights keeps historical data, so the behavior metrics from before the rollout may still be there. Pull the months before each person's first copilot action and treat that as the baseline for document turnaround. Your own systems hold timestamps going back years. Ticket closed times. Approval dates. File creation dates. They were recorded for other reasons and they work here too. It won't be perfect. People may have changed roles, the company may have reorganized, and the users who got licenses first were probably not a random sample of employees. So label the rebuilt baseline for what it is a reconstruction and say so in the report. A reconstructed baseline with honest caveats still beats no baseline. It turns. I think it helped into. Here's what we can show and here's what we can't. But a baseline only gives you one side of the comparison. It tells you where the copilot users started. What it can't tell you is what would have happened to those same people. Anyway. Everything else in the business kept moving too. So once you know where they began, you need someone to stand next to them. Control groups and fair comparisons. Say you have your baseline. Eight weeks of clean data. Same people. Same definitions. You roll out copilot. Three months later, you measure again. Email time is down eight percent. Good news? Maybe. But before you write the slide, ask what else happened in those three months? A new manager arrived in one team. A reorg moved two groups. The company cut a weekly status meeting. Quarter end came and went. A competitor launched something and everyone changed their priorities. That's the weakness of before and after on its own. Everything else changes too, and the data can't tell you which change did the work. If the tool gets credit for all of it, you're not measuring copilot, you're measuring time. So you need a second line on the chart. A group of people who lived through the same three months with the same reorgs, the same deadlines, the same calendar, but without copilot. That's a comparison group. And the logic is simple. If both groups improved by eight percent, copilot did nothing special. If your licensed group improved by eight and the other group by two, the gap is what you can start to talk about. Six points, not eight. Now how do you build one? The first way is matching. You take the people who got licenses and you find people who didn't who look like them. Same function, same level, same location, similar meeting load and email volume in the baseline period. The closer the match, the fairer the comparison. The analyst workspace in Viva Insights can help here, because you can define both groups and run the same metrics on each. But the matching itself is your job. It takes judgment about which traits matter for the work in question. The second way is staggered rollout. Instead of licensing everyone at once, you go in waves. Wave one gets seats. Now wave two gets them in ten weeks. Wave three after that. And that gives you something for free. While wave one is using co-pilot, wave two is still waiting. They're doing the same kind of work in the same company during the same weeks. Wave two is your comparison group, and nobody had to be denied anything permanently. They just had to wait their turn. That's a natural experiment. You're not building something artificial in a lab. You're using a decision you are going to make anyway. Phased deployment and treating its timing as data. Most large rollouts are phased already for budget or support reasons. The only missing step is deciding upfront to measure the gap between waves instead of ignoring it. But there's a pitfall here, and it's the one that quietly ruins most pilots. Early adopters are not average employees. Think about who ends up in wave one. Usually it's volunteers or people handpicked because they're curious, comfortable with new tools, and likely to give good feedback. Or leaders, favorites or the IT adjacent teams who asked first. Those people were already different before copilot arrived. They may already work faster. They may already be better with prompts, or at least more willing to try. So if wave one beats wave two, you can't tell how much came from the tool and how much came from the people. You see this in the baseline too. If you look at the early group, often starts out ahead on the very metrics you're about to track. Which means any improvement you measure may be them doing what they'd have done anyway. A few things help check the baseline gap first. If the groups start far apart, say so and compare change rather than levels match on past behavior, not only on job title and where you can assign wave order by something unrelated to enthusiasm, like office or alphabet or random draw. So curiosity isn't picking your sample. None of this makes the comparison perfect. Real organizations never allow that, but it makes the claim fair, and a fair claim survives a finance review. So now you have structure, a baseline for where people started, and a comparison group for what would have happened anyway. But structure answers the question of when and against whom. It doesn't answer what you're measuring. Meeting hours and email volume are wide, blunt numbers, and the work behind them is a thousand different things. So the next decision is the unit. And in this case, size matters. Choosing the right unit. Task level thinking. Look at what the typical report measures. A job title, a department, sales, finance, HR and the question it asks is whether copilot helped that group. But a department isn't one kind of work. It's hundreds of small activities bundled under one name. A sales team writes proposals, preps for calls, updates the CRM, answers pricing questions, and sits through forecast meetings. Copilot might transform one of those and do nothing for the rest. So when you average across all of it, the one task that moved gets buried under the ones that didn't ten percent better on one activity, zero on nine others. And the department number barely twitches. You'd conclude copilot did nothing. It did something. The unit was too big to see it. Same problem at the job level. Analyst covers a person who spends mornings pulling data and afternoons writing commentary. Different tasks, different results. Job level numbers are too blunt to tell them apart. So shrink the unit. Measure tasks. A task is a piece of work with a clear start, a clear end, and an output. You can point at drafting a first version of a document summarizing a long thread or a meeting. Searching for an answer. Buried in files. Analyzing a set of numbers. Scheduling something that takes six messages to settle those five cover most of what people actually reach for copilot to do, and each one behaves differently. Drafting is about speed to a first version. Summarizing is about reading. Time. Searching is about how long until someone finds the thing. Analyzing is about both speed and accuracy, and scheduling is mostly about coordination overhead. Now you can't measure every task you drown, so you pick. And the choice matters more than the measurement itself. Start with frequency. A task that happens twice a year can't move a business even if copilot nails it. You want work that repeats ideally daily or weekly across many people. That's where small gains add up, then measurability. Can you see when it starts and when it ends? A task with a ticket, a document or a timestamp is measurable. A task that lives only in someone's head, like thinking through strategy isn't. Skip those for now and tie it to a business process. This one separates useful measurement from busywork. A task should sit inside something the company already tracks. A proposal feeds a sales cycle. A case summary feeds a resolution time. A closed commentary feeds the monthly close. If the task connects to a process with a number attached, then saving time on it can show up somewhere real. If it floats free, the savings have nowhere to land. So those are the three filters. Frequent, measurable, connected. Then for practical criteria, help you rank what's left volume. How many times does this happen per week across how many people a task done five hundred times a month. Beats one. Done twenty. Duration. How long does it take today? A thirty second task can't save you much. A ninety minute one has room to move. Error cost. What happens when it goes wrong? Here the answer cuts both ways. A task where mistakes are cheap is safe to test first. But a task where mistakes are expensive is where quality gains would matter most. So you need to measure carefully there and not avoid it. And owner willingness. This is the one nobody puts on a spreadsheet. Somebody has to own this task. Agree to be timed, share the numbers, and change how the work gets done. If the team lead doesn't care, the measurement dies in week three. A good task with a reluctant owner is worse than an average task with an eager one. Score your candidates on those four. You'll usually land on three to five tasks worth following, not fifty, and that shortlist becomes the spine of everything after the baseline gets captured. For those tasks, the comparison runs on those tasks. The survey asks about those tasks. The cost per outcome gets calculated on those tasks. So with the tasks chosen, the next move is the one everyone wants to jump to. First measure the time measuring time savings at the task level, there are three ways to measure time on a task. None of them is perfect. Each one catches something the others miss. Method one is timed observation. It's the oldest approach there is and the cleanest. You pick a task from your short list, say writing a first draft of a customer proposal, you get a small group of people to do it two ways, once the way they always have. Once with copilot. Same type of task, same level of difficulty, and someone with a stopwatch or a screen recording, or just a note of the start and end time. Then you compare not the feeling of it. The minutes two details make or break this. first, don't use the same document twice. If someone writes the proposal once, then rewrites it with copilot. The second round is faster because they already know the content, so split the group or use similar tasks with different inputs. Second time the whole job, including the review a draft that appears in two minutes but takes thirty minutes to fix, hasn't saved anything. It moved the effort to a different step. Observation is slow and it doesn't scale to a thousand people, but it gives you the most trustworthy number you'll get. Treat it as your anchor and use it to test the other two methods. Method two is system timestamps. This one asks nobody to do anything new. Your systems already record when things start and finish, a document gets created. Then a draft gets shared. Then it gets approved. A ticket opens, then it closes. A case arrives, then someone responds. So you take the task from your baseline, the one you captured before rollout, and you measure the same interval after creation to approval, open to resolved. And because it's recorded by the system, there's no recall problem, no flattering rounding and no survey fatigue. You can also split it by who used copilot proposals drafted by licensed users in wave one against proposals drafted by people still waiting in wave two. Same timestamps. Same process. A gap you can defend. The limit is that timestamps measure elapsed time, not effort. A document might sit in someone's inbox for three days waiting for approval. Copilot didn't cause that and can't fix it. So pick intervals that mostly reflect the work itself and be careful about intervals dominated by waiting. Method three is structured self-report. This is the weakest of the three and the only one that reaches everyone. People are asked how long a task took them, but the structure is what keeps it honest. You name one specific task. You set a recall window like the last five times you did this or the past two weeks, and you ask for a before and after comparison on that same task. Not a general feeling about being faster. Why so strict? Because memory flatters. Ask someone how much time copilot saves them and you'll get a round optimistic number. Ask how long the last three summaries took and you get something closer to what happened. The narrower the question, the less room for hope. Even then, self-report is a signal, not a measurement. Which is why you check it against the other two. Now, a word about the number. You've probably already seen vendor studies and early research report. Big headline figures. percentages of time saved minutes per week speed gains on specific tasks. Those numbers are real in the sense that someone measured them somewhere under certain conditions, but they were measured on someone else's tasks with someone else's data in someone else's company. Your proposals, your approval chains, and your people aren't theirs. So treat a headline number as a hypothesis. It tells you where to look and roughly how big the effect might be. It doesn't tell you what happened in your environment. Your own measurement does that. And if your number is lower than the headline, the headline isn't wrong. Your work is just different. Put those three methods together and you can finally say how long a task took before and after. That's a real result. But look carefully at what it says. It says time was saved. It says nothing about what that time became. A person who finishes a draft twenty minutes sooner hasn't gained twenty minutes of anything yet. Those minutes went somewhere or they went nowhere. And the gap between time saved and time freed turns out to be where most value claims fall apart from time saved to value realized. Take that number you just measured. Ten minutes saved per task. Now multiply it five hundred people, a few tasks a week, and suddenly the spreadsheet says thousands of hours a month looks like a finding. 00:32:51 Speaker: But it's arithmetic, not an outcome. Ten minutes saved across five hundred people is not ten minutes of extra output from each of them. Nobody works that way. Where small gaps pile up into a usable block, a saved ten minutes lands between a meeting and a message. It gets absorbed before anyone can point at it. That's the conversion problem. Time saved is a property of a task. Value is a property of the business, and there's no automatic path from one to the other. So where does the save time actually go for places? And you have to find out which one it is first more of the same work. The analyst finishes the commentary sooner, then writes more commentary. Output rises. That's real and you can count it. Second, better work. The same person uses the time to check the numbers twice or to tailor the proposal instead of reusing a template, output stays flat, but the quality of it goes up. Third rest. The person takes a breath, grabs coffee, ends the day on time. That's not nothing. People who aren't drowning make fewer mistakes and stay longer, but it won't show up on a PNL this quarter and fourth. Nothing. The time just evaporates into the normal drift of a workday. No one decides where it goes, so it goes nowhere. Most organizations never ask which of the four is happening. They assume the first one because the first one sounds like money. Now there's a better way to sort this. Stop thinking of value as one thing. There are at least four types, and each needs its own proof capacity. The team can handle more volume without adding people. Support closes more cases per agent. You prove it with throughput numbers, and only when the work is actually waiting to be done. Quality. The output is better. Fewer errors in contracts, stronger answers to customers. Cleaner reports. You prove it with error rates, review scores, or customer feedback speed. Things move faster from start to finish. A proposal reaches the client in two days instead of five, and the deal closes sooner. You prove it with cycle time, the kind of timestamp we pulled earlier and risk reduction. A mistake didn't happen. A compliance gap got caught. A deadline wasn't missed. This one is hardest to count because you're measuring something that didn't occur, but it can be the largest value of all, especially in regulated work. Each type has a different owner, a different metric, and a different audience. Lumping them under productivity is how a strong result ends up sounding vague and vague is exactly what finance teams distrust. Think about how they've heard this before. Every new tool arrives with a productivity promise. Hours saved, efficiency gained. Then the headcount stays the same, the costs stay the same and the savings never appear in a budget line. So when someone says copilot saves each person two hours a week, finance doesn't hear a result. They hear a claim they've already watched failed. They're not being difficult. They're asking a fair question where did the money go? So answer it directly. Don't lead with hours. Lead with the type of value and tie it to a number. Finance already tracks not. We save two thousand hours, but the close finished a day earlier which let us release the book sooner. Not people are more efficient, but support handled eleven percent more cases with the same team and be straight about what isn't cash. If save time became better work or less overload, say that. Call it capacity or quality, not cost reduction. Finance respects an honest label far more than an inflated one. But notice the limit of everything so far. Timestamps and system data show you the work. They can't show you where a person put the time they got back. They can't tell you whether a draft fell trustworthy or whether a task got easier or just got different. For that, you have to ask people directly. Surveys that produce evidence, not applause. Most copilot surveys ask one question in one form or another. How satisfied are you? And the answers come back warm eighty percent satisfied. A string of comments saying it's great. It's helpful. It's the future. Somebody screenshots the results for a slide. But what did that measure? It measured mood. I like it is a statement about a feeling. And a feeling doesn't need work to have changed people like a good chair. People like a tool that feels clever. Neither one tells you whether a task got shorter, a result got better, or a decision got made faster. A person can love copilot and save nothing. Another can find it annoying and save an hour a week. So satisfaction isn't wrong. It's just answering a different question. It tells you about the experience and you were asked about the change. That's the shift in survey design. Stop asking how people feel about the tool. Start asking what happened to the work. Three habits make that possible. First, name a specific task, not how does copilot help your work? But think about writing the first draft of a customer proposal. One task, one picture in the head. The more specific the task, the less room there is for a general warm glow. Second, set a time window. In the last two weeks or the last five times you did this memory works on recent concrete events. It fails on average as an impressions. So give people something they can actually recall. Third, ask for a before and after on that same task. How long did it usually take you? How long did the last few take with copilot? And what did you do with the difference? That last part matters because it connects straight back to where the save time goes. Notice what you get from that. A number you can compare against your timestamps, a task you can match to your baseline, and a reason in the person's own words for why it worked or didn't. Now, when you ask matters as much as what week two is the first pulse. By then, the novelty is still strong, but people have used it enough to have real examples. This one catches set up problems, can't find it. Doesn't work in this app. Didn't know what to ask. It's early, so treat the savings numbers lightly. Treat the friction reports seriously. Week eight is the second. The honeymoon is over. People who were going to drift away have mostly drifted. Those who remain have found a routine, so their answers about time and task are closer to steady state. And after quarter one comes the third. By now, there's enough history to compare against the baseline and the timestamps. This is the pulse you can put next to the hard data and learn something from three points in time. Same questions, same tasks. That gives you a line instead of a snapshot. And a line is what shows whether something is growing or fading. Then there's the problem. Nobody likes to admit surveys are people and people are uneven. Response bias is the first trap who answers, usually the enthusiasts because they have something to say. And sometimes the angry ones, the quiet middle who tried it twice and moved on rarely opens the email, so your results lean toward whoever cared enough to reply. Survey fatigue is the second. Send a long form every month, and by round three, people click through. Responses get shorter than random. Then they stop, keep each pulse to a handful of questions and tell people what changed because of the last one. Nothing kills participation faster than feeling like the answers went into a drawer. So protect the sample. Track the response rate by team, not just overall compare who answered against who was licensed and see who's missing. Follow up with the silent group directly. Even a few conversations. And when you report results, say how many people answered and out of how many, a survey with sixty percent response and specific questions can carry real weight, one with twelve percent and the satisfaction score is applause. But even a well-built survey only gives you one view. People tell you what they believe happened. The system tells you what it recorded, and those two don't always agree. So the next question is how to hold them together and what to do when they point in opposite directions. Triangulating telemetry, surveys, and observation. Every source you've collected so far has a blind spot. Telemetry is precise, but it's blind to meaning. It knows a person pressed a button forty times, but it has no idea if those forty actions were useful or if the output went straight into the bin. Surveys are rich, but they're built on memory and mood. People report what they believe happened and belief runs warmer than the facts. Observation is the most honest of the three, but it's tiny. A dozen people, a handful of tasks, a few afternoons. It can't speak for a thousand employees, so no single source can carry the claim alone. Each one needs another to check it. That's what triangulation means here. You don't pick the best source. You make them argue with each other and you trust what survives. Start with the simplest check. Take what people said in the survey and match it against what the system recorded. Say a team reports saving about an hour a week on meeting follow ups. Fine, now go to the data. Did those people actually use the meeting recap feature? How often across how many days? If the usage shows up and lines up with the task they named? The claim has a leg to stand on. If the usage isn't there, the claim has a problem. The match works best when you can connect the two at the group level. You usually can't tie one survey answer to one named person's logs, and you shouldn't try, but you can compare the people who said they use it heavily against the usage numbers for that same team. Wave or role. Do the groups look like what they described now? The contradictions. These are the most useful finding you'll get, so go looking for them. The classic one high reported savings. Low actual usage. A team says copilot saves them hours. The dashboard shows a few actions a month, mostly in one app. Those two things can't both be fully true. There are a few ways that happens. People may be using a different tool and crediting copilot. They may be remembering one great experience and generalizing from it. They may be answering the way they think the company wants, or the usage is happening in a place the telemetry doesn't capture. Well. You don't have to decide which on your own. You go ask a short conversation with three people from that team will usually settle it in ten minutes, and what you learn is worth more than either data point, because it tells you which source to trust for that kind of task. The reverse contradiction matters just as much. Heavy usage, but flat or negative survey answers. People are clicking all day and telling you it isn't helping. That's often a sign of low quality output or of a feature people feel pushed to use. It's a warning, and it connects to something we'll get to later when sources disagree. Don't average them. Weigh them. Weigh by reliability system timestamps and observed timing. Sit at the top because they don't depend on anyone's memory. Structured self-report sits lower, general satisfaction sits lower still and shouldn't be used to support a savings claim at all. Way by recency. A survey from week two describes a person still learning the tool. A survey from month four describes a routine when the two differ. The later one is closer to the truth about steady state work. The same goes for usage data. A spike at launch tells you about curiosity, not habit and way by sample. Forty observed tasks beat four hundred anonymous clicks when the question is how long a proposal takes. But four hundred clicks beat forty tasks when the question is whether people keep coming back, then write down the confidence level for each claim high, medium or low, with the reason that small habit forces you to look at what each number actually rests on, and it becomes the backbone of the executive report later. So now you have a way to build a conclusion that holds up baselines, comparison groups, task level timing surveys, and a method for reconciling them. But all of it sits on one fragile assumption that people are behaving normally while you measure them, and they won't if the measurement feels like a threat. People change what they do the moment they think the numbers will be used against them, which means even a perfect design can fail, not because the data was wrong, but because of what the data was allowed to become. Privacy, trust and measuring people responsibly. Start with what the tools won't show you. Viva insights and the copilot dashboard work on aggregates. They're built to describe groups, not to report on a single person, and there's a rule inside them that enforces it. A minimum group size. If a team is too small, the numbers get hidden. You'll see a blank chart or a note that there isn't enough data that isn't a bug, it's the design. Then there's de-identification in the analyst workspace, personal identifiers are masked by default. You can see that a population of two hundred people spent so many hours in meetings you can't see that one named person worked until midnight on Thursday. And what can admins see less than most people assume? Admins can manage settings set who gets access and view reports at the group level. They don't get a back door into individual behavior just because they hold an admin role. Exactly what each role sees changes over time, so check the current documentation before you tell anyone what's possible. But the principle is stable. The tools are meant to answer questions about populations. So where does the risk come from? Not the tool, the people using it. Because the moment a leader asks which of my people aren't using copilot, the measurement has changed its purpose. It stopped describing adoption and started grading individuals. And there's a quiet version of this too. Someone sets a target ninety percent active and a manager starts nudging specific names to hit it. You know what happens next? People click the button, open the app, fire off a throwaway prompt, close it. The dashboard goes up and the value doesn't move. That's a measurement system teaching people to game it. Worse, trust erodes if employees believe copilot is a way to watch them, they'll use it carefully or avoid it, or stop being honest in your surveys. And then every method we've covered gets weaker because they all depend on people behaving normally. So set a line and set it early. Copilot metrics describe groups and processes they're never used for individual performance, reviews, rankings, or discipline. Write that down. Get the executive sponsor to sign it and make it hard to undo. Now a second layer, and it depends on where your people work. In some regions, employee data rules are strict. In Germany, for example, works councils often have co-determination rights over tools that can monitor behaviour or performance. Parts of the EU have data protection law that limits how personal data gets processed, and what counts as a legitimate purpose. Other countries have their own rules, so before you switch on anything beyond, the basics involve legal, privacy and HR and where a works council exists, bring them in early, not at the end early means they can help shape what gets measured. Late means they can stop the whole program. Don't treat this as paperwork to clear a works council that understands the aggregation rules, the minimum group sizes and the purpose limits often becomes the strongest voice for the program because it protects their people too. And I'm not giving legal advice here. Your council decides what's allowed, where you operate. What I'm telling you is to ask before you build, because retrofitting consent is far harder than designing for it. The last piece is the one most programs skip. Tell the employees, say what you're measuring adoption by group work patterns by group task time in a small set of scenarios and survey answers. Say what you're not measuring. No individual rankings. No reading of content. No use in reviews. Say why? Because the company is spending real money and wants to know if it helps and where it doesn't. To fix the rollout, instead of blaming anyone and say who sees the results and what happens next, then do it again after each reporting cycle with what you found. That plain explanation does more for honest data than any control group. People who know the rules answer survey questions straight, and they use the tool the way they really use it. With trust in place, you can finally look at the uncomfortable result. A team where adoption is weak and the question becomes what leaders do about it. Diagnosing low adoption without blaming users. A team sits at fifteen percent active first instinct. They're resistant. That's the lazy read, and it's almost always wrong. People don't ignore a tool that helps them. They ignore a tool that doesn't fit their work, or one they can't trust, or one nobody showed them how to use. So low adoption is rarely a people problem. It's a signal that something upstream is broken. Your job is to find where for causes show up again and again. First is the wrong use case. Someone hands a team a license and says be more productive, but productive at what? If the team's real work is. Phone calls and field visits, drafting documents in word isn't where their day goes. The tool is fine. The match is off. Second is poor data quality. Copilot works from what it can reach. If the files are scattered, outdated, or full of duplicates, the answers come back thin or wrong. A person tries it twice, gets a confident answer, built on a stale document, and stops asking. They didn't reject copilot. They learned it can't be trusted on their content. Third is weak prompting. Most people were never taught how to ask. They type one vague line, get a vague result, and decide it's a toy. Nobody told them a good request. Names the task, the audience, and the source. That's a skill gap and it's fixable. Fourth is no manager support. We covered the manager effect earlier. A team where nobody with authority makes it normal stays cold. However good. The tool is now a course that sits one step earlier. Who got the licenses in the first place? In many companies, seats go out by seniority. Directors and vice presidents get them first because it feels right and because they asked. But think about their work. Mostly meetings, mostly conversation. Very little drafting or analysis. Meanwhile, the analyst who writes six reports a week, or the support agent who summarizes forty cases a day waits in line. So the licenses land where status is not where the workload is, and then the usage numbers look weak because the people holding the seats don't do the kind of work copilot speeds up that isn't low adoption, that's misplaced licensing. The fix is to assign seats by task volume, and let the dashboard tell you which groups are doing the work. Copilot fits. Then there's training. And here the problem is subtle. Most training sessions walk through features. This button summarizes a thread that one drafts an email. Here's how to open the chat. Pain people nod and then go back to their desks, where the work doesn't look like a feature demo. What they needed was a workflow. Here's how you prepare for a customer call start to finish. Here's how you turn a messy meeting into a task list and a follow up. When training follows the actual shape of someone's day, they can picture themselves doing it. When it follows the menu, they can't. So the question becomes how to tell which cause you're facing. The metrics can help if you read them for friction versus disinterest, look at the pattern in retention. If people try it once or twice and vanish, that points to a bad first experience poor data, unclear prompts, or a mismatch with the task. That's friction if usage never starts at all, even among people with seats in training. Look at the manager and the use case. Nobody modeled it or nobody saw why it mattered. That's missing permission or missing purpose. If usage concentrates in one app and ignores the rest, the other apps may not fit the work or people may not know what they can do there. If usage is steady but shallow, a few actions a week, that often means people found one small use and never went further. Then add the survey. Ask the cold teams one plain question what got in the way? The answers sought quickly. Can't find it. Didn't trust the result. Didn't know what to ask. Wasn't sure I was allowed. Each one points to a different fix and none of them is. Try harder. Treat low adoption like a diagnosis, not a verdict. Check the licenses, the content, the training, and the manager before you check the person. But a weak number isn't the only way a chart can mislead you. Sometimes the line climbs exactly the way you hoped and the work underneath it gets worse. Does when high usage hides low values. 00:49:30 Speaker: Picture the opposite problem. The adoption chart is perfect. Active users climb actions per user, climb. Every app lights up, and the leader reads that as proof. But a rising line only says people are doing more with copilot. It doesn't say the work got better. Start with the simplest failure busywork amplification. When writing gets cheap, people write more. A short update becomes a long one. A three slide summary becomes a twelve slide deck because the tool filled the slides in seconds. An email that used to be two lines turns into five paragraphs, with a friendly opening and a recap at the end. Now multiply that across a company. More email goes out so more email comes in, more documents get produced, so more documents need reading. Nobody planned that. But the volume of output rises and the volume of attention doesn't. So the cost didn't vanish. It moved from the writer to every reader downstream, and your usage numbers counted as a win because copilot was used a lot. Then there's quality drift. This one is harder to see because the output looks fine. A draft arrives clean. Good structure, confident tone, no typos. It reads like finished work, but the claim in paragraph three came from an old file. The figure in the table was rounded in the wrong direction, and the summary left out the one objection that mattered in the meeting. The surface is polished and the substance isn't. People stop checking because everything looks checked and that connects to the third problem review overhead. Say copilot cuts a drafting task from forty minutes to ten thirty minutes saved in the timing study. But now someone has to read the draft closely because they know it can be wrong. Verify the numbers. Rewrite the weak parts. Fix the tone. If that takes twenty five minutes, the net gain is five. If the reviewer is a senior person who now spends their afternoon correcting machine drafts instead of doing their own work, the net can be negative. That's why the earlier advice to time the whole job review included matters so much. A timing study that stops when the draft appears will overstate every result. So how do you catch all this? Not with usage metrics. They can't see it. You need numbers that measure what happens after the output leaves. The tool rework rate is the first. How often does a document come back for changes after it's submitted? Compare the rate for copilot assisted work against the baseline. If it rises, the drafts are shipping with problems. Revision cycles are the second. Count the rounds between first draft and approval, a proposal that used to need two passes and now needs four hasn't gotten faster even if the first draft appeared in minutes and downstream complaints are the third. This is the one nobody tracks until it hurts customers who write back to correct an answer. Colleagues who say a report was wrong. Legal flagging a clause. Support ticket reopened because the first reply missed the point. Those signals live in your ticketing system, your inboxes, your review logs. Pull them for the same task groups you've been following, and read them next to the usage numbers. When usage goes up and these go up with it, you found the pattern. People are using copilot more and producing more, and the business is absorbing the cleanup when usage goes up and these hold steady or fall. That's the evidence you were hoping for. The tool is adding speed without adding errors. Either way, you only know because you looked past the dashboard, which brings you to the next gap. Suppose the value is real and the quality holds. You still can't judge whether it was worth it, because a benefit means nothing until you set it against what it took. And what it takes is more than the number on the license invoice. The real cost of copilot start with the number everyone knows thirty dollars per user per month. At the time of writing, that's the list price for a Microsoft three hundred sixty five copilot license. It sits on the invoice where nobody can miss it. Multiplied by seats, multiply by twelve and you have a line in the budget. Check current pricing and your agreement before you quote it, because contracts and discounts differ. That's the visible cost and it's the only one most reports include. But a license is the ticket, not the trip. Before copilot gives a useful answer, somebody had to make the content worth answering from. That work has a price even when it doesn't have an invoice. Take data. Clean up. Copilot reads what the person can reach. So the old project sites, the duplicate files, the five versions of the same policy, they all become inputs. Someone has to archive the dead material, fix the labels, and decide which version counts. That's weeks of effort for a team, sometimes months for a company, and it rarely gets booked to the copilot program. Then permissions. This one surprises people. Copilot respects access rights, which sounds like a safety feature. And it is. But it also means every Overshared folder and every anyone in the company link suddenly matters because a prompt can surface what a person was never meant to see. So before roll out, somebody audits sharing Titans access and cleans up groups. Skilled people doing slow work for as long as it takes. Training costs time twice, once for the people who build the material, once for the people who sit through it, which is hours away from the work you're hoping to speed up. Do it properly by workflow instead of by feature, and the cost goes up. It's still worth it, but it belongs in the total change. Management is the same story. Champions, manager briefings, communications, office hours. Someone has to run all of that and it takes real calendar time from real salaries and support. A new tool means new questions. How do I ask this? Why did it say that? Who can I trust to check it? The help desk absorbs those tickets, and the early weeks are the heaviest. Now the cost that never ends. Oversight copilot isn't a project you finish. It's something you run. Someone reviews usage reports, adjusts. Who has access watches for oversharing, handles new features as they arrive, and answers the compliance team when they ask how it's governed. That's ongoing. Admin and governance time. Month after month, a small slice of several people's jobs adds up fast, and if you don't count it, you'll undercount the program every single year. Then there's the math on seats nobody uses. Say you bought one thousand licenses, two hundred never got assigned because the rollout stalled in one region. Another three hundred went to people who opened copilot once in week one and never returned. That's five hundred seats doing nothing at thirty dollars a month. That's fifteen thousand dollars every month, one hundred and eighty thousand a year for software that never touched a task. And here's the part that stings. Those seats still count in the denominator when you divide total cost by results. So idle licenses don't just waste money. They drag down every ratio you compute afterward, and they make the people who do use copilot look less valuable than they are. So add it up. Honestly, license fees, clean up permissions, work training, change efforts, support governance, and the share of seats going to waste. That's the real cost of the program, not the invoice, but everything the invoice assumes someone else already did. And now you finally have both sides, a measured change in the work and a full price for producing it. Which means you can do what the active user number never allowed. Divide one by the other cost per outcome. The metric that replaces active users active users has a numerator problem. It counts people, but nobody buys co-pilot to have people. They buy it to get work done. So the new metric starts with the work and the unit of work is an outcome. An outcome is a finished piece of work. With a result, you can point at a closed ticket, a drafted proposal, a completed summary, a resolved case. It has a start and end and a record that says it happened. If you followed the earlier advice on task selection, you already have a short list of these. They're the same tasks now counted as units. The test is simple. Could someone else look at the system and confirm it occurred? If yes, it's an outcome. If it only exists as people felt more productive, it isn't. Now the formula. It's plain division. Total program cost divided by the number of outcomes completed with copilot assistance. Look at what goes on top, not the license fees alone. The full cost from the last section. Licenses, clean up permissions, work training, change efforts, support governance and the idle seats. All of it. If you leave pieces out, the ratio looks better than the truth and finance will find the missing pieces before you do. And look at what goes on the bottom. Not every outcome in the company, only the ones where copilot was part of the work. That takes some care. You need a way to tell which proposals or cases were assisted. Sometimes the system tags it. Sometimes you use the license group as a stand. In. Either way, state the rule and keep it the same each month. Say your program costs sixty thousand dollars this quarter. All in and licensed support agents closed twelve thousand cases with copilot involved. That's five dollars a case as program cost. Now that number alone doesn't mean much. A single ratio never does. It needs something beside it. So compare it before and after first. What did a closed case cost you in agent time before rollout? Pull that from the baseline. If handling time was twelve minutes and copilot brought it to nine, you can price the difference using the loaded cost of an agent's time. Then ask whether the three minutes saved per case covers the five dollars you're spending to get it. Sometimes it does, sometimes it doesn't, and you've learned something before the renewal, not after. Then compare across teams. Same formula, different groups. Support might land at five dollars an outcome. Sales proposals might land at forty. Finance close commentary might be higher still. That spread is the useful part. It shows you where the money is working and where it's mostly buying seats, and a team with a high cost per outcome isn't automatically a failure. A proposal is a bigger outcome than a case reply, so it should cost more. Compare like with like and be careful about ranking teams against each other when the work isn't the same size. One more choice you have to make. There's a second ratio floating around, and it's tempting. Cost per hour. Freed. It takes total cost and divides by hours saved. It's easy to compute because you already have time savings from the task studies, and it does fit in one situation when the whole business case rests on capacity. And you can show that freed hours turn into real work or avoided hiring cost per hour. Freed speaks the language of labor cost, but it carries the weakness we covered earlier and hour freed isn't an hour used, so the ratio can look excellent while nothing in the business moved. You're dividing by something that may have evaporated. Cost per outcome is harder to flatter the outcome either not completed or it didn't. So use it as your lead metric. Keep cost per hour freed as a supporting number labeled clearly and only where you've shown where the hours went. Now you have a ratio that connects spend to work. It replaces seventy two percent active with something an owner of a process can argue with. But a metric only works if the right people can read it. A ratio sitting in an analyst's workbook changes nothing. It has to land on a page where leaders, finance, and process owners can see it side by side with everything else and agree on what it means. Building the Value scorecard. Right now, you're holding a lot of numbers. Readiness data, adoption data, task timings, survey results, rework rates, cost per outcome. Scattered across five reports. They tell five small stories on one page. They tell one. So build the page and give it four layers in a fixed order. The first layer is readiness. Are the conditions right? License is assigned to the right groups. Content cleaned up permissions. Audited managers briefed. This layer answers whether the work could succeed at all before anyone types a prompt. The second is adoption. Who's using it, how often and in which apps. The dashboard numbers live here, including retention. It answers who the third is behavior change did the way work gets done. Shift task. Time. Meeting. Load. Focus time. Review. Effort. The survey comparisons. This layer answers what changed in the work and the fourth is business outcome cycle time throughput error rates. Cost per outcome. The numbers of process owner already trusts. This layer answers whether any of it mattered. Notice the direction each layer rests on the one below it. Adoption without readiness stalls. Behavior change without adoption is a coincidence, and an outcome without a behavior change is luck or something else entirely. When the page reads from bottom to top, a reader can see exactly where a chain breaks. Now label every number leading or lagging. A leading indicator moves first and predicts weekly active users in a wave manager participation share of licensed people who tried a priority scenario these shift within days, so they warn you early. A lagging indicator moves late and confirms cycle time rework rate cost per outcome. These take weeks or a full quarter to settle, and they're the ones that hold up in front of finance. Why label them? Because people read them wrong. Without it, a leader sees adoption jump and expects the outcome line to jump next week. It won't. And the leader sees an outcome stay flat in month one and declares the program dead. It isn't a small tag beside each number, leading or lagging. Sets the right expectation about when to look. Then comes the hard part. Cut a scorecard with forty metrics isn't a scorecard. It's an archive. Nobody reads it, so nobody acts on it. AIM for a handful per layer. Maybe twelve numbers in total, and push yourself toward fewer. If you can't say what decision a number would change. It doesn't belong on the page and every number needs an owner. A name person, not a team. Adoption by a group might belong to the change lead. Task time for support cases belongs to the support manager. Cost per outcome belongs to someone in finance or the program office. When a number moves the wrong way, that person gets asked why. Without an owner, a metric is just decoration and the red cell sits red for three months. Give each owner a target to or at least a direction. Rework rate should not rise above baseline. Handling time should fall by the amount we assumed in the business case. Now the number has a job and then protect the definitions. This is the unglamorous part, and it decides whether your trends mean anything. Say, active user meant one action in twenty eight days in January. In April, someone switches to a stricter definition or the tool's own calculation changes, or a new team gets folded into the group. The line drops, everyone panics and nothing real happened. Only the ruler changed. So write each definition down once. What counts? What's excluded, which group, which time window, which source store it next to the scorecard. When a definition has to change, and sometimes it will mark the date on the chart and restate the earlier months under the new rule. So the trend stays honest. That discipline feels fussy, but a trend is the whole point of measuring over time, and a trend built on shifting definitions isn't a trend. So the scorecard exists for layers labeled, trimmed, owned, and stable. But hand that page to an analyst and to a chief financial officer, and they'll read it completely differently. The analyst wants the detail behind each cell. The executive wants to know what to do on Monday, reporting copilot value to executives and executive doesn't want a dashboard. They have one. They have fifty. Every function sends them charts, and most of those charts end with the same silent question. So what do you want me to do? That's the gap. An analyst reports what the data says. An executive needs to know what to decide, fund more seats, move them, fix the rollout, or stop. If your report doesn't point at one of those four, it's a status update and status updates get skimmed and forgotten. So build a report around the decision and give it four parts in this order. The first is the headline one or two sentences. Plain words no tool names. Support handled eleven percent more cases per agent with no drop in quality at a program cost of five dollars a case. That's a headline. Copilot adoption reached seventy two percent. Isn't right. It so that someone who reads nothing else still walks away with the result. The second is the evidence. Three or four numbers, not twenty. The measured change in the work, the comparison group beside it, the quality check and the cost per outcome. Each one gets a source and a date. You've already built these. Now pick the ones that carry the claim and leave the rest in the appendix. The third is the confidence level. This is the part most reports skip, and it's what makes the rest believable. For each claim, say high, medium or low, and give the reason in one line. High because it comes from system timestamps across two comparable groups. Low because it rests on a survey with a thirty percent response. You wrote these down while triangulating. Now they go on the page. The fourth is the next action. One recommendation with an owner and a date. Extend licenses to the two regional support teams by the end of next quarter, or pause expansion in sales until the proposal rework rate comes back to baseline. Headline evidence. Confidence. Action one page. Now the translation problem. Your evidence probably arrived in hours. Hours mean little in a boardroom, so convert them into the thing the listener already tracks. If the value is capacity, say what? The team can now absorb. The same twelve agents handled the volume that used to need fourteen. That's a statement about avoided hiring and finance can price it. If the value is cycle time, say how much sooner something reaches the customer. Proposals now go out in three days instead of five. Then connect it to what sooner means earlier revenue. Fewer lost deals faster close. If its margin show the arithmetic in one line and show the assumptions behind it. Loaded cost of an hour. Number of hours that became real output and the share that didn't. Don't hide the share that didn't. A margin claim with visible assumptions survives questions. One without them falls over at the first. How did you get that? And remember the earlier point about labels? If the gain is quality or risk, call it that an honest, better work. No cash impact yet beats a stretched cost saving every time. Then comes the part that worries people most. Uncertainty. The fear is that admitting doubt costs you the room. In practice, it's the opposite. A leader who hears a number with no caveats assumes you either don't know where it's weak or you're hiding it. A leader who hears this part is solid. This part is an estimate, and here's how we'll firm it up. Starts trusting the solid part more. So state it as a range, not a point between eight and fourteen percent, with the low end being the measured result and the high end including self-reported tasks. Name the single biggest weakness before someone else does and attach a next step to each doubt. We'll close this gap with a second timing study in June. Keep the tone flat. No apology, no drama. Doubt delivered calmly. Sounds like rigor. That's what a good report does. It picks a decision, shows tight evidence, labels its confidence, and offers an action. But there's a second half to reporting well, knowing what to put on the page is one skill. Knowing what to leave off is another, because some claims feel natural, even obvious, and they're exactly the ones that will undo the rest of your work. If you make them claims you should not make. There's a short list of sentences that feel safe in a report and aren't. Each one sounds like a. Finding. Each one is a leap. The first is the pilot extrapolation. Your pilot group of eighty people save twelve percent on proposal drafting, so you write copilot will save twelve percent across the company. But who was in the pilot? Volunteers. People who wanted it had the right kind of work and probably had a manager cheering them on. Your finance team, your field staff and your ten year veterans weren't in that room. A result from the keen few tells you what's possible under good conditions. It doesn't tell you what happens when the rollout reaches everyone else. 01:06:11 Speaker: So say what you saw in a pilot of eighty volunteers in proposal work, drafting time fell twelve percent. Then came the next test. Before anyone asks for the company wide number, the second claim is quieter, self-reported savings presented as measured savings. It happens through formatting, the survey said. People save ninety minutes a week. That number lands in a chart next to the timestamp data. Same font, same color, and the reader assumes they're the same kind of thing. They aren't. One is what people remember and believe. The other is what a system recorded. Label every figure by its source right on the chart. Self-reported or system measured. If a headline number rests on the self-reported kind, say so in the headline. Third, the cost reduction claim every saved minute counted as money back. You did the work in the earlier section on value types, save time becomes cash only. When something actually changes, a vacancy goes unfilled. Overtime stops. A contractor isn't renewed. If the team kept the same size and the same pay, nothing left the budget. Calling it a cost reduction invites finance to look for the line where it shows up. They won't find it, and your next real result will get the same suspicion. Here's the cleaner phrase freed capacity not yet converted to cost. It's less exciting. It's also true, and it leaves room to claim the savings later once the conversion happens. And the fourth, which is the hardest to resist ignoring the comparison group when the numbers look good. Imagine the licensed teams handling time fell eight percent. Great. Then you check the comparison group. The unlicensed people doing the same work and their handling time fell six percent over the same months. A new ticketing tool arrived or the product got simpler, or the season turned Copilots share of that gain isn't eight percent, it's two. That feels like a letdown when you're holding a strong number and a deadline. The temptation is to leave the comparison off the slide because nobody asked for it. But somebody will. A skeptical director, an auditor, a competing project that wants the budget. And if they find the gap before you show it, every other number in your report gets reread with suspicion. So put the comparison next to the result every time, even when it shrinks the headline. A smaller claim that survives questioning is worth more than a large one that doesn't notice what all four have in common. They're not lies. Each one starts from a real number and stretches it past what the evidence supports. Which means the fix isn't more honesty at the end. It's structure at the start. You can only report a clean comparison if you set one up. You can only separate measured from self-reported. If you plan to collect both and you can only extend the pilot with confidence. If the pilot was built to be extended. That means measurement can't be a layer you add after the licenses go out. It has to be part of how the rollout itself is designed from day one. Designing rollouts that can be measured. Most rollouts are designed around one question how fast can we get licenses out? So the plan is a date, a headcount, and a communications email measurement shows up later as a favor someone asks the analyst for. And by then, the one thing that would have made the numbers believable has already been spent. The fix is to treat the structure of the rollout as a measurement choice, not an afterthought, a choice. Start with waves. Instead of switching on a thousand seats in one week, release them in groups a first wave, a second, a third a month or so apart. That isn't just caution. It creates a comparison for free because while wave one uses co-pilot, wave two is still working the old way, and you can watch both over the same weeks within each wave. Define cohorts. A cohort is a group chosen on purpose. Same function, similar work. Similar size. Support agents in one region. Proposal writers in two business units. When cohorts are built around real work, their results can be read against each other when they're built around whoever replied to the sign up form, they can't. Then there's the holdout group. This is the one leaders resist because it means someone who could have a license doesn't get one yet. But a holdout is exactly what protects you from the claim. We just covered the gain that was really the season. Keep a matched group unlicensed for a defined period. Tell them honestly why and give them first access. Once the comparison is done, it costs you a few weeks of delay. For some people, it buys a result. Nobody can wave away now. Success criteria write them before the first license is assigned. That order matters more than it sounds. Once the data is in, everyone gets clever. A flat result becomes. We were really testing adoption. A small gain becomes early signs. The goalposts drift toward wherever the numbers landed, so settle it ahead of time. What would count as working? What would count as not working? Handling time falls at least eight percent against the holdout, with rework no higher than baseline. Put it in writing. Get the sponsor to agree and date it. That one page turns the day ninety review from an argument into a check. Next scenarios. Resist the urge to measure everything. Pick three to five priority scenarios, each tied to a real process the business already runs. Not general productivity. A scenario is something like drafting customer proposals, summarizing support cases, or preparing for client meetings. Use the selection test from the task section. Frequent, measurable and costly enough when it goes wrong. If a scenario fails that test, drop it. However exciting it sounds, three to five is a deliberate limit. Fewer than three and one bad result sinks the program more than five, and nobody has the attention to run them properly. And a short list makes training easier too, because you can teach the workflow for each one by name. Then give every scenario an owner, a person with a name who already cares about that process. The support manager owns the support case scenario. The sales operations lead owns proposals and attach a number to that name, not improve efficiency. A specific measure with a baseline and a target. Average handling time currently twelve minutes. Target eleven or lower by day ninety. Now, when the review arrives, there's a person who knows the figure, owns the explanation and has a reason to care. Without the owner, a scenario is a topic without the number and owner is just a title. Put it together and you have a rollout with edges. Waves that create comparison cohorts that mean something. A holdout that protects the result criteria written in advance. A short list of real scenarios and a named person holding each one. But a design only counts once it runs. On paper, it always looks tidy, so the useful next step is to put it on a calendar and watch what a real ninety days of measurement looks like. One stretch at a time. A ninety day measurement plan. Take everything so far and put it on a calendar ninety days. three blocks of thirty. Each block has one job, and each job has to finish before the next one starts. Days one to thirty are set up. Nobody gets a license yet, or at least the measured groups don't. First, capture the baseline. Pull the numbers for your chosen scenarios from before rollout. Handling time. Turnaround. Rework rate. Meeting hours. Whatever your owners agreed to, check that the pre period is long enough and that it doesn't sit on a quarter end spike if history is missing. This is the week you find out. Not week ten. Second, lock the scenarios three to five, each with an owner and a number. Third, write the survey task specific questions. A defined recall window. The same wording every time. So wave one and wave three can be compared. And fourth, set up the dashboard. Confirm who has access. Confirm the minimum group sizes won't hide your cohorts, and write down the definitions for every metric on the scorecard. By day thirty, you should have a baseline on file and a success criteria page signed by the sponsor. If you don't, don't start the clock. A late start costs you a week. A start without a baseline costs you the whole result. Days thirty one to sixty are for watching. Licenses are live in wave one. The holdout is still waiting. Now run the first pulse survey around week two or three of use and treat it for what it is a read on learning, not on steady state work. People are still figuring out how to ask at the same time. Start the task level timing. Observe a small group doing the scenario tasks. Review included. Pull the system timestamps for the same tasks. A dozen well timed tasks per scenario is enough to start, then review the segmentation. Cut adoption by role, by region, and by manager. Look for the pockets we talked about, where it's taking hold and where licenses sit idle. This is also the moment to diagnose, not blame. A cold team at day forty five has time to get a workflow session, a manager briefing, or a cleaner set of files and still show a different result by day ninety. By day sixty, you should know which scenarios are moving, which are stuck and why. Days sixty one to ninety are for the verdict. Now the comparison set wave one against the holdout over the same weeks. Check the difference against baseline and check that the holdout didn't move on its own. If both fell by similar amounts, the credit goes to something else and you say so. Run the second pulse survey around week eight and match it against the usage and timing data. Flag any contradiction and settle it with a few short conversations. Then compute cost per outcome. Full program cost on top licenses, clean up permissions. Work training. Support governance. Idle seats. Assisted outcomes on the bottom. Do it per scenario and compare against the cost of the same outcome before rollout. Finally, build the executive readout one page headline evidence confidence level, next action and write the confidence levels honestly, because by now you know exactly which numbers are solid and which are soft. Then comes day ninety and the page has to end in one of four decisions. Expand the scenario. Beat its success criteria. The quality held and cost per outcome came in under the business case. Extend licenses and waves and keep a smaller holdout to confirm the result at scale. Redirect. The tool worked, but not where you pointed it. A scenario fell short, while another may be one you hadn't planned, showed strong results, move seats and training toward where the value showed up. Fix usage was weak or quality slipped, but the cause is something you can name. Poor content, thin training, missing manager support, hold the rollout, repair the cause and remeasure for another thirty days or stop. The criteria were clear. The evidence is in and the scenario didn't clear the bar. Stopping a scenario isn't failure. It's the reason you wrote the criteria first, and it returns budget to something that works. Notice that none of the four decisions is keep reporting. That's the plan. Clean, sequenced, and easy to read in a slide deck. And that's exactly the problem because on paper, nobody misses a deadline. Nobody changes the definition, and every owner answers the phone. In real organizations, the plan breaks and it breaks in the same few places almost every time. Where measurement programs break, the first break is quiet. It looks like diligence. Someone builds the scorecard and it's good twelve numbers. Then a leader asks for one more cut by region, then another for the new business unit. Then someone adds a sentiment index, a prompt quality score a licenses by tier view. Six months later, there are forty metrics across six reports, and every one of them has a reasonable story, but nobody can say which number would make them change a decision, so nobody does. The meeting becomes a tour of charts, and the tour ends with let's keep an eye on it. That's metric sprawl. It feels like rigor and it works like fog. Every number you add dilutes the ones that matter, and the red cell that should have forced a conversation gets lost between two green ones. The test hasn't changed since the scorecard section. If you can't name the decision, a number would shift. Cut it. The second break is about people specifically who owns what. Think about how the pieces are held. It owns the tenant, the licenses, and the dashboard. HR owns the survey and the employee data rules. Finance owns the cost model and the budget line, and the business owns the actual work. The cases and proposals the whole program is meant to improve. Four groups, each holding one quarter of the answer. And nobody holds the whole question. I can report adoption, but can't say whether handling time moved finance can price the licenses but doesn't know which outcomes count. The business sees the work change but doesn't see the cost. So a request like is copilot paying off bounces around the building and every group answers the part it can see. This is where the program stalls and it doesn't look like a failure. It looks like a polite loop of emails. The fix is one named owner for the value question, usually in a program office or a finance partner role, with the authority to pull numbers from all four. Not a committee. One person whose name is on the readout. The third brake is slower and it hides in the data itself. Start with lag. Some metrics refresh weekly, some monthly, and some only after a quarter closes. So the adoption chart shows last week. The survey shows the month before and the cost figure shows last quarter. Put them on one page and they look like they describe the same moment. They don't. A leader reads a rise in usage next to a flat outcome and concludes it isn't working when the outcome number simply hasn't caught up yet. Then there's definition drift. We touched on it when building the scorecard, but in practice it creeps in through side doors. A new analyst pulls active users from a different report. The tool changes how it calculates a metric. A team gets reorganized and lands in a different group. Nobody lies. The number just means something slightly different than it did in March, and the trend line quietly bends. The only defense is boring. A dated note beside each metric saying what it counted when you first reported it, and a rule that no definition changes without restating the history. The fourth break is the most human one. People start chasing the dashboard. Once a number has a target, it gets a gravity of its own. Adoption needs to hit eighty percent. So the effort goes into licenses and nudges and launch events. The chart climbs and somewhere in that push, the original scenario gets forgotten. Nobody checks whether proposals are going out faster or whether the support queue is clearing. The team is now optimizing the instrument, and the work it was meant to describe sits untouched. You can spot it in the meeting. The questions are about the line why did Tuesday dip? Can we get region three up? Rarely does anyone ask what happened to the cases. Look at all four breaks together. Too many metrics. No single owner data that drifts and lags a dashboard that becomes the goal. These aren't separate problems and they don't get solved by better charts. They share a sauce. Each one comes from treating measurement as a reporting job that sits beside the rollout, something you add and maintain. Adding more of it makes it worse. More metrics means more sprawl, more owners means more handoffs, and more dashboards means more to chase. The fix isn't more measurement. It's a different starting model. From usage reporting to value management. Every measurement program starts with the same question did they use it fair? First question. But it's a question about the tool. And the tool doesn't pay for itself by being touched. The question that replaces it is different. Did the work change? Did the proposal go out sooner? Did the case close with fewer reopenings? Did the analyst spend Thursday on analysis instead of formatting? Those are questions about the business, and they only get answered by someone who knows what the business does all day. That's the shift. Sounds small, but it changes who's in the room, which numbers lead the page? What counts as a bad result? Under usage reporting, a bad result is a low chart. So the response is a launch event. A reminder email, a leaderboard under value management. A bad result is a process that didn't move. So the response is to look at the process. Is the content clean? Is the workflow right? Does the manager use it? You stop managing the instrument and start managing the work, and that connects to how you treat the whole thing. Most companies run copilot as a software rollout. There's a project plan, a go live date, a hypercare window, and a closing slide that says complete. The licenses are out, the project ends, but nothing about copilot ends at go live. The content keeps changing, so the answers change. New features arrive every few weeks. People join, move, leave. Work shifts. With the season, a software rollout finishes. An operating change keeps running because it's now part of how work gets done. And it needs an owner the same way a support queue or a sales process does. Once you see it as an operating change, the cadence follows. You don't review it once you review it on a rhythm monthly look at adoption. This is the first layer. Who's using it? Which groups went quiet where licenses are sitting idle? Which managers have made it normal? These numbers move within weeks, so a monthly look catches problems while they're still cheap to fix A team that drops off in March shouldn't still be dropped off in June. Quarterly look at value. This is the slow layer. Task level change. Rework rates. Cost per outcome. The comparison against your holdout or baseline. These need time to settle, and reading them weekly only produces noise, so give them a full quarter. Run the survey pulse. Redo the cost model and write the readout. Two rhythms, two questions monthly asks whether people are showing up quarterly. Asks whether showing up mattered. Now. The part nobody enjoys cutting. Every metric earned its place at some point, but work changes, and a number that drove a decision in the first quarter might drive nothing by the third adoption rate, was the argument at launch. Once usage is steady and broad, it's just a lamp that stays lit. Keep checking it and it eats attention that belongs somewhere else. So build a review into the review each quarter, take every number on the scorecard and ask one thing in the last three months. Did this change what anyone did? If yes, it stays. If not, retire it or push it down to a background report that only gets read when something breaks. Retiring a metric feels risky, feels like hiding something, but a scorecard that only grows is a scorecard nobody reads, and the metrics you keep carry more weight precisely because there are fewer of them. Put these together and the model is simple. Ask about the work. Run it as an ongoing change. Check people monthly and results quarterly, and prune anything that stopped earning its seat. Which leaves one thing a question, really. And it's the one this whole episode has been circling. When someone asks you how copilot is going, what will you be able to say that isn't a percentage of people who opened it? Conclusion. Go back to the number you opened with seventy two percent active. It's accurate. It's also the answer to a smaller question than the one the executive asked. Active users tells you who showed up. It never told you whether showing up mattered. So here's what replaces it. Not one metric, but a chain. And every link has to hold first, a baseline. What the work looked like before anyone touched the tool. Then a comparison. So the change belongs to copilot and not to the season. Then the task level where you time the real work review included and stop guessing from job titles. Then cost per outcome with the full price on top and finished work on the bottom. And last, a report that labels its confidence and ends in a decision. Skip the baseline and the rest becomes a story. Skip the comparison and it becomes a flattering one. Everything downstream depends on what you captured first. So here's one action. Just one this week. Pick a single scenario, something frequent, something countable, something with an owner who cares. Then capture its baseline before anything else happens. Handling time. Turnaround. Rework rate. Write down the number, write down the date, and write down how you pulled it. That's an hour of work, and it's the only hour in this whole process you can't get back later. If this changed how you report copilot leave a review. It helps more people who are stuck reporting licenses find the show. And if you want to talk through a measurement problem you're dealing with, connect with me on LinkedIn. Tell me which topic should come next. I read those messages. Now one more thing. Next month the dashboard will probably look better. More active users, more actions per person, a new app lighting up on the chart. Someone will paste it into a slide and the room will nod and the question will still be sitting there unanswered. Did the work get better? Nothing on that chart can tell you. Only the baseline you capture this week can.