From Feature Tourism to Business Impact
A Copilot Reality Check
You’ve experienced this before. Whether on a Conference stage, webinar or LinkedIn post. Someone opens a Teams meeting recap and says: “I missed this one-hour meeting. Watch this.” They click “Recap” and Copilot spits out a summary with action items in seconds. The audience nods. “Imagine never having to write meeting notes again!” Fire emojis in the comments. 🔥
Quick question: what business problem did that just solve?
None. Don’t get me wrong. Having a meeting summary is useful. But the question most people skip is: why am I making this summary? What happens with it? Does it feed into a project tracker? Does it trigger follow-ups? Does it change how the team makes decisions? Or does it just exist? A nice-to-have that nobody opens twice.
That’s the thing. The demo shows the what. But nobody talks about the why and the so what. And that’s where most Copilot initiatives quietly fall apart.
I’ve watched hundreds of these demos over last couples of years. At conferences, in customer workshops, on LinkedIn. I’ve learned something that took me a while to admit:
Most Copilot demos are worthless. At least when they stay demos.
And yes, I’m pointing at myself too. If you follow me on LinkedIn, you know I regularly post about individual Copilot features. New Agent Mode capability here. Researcher update there. A little trick in Copilot Chat. I do that on purpose, because you can’t adopt what you don’t know exists. Feature posts create curiosity, open doors, show people what’s possible. For organizations where employees still think Copilot is “a chatbot in the sidebar“ that awareness work matters. But awareness is the starting point, not the finish line.
The problem starts when organizations get stuck there. When the demo becomes the strategy. When “look what it can do” is the only message, and nobody asks the harder question: what should it do for us, in our workflows, to solve our problems?
A single feature is a good conversation starter. The real lever, though? A Day in the Life scenario. Where the feature is the means, not the end. Where you walk a financial controller through how Copilot changes their entire month-end close, not just show them that Excel can “summarize data.” Where the feature is the tool and the workflow is the story.
The gap between those two things?
That’s what I call Feature Tourism.
It’s like on the hop-on / hop-off buses. I see as many spots as possible, without even moving yourself. And in my experience, it’s the number one reason organizations don’t get ROI from Copilot. (🤫 talking about ROI on personal productivity is the wrong question anyway)
What Feature Tourism Actually Looks Like
I talk to organizations every week about Copilot. Large ones, mid-sized ones, across industries. And when an organization isn’t willing to invest properly in adoption (and I mean really invest, not just buy licenses), the pattern is always the same. I can almost predict it by now.
Phase 1: The Wow Moment. Leadership watches a demo. Copilot summarizes a meeting, generates a document, builds a chart. Impressive. Licenses get approved. (...But only for a handful of people, maybe 50, maybe 100. “Let’s start small and see.”)
Phase 2: The Rollout. IT enables Copilot. There’s a launch email (maybe). Employees are told to “explore”
Phase 3: The Scatter. People try random things. Some love it in Outlook. Others open PowerPoint, get a mediocre deck, and close it again. Most have no idea where to start.
Phase 4: The Plateau. Two, three months in, usage goes flat. The enthusiasts keep going. Everyone else stopped weeks ago. Leadership asks “Where’s the ROI?” and nobody has a real answer. Because nobody tied the features to outcomes in the first place. (The Copilot Plateau)
Phase 5: The Verdict. Someone in finance calculates the cost of unused licenses. “Copilot doesn’t deliver a value.” Seats get reduced. Another enterprise tech pilot that didn’t scale.
If this sounds like your organization, you’re not alone. I’ve had this exact conversation multiple times. And it’s almost never the technology that failed. It’s the willingness to treat adoption as a real investment, not just a line item for licenses.
The AI Productivity Paradox
There’s something bigger going on here, and it’s worth understanding.
A working paper from the National Bureau of Economic Research looked at how AI adoption actually translates into productivity gains at the firm level. They surveyed almost 6,000 CEOs, CFOs and executives across the US, UK, Germany and Australia. Here are the 4 key facts from their abstract:
Around 70% of firms actively use AI, particularly younger, more productive firms.
While over two thirds of top executives regularly use AI, their average use is only 1.5 hours a week, with one quarter reporting no AI use.
Firms report little impact of AI over the last 3 years, with over 80% of firms reporting no impact on either employment or productivity.
Firms predict sizable impacts over the next 3 years, forecasting AI will boost productivity by 1.4%, increase output by 0.8% and cut employment by 0.7%. We also survey individual employees who predict a 0.5% increase in employment in the next 3 years as a result of AI.
Over 80% of firms reported no impact from AI on either employment or productivity over the last three years. Employees using AI tools did get faster at specific tasks. But those small wins didn’t add up to measurable improvements at the company level.
In knowledge work, it gets even more interesting. Lawyers and financial analysts saved time on first drafts, sure. But then they spent more time reviewing and fact-checking what the AI produced. Less time writing, more time editing. The net effect? A shift in where the effort goes, not how much effort there is.
But here’s the thing most people miss in this debate:
We need to ask what we’re actually trying to measure.
Most of the conversation around Copilot ROI focuses on personal productivity. Did Sarah draft her email faster? Did Thomas prepare for his meeting in less time? That’s useful, but it’s incredibly hard to quantify in a way that satisfies a CFO. Saving 15 minutes on an email doesn’t show up anywhere in the books, however it’s helpful for an individual.
Personal productivity is the foundation. It’s where people build confidence with the tool, where they learn what it can and can’t do. You need that stage. But it’s not where the measurable impact lives.
The real impact shows up one level higher: in business processes. When you move from “Sarah writes emails faster” to “our IT helpdesk resolved 40% more tickets this quarter because Copilot handles the first-level triage,” that’s a number. When your sales team’s average response time to inbound leads drops from 4 hours to 45 minutes because Copilot drafts the first reply with the knowledge we have, and your deal cycle shortens by two weeks as a result, that shows up in the pipeline.
That’s the shift organizations need to make. Personal productivity is the on-ramp. Business process impact is the destination. And the paradox only exists when you try to measure destination-level outcomes at the on-ramp stage.
This maps directly to the Frontier Transformation Journey I wrote about recently. Pattern 1 (Human + Assistant) is where personal productivity lives: you and Copilot, same tasks, faster. That’s where most organizations are today, and that’s where the ROI question keeps hitting a wall and keeps organization away to push the journey across the organization. Pattern 2 changes who does what, with agents joining your team. Pattern 3 is where humans set direction and agents execute, and where business outcomes become measurable. These patterns are also a measurement roadmap, not only a technology view. And the mistake is applying Pattern 3 expectations to Pattern 1 maturity.
I’m not making the case against Copilot here. I’m making the case against measuring the wrong thing at the wrong stage. And against starting with features instead of outcomes. When you kick things off with “Copilot can summarize meetings!” instead of “We need to cut our deal cycle time by 15%,” you end up with Feature Tourism.
Feature Tourist vs. Impact Architect
Two people in the same company, with the same Copilot license. Completely different results.
The Feature Tourist shows the team what Copilot can do in Excel. The Impact Architect sits down with the finance team and says: “You spend 12 hours a month on variance analysis. Let’s get that down to 4. And then let’s figure out what you do with those 8 hours.”
The Feature Tourist reports 500 active users to leadership. The Impact Architect reports that the sales team’s meeting prep dropped by 40% and their close rate went up 8% since Copilot got embedded into the pre-call workflow.
The Feature Tourist runs a training called “Introduction to Copilot.” The Impact Architect says: “Let me walk you through Day in a Life of Sarah. She’s a customer success manager. Here’s how Copilot changes her day from the moment she opens Outlook to the moment she finishes her quarterly business review.” Same features. Completely different training. Because now it’s about Sarah’s job, not about Copilot’s capabilities.
The Feature Tourist tells the board: “Adoption is growing.” The Impact Architect tells the board: “Copilot-assisted processes freed up 2’400 hours last quarter, worth about CHF 264’000 in capacity. Here’s exactly where we’re reinvesting those hours.”
Now, this is called a reality check for a reason. I know Impact Architecture sounds clean on paper. In practice, measuring these things can be hard. Sometimes really hard. But even when the numbers aren’t perfect, it’s a different thinking pattern and that matters. When your employees stop seeing Copilot as “that AI thing from the training” and start seeing themselves in it, in their Monday inbox, their Tuesday standup, their Wednesday client prep, that’s when they turn capabilities into use cases. And that’s when business impact stops being a slide deck promise and starts being something you can actually point to.
The Impact Chain
So how do you actually make this shift? I use a framework I call the Impact Chain with five steps. Easy to follow, because the issue isn’t that we need a more complicated framework. It’s that most organizations don’t care about this step.
1. Business Problem. Always start with the business. Identify the friction that has a price tag. Time, money, quality, risk. Not “let’s explore what Copilot can do” but “our tender responses take 40 hours and we’re losing deals because we’re too slow.” If you can’t name the problem, you’re touring features.
But there’s a step before the step: you need to understand how your people actually work today. Are they already mature in digital collaboration, or are they still saving documents on their desktop, sending attachments instead of sharing links, working in tools that Copilot can’t easily reach? Because if the foundation isn’t there, no amount of AI will fix it. You can’t build Copilot workflows on top of broken collaboration habits. Understanding how people work is where every Impact Chain has to start.
2. Day in a Life. Now map how work actually happens, role by role. Not a process diagram from 2019, but Sarah’s real Monday morning. She opens Outlook, triages 40 emails, prepares for two client calls, updates a pipeline report, joins three meetings.
Where does she lose time?
Where does quality drop?
Where does she do repetitive work that drains her energy?
This is where Feature Tourism ends and Impact Architecture begins, because now you’re not asking “what can Copilot do?” but “where does Sarah need help?” When employees see themselves in the journey, they stop treating Copilot as a training exercise and start treating it as part of how they work.
3. AI Intervention Point. Only now do you look at where Copilot fits. Which specific capability addresses which specific bottleneck in Sarah’s day? “Use Copilot in Word” is a feature. “Use Copilot to draft tender responses from our SharePoint knowledge base, cutting Sarah’s initial draft from 8 hours to 2” is an intervention. The difference matters and makes a huge difference.
4. Before/After Measurement. Set baselines before you deploy, like
Time to complete
Error rates
Cycle times
Quality scores.
Whatever the business already tracks. (to be honest, this is another issue to identify AI’s impact. Most organization didn’t care at all about those numbers in the past. But now it’s the most important thing 🙂) Then measure again at 30, 60, 90 days. Without a baseline, you’re collecting opinions. “People say they like it” has never survived a budget review.
5. Reinvestment. This is the one almost everyone misses, and it’s where the actual value lives. When AI saves time, what happens with that time? Research shows 80% of people just spend it on other tasks, often low-value ones like inbox management. Frontier Firms don’t leave that to chance. If Copilot saves your finance team 8 hours a month, those 8 hours get explicitly redirected to scenario planning or strategic analysis. The saved time is the input for better work. That’s where the P&L impact actually shows up.
What I would Change, if I were in Your Set
If you recognize Feature Tourism in your organization, here’s where I’d start.
Start with why. You see it in my background and Simon Sinek says it for years. Identify your why. Why are you implement Copilot in your organization? What’s your goal? That’s why we always start with a goal setting workshop in our Copilot projects.
Lead with problems, not demos. Every Copilot project should begin with a business question. “What’s our most painful recurring process?” beats “Let’s show people what Copilot can do in Teams” every single time.
Ditch the generic training. Have you already completed the Copilot basic sessions: Nobody needs another “Introduction to Copilot” webinar. Build role-specific, workflow-specific sessions using real data from your organization. A financial controller doesn’t care about Copilot in PowerPoint. Show them Copilot in their actual month-end close.
Track outcomes, not logins. Active users is a vanity metric. What actually moved? Cycle times? Error rates? Capacity freed? Revenue influenced? Use the Copilot Dashboard in Viva Insights as a start, but connect it to the business KPIs your leadership already watches.
Think platform, not chatbot. The 2026 Copilot ecosystem (Agent Mode, Copilot Studio, Researcher with Computer Use, Project Opal) is about making AI an active part of how your business runs. That’s when the ROI conversation changes from “minutes saved per email” to “processes we’ve rebuilt.”
What Frontier Firms Do Differently
This is where I see the clearest gap between organizations that plateau and organizations that break through. And it comes down to how they train their people.
Most companies start with feature-based enablement. “Here’s Copilot in Outlook. Here’s Copilot in Teams. Here’s how you write a prompt.” And that’s fine, because that’s a good foundation. (I do this as well) People need to understand the basic capabilities before they can do anything with them.
But that foundation is exactly that: a foundation, but now let’s build this skyscraper. The problem is that most organizations stop there (If they have even done this step.). They run the feature training, check the box, and assume employees will figure out the rest on their own. And that’s where it falls apart. Because the step from “I know Copilot can summarize emails” to “I know how Copilot fits into my specific Tuesday morning when I’m prepping for three client calls, reviewing last week’s pipeline numbers, and writing a follow-up proposal” is a massive leap and most employees simply can’t make that leap on their own. And it’s not your people’s fault.
You’re asking a marketing manager or a project controller to do the transfer work that should be done by whoever designs the enablement program. You’re saying “here are the Lego bricks” without showing them what to build.
Frontier Firms flip this. They treat feature training as Level 1. And then they invest the real effort in Level 2: Day in the Life journeys.
What does that look like? You sit down with a role (say, a project manager in your consulting practice) and you map their actual week. The Monday morning inbox triage. The Tuesday project status meetings. The Wednesday client prep. The Thursday reporting. The Friday planning for next week.
Then, you go back and draft a day in the life journey for their role, including their specific tasks and areas where they can infuse AI into their work.
The feature is still there. Copilot in Teams, Copilot in Excel, Copilot in Outlook. But now it’s embedded in their context. It’s not “Copilot can summarize a meeting.” It’s “After your Tuesday standup, ask Copilot to pull the open action items and draft a status update for your project sponsor. Here’s the prompt. Here’s what the output looks like. Here’s how you refine it.”
That’s when adoption sticks. Because you’ve done the transfer work for them. You’ve connected the feature to the moment in their day where it actually helps. And suddenly it’s not “another tool I should probably try” but “the thing that saves me 20 minutes every Tuesday.”
The organizations that get this right build a library of these Day in the Life journeys, role by role. Each one grounded in real workflows and with real prompts That’s the difference between enablement that creates a spike and enablement that creates a habit.
Feature training builds awareness. Day in the Life journeys build adoption. Frontier Firms do both, and they know which one is the foundation and which one is the building.
On a Personal Note
I know, sometimes we just want to be a tourist and explore the neighborhood. But that’s not where you stay to life. I will be your Tour guide in the city of Copilot to explore all the exciting sightseeings here on LinkedIn.
But at Copilot projects I’m the impact architecture with your team. And I love both side of my daily job 😍 But please keep in mind that the way we promote things on LinkedIn, is not the way it should be done in your organization.
The organizations I call Frontier Firms don’t start with “look what it can do.” They start with “here’s what we need to solve.”
Start generate Business Impact and subscribe this newsletter