95% of Organizations Haven't Seen Measurable AI Impact

Ninety-five percent of organizations in MIT Project NANDA's 2025 State of AI in Business report had yet to see measurable P&L impact from their enterprise GenAI initiatives.

The problem was not access to capable technology. So what does that mean for customer support?

Not that human support becomes universally more important. That's too easy an answer, and it lets vendors off the hook for thinking carefully about where human attention changes outcomes. The better question is: which parts of support can AI make faster and cheaper, and which parts become more valuable once it does?

AI can already retrieve information, summarize documentation, compare published features, draft responses, and answer routine questions. Some of what customer support teams do today will become easier to automate. And it should. If a customer needs an answer that already exists in the documentation, making them wait for a person to retrieve it adds waiting time and little else.

The more interesting question is where does human value move as AI absorbs that work.

It moves toward the parts of the customer relationship that depend on understanding the customer's specific situation: discovering the requirement nobody documented, translating organizational context into system structure, carrying knowledge across an implementation, and adapting the system when the work changes.

That's a different argument from saying customer support matters because people prefer people. The position becomes, where do you need a person, and why.

The Failure Is Not a Lack of Trying

MIT's research gives us a useful place to start.

Workers at more than 90% of surveyed companies reported regular use of personal AI tools for work, while only 40% of companies reported purchasing an official large language model subscription. The researchers call this the "shadow AI economy."

Why can an individual get useful results from AI while a company-wide implementation struggles to produce measurable value?

Context. When you ask AI to help draft an email, you already know who will receive it, what happened before it, what tone will work, and what outcome you need.

You can evaluate the result because you brought most of the necessary context into the interaction yourself.

Move the same challenge into a shared business process and the context problem changes. The information required to complete one workflow may be spread across six people, three systems, a reporting requirement, a permission structure, and a workaround that has existed for four years without ever being written down. One employee knows why a field gets entered a certain way. Another knows why a report gets rebuilt before it reaches a funder. A third knows the exception that applies to one customer type.

None of that knowledge helps a system if nobody surfaces it.

An AI system cannot account for organizational context it has never been given. Someone has to find it first. That's where the human role enters the AI conversation: in finding the context the technology does not already have.

Discovery Becomes More Valuable as Research Gets Cheaper

AI has changed the front end of software buying.

You can summarize product pages, compare published features, organize reviews, and prepare questions before speaking with a vendor. Research that once required hours takes less time.

That's useful. It also exposes its limits. You can compare only the requirements you know to ask about.

Most software searches begin with the visible problem. Reporting takes too long. Approvals get stuck. Data lives in too many places. People spend hours moving information between spreadsheets. Those are useful starting points but they're not always the requirements a new system needs to address.

A slow reporting process may trace back to duplicate records stored across separate databases. An approval delay may come from two departments using different definitions for the same status. A spreadsheet problem may come from a process that changes depending on customer, funding source, project type, or who handles the next step, etc.

A comparison tool can tell you which platforms advertise reporting, workflow, or database features. It cannot identify a funder rule you didn't mention. It cannot uncover an exception your staff handles from experience. It cannot resolve a disagreement between departments if nobody has surfaced the disagreement.

Those requirements have to be discovered.

That means following the work from one person to the next.

• Why is this report rebuilt by hand?
• What happens when the standard approval path doesn't apply?
• Why do two teams maintain separate versions of this record?
• Which definition wins when those records reach an external stakeholder?

These are not feature-comparison questions, but rather they're discovery questions, and answering them is the first place human support separates from information delivery. As research gets cheaper, discovery becomes the scarcer skill.

No Feature Comparison Catches This Problem

Rural Resources serves 12 counties in Washington state as a community action agency. It began using Kintone in one department and expanded to more than 10. One of its heaviest administrative burdens was state reporting.

Before Kintone, staff spent more than 80 hours each month preparing reports for government funders. After implementation, that dropped to 2 hours.

The number is striking. The reason behind it matters more.

Government funders need Rural Resources to count unique individuals served, not total visits across its programs. The same person can appear in more than one database or service record. Staff had to identify those duplicates across separate sources before they could report an accurate count. "We need better reporting" would have described the visible problem accurately. It would not have described the requirement that needed to be solved.

Rural Resources needed a way to record, match, and report the same person across programs without rebuilding the count by hand at the end of each month. A long list of platforms with reporting features could have narrowed the market. None of that comparison could have designed the implementation around that specific operating rule.

Discovery determined what the feature needed to solve. That is what turned an 80-plus-hour reporting process into a 2-hour one.

Implementation Is Where Context Becomes Structure

Discovery finds the requirement. Implementation turns that discovery into a system. Those are related jobs. They are not the same job. A vendor can understand your problem during a sales conversation and still fail to translate that understanding into how records, permissions, workflows, and reporting get configured. Translation is where organizational knowledge either gets preserved or lost.

This becomes more consequential when AI enters the system.

Kintone's current approach to AI illustrates why. Its AI capabilities work with the apps, records, permissions, and team information already stored within Kintone. The point is not any individual AI feature. AI has more useful context when the structure surrounding the work already reflects how the work operates.

Software cannot create that organizational context on its own. Someone still has to understand what your team is trying to accomplish, which information matters, how the process works, and where the exceptions live. Implementation converts that human knowledge into system structure. Done well, it means the technology depends less on one employee remembering why the process works the way it does.

That's one place human value migrates in the AI era: away from retrieving information for the customer and toward structuring the information the technology needs to work for the customer.

Support Is What Happens When Reality Changes the Plan

Then the system goes live. Implementation builds around what you know at the time. Support responds to what you learn after people start using it.

Your team encounters an exception. A report changes. A customer introduces a requirement they hadn’t anticipated. A workflow that made sense during implementation becomes difficult after six weeks of daily use, when the cracks start showing.

This is where support becomes more than troubleshooting. Support, at its core, should be the mechanism for keeping the system connected with work that isn't standing still.

Kintone's White Glove process starts before implementation with questions about your work:

• how reporting works
• where tasks slow down
• who approves which records
• what happens when the normal process doesn't fit.

The purpose is to surface requirements that may never appear in an RFP or feature checklist. Those requirements feed into a proof of concept built around the actual use case. The relationship continues after launch.

About one to two months after go-live, the Kintone team conducts a Kaizen-style review. What has changed since implementation? Where is staff having difficulty? Which assumptions no longer hold?

A Kintone stakeholders, described the model succinctly:

"None of our competitors white-glove the service the way we do. They look at it as a transaction but we look at it as a partnership."

They also cited 20 referral centers across the Pacific Northwest that came through word of mouth over a two-year period, because of the connection Kintone made with Rural Resources before, during, and after the implementation process.

"Partnership" can become empty marketing language fast. What it should mean is continuity. The person helping you after launch understands what you were trying to accomplish before launch. When your process changes, the conversation doesn't start from zero. That continuity is a practical foundation of trust, because the person understands enough of the history and constraints to help make a judgment when the standard answer stops working.

Where Human Support Earns Its Place

None of this means every support interaction needs a person. That would miss the point.

AI should handle more routine retrieval, summarization, and repeatable troubleshooting as it improves. The human role becomes clearer when we stop defending the work AI can already perform well and start identifying what remains. MIT's research helps draw that line.

When enterprise users were asked about complex or long-term work, they preferred humans over AI by roughly nine to one. For short, defined tasks like drafting emails, producing basic summaries, users were comfortable relying on AI. As work required more context, judgment, and adaptation over time, preference shifted toward people.

That is not meant as an argument against AI. Instead, it’s an argument for putting human attention where it changes the outcome. Discovery finds the context. Implementation builds around it. Support adapts it. Partnership preserves it. That is where human value moves as automation absorbs more of the standardized work. Not across all of customer support, but toward the parts that cannot be standardized without first understanding the customer's work.

Five Questions to Ask Any Vendor About Post-Sale Support

That gives you a different framework for evaluating vendors.

Feature comparison still matters. So do security, integrations, pricing, AI capabilities, and technical fit. But once a product passes that evaluation, examine what happens around the software.

1. How will you learn how our organization works before you build anything? Ask what discovery takes place before configuration begins. Who identifies reporting requirements, exceptions, handoffs, definitions, and constraints that may not appear in your original request?

2. How does what you learn during discovery affect the implementation? Don't stop at whether the vendor asks good questions. Ask how the answers change the system they build. Where do workflow rules, permissions, and reporting requirements actually get reflected?

3. Who carries that context after launch? Find out whether post-sale support understands why the system was configured the way it was. If every problem starts with your team re-explaining the implementation from scratch, continuity has been lost.

4. What happens when our process changes? Ask how the vendor handles a requirement that surfaces after launch. What support is available when the original configuration no longer reflects your work?

5. Can we talk to customers about what happened after implementation? A demo shows what a platform can do. Existing customers can tell you what happened when assumptions changed, problems appeared, and they needed help adapting the system.

These questions are not proxies for whether the vendor is friendly. They test whether the vendor can preserve context across the life of the technology — which is the part of the investment that feature comparison cannot evaluate.

What Becomes Scarce When Automation Becomes Abundant?

AI will make more information available. It will make more answers immediate. It will automate more of the work that once required a person to retrieve, summarize, compare, or explain.

That changes the economics of human attention.

The interaction that requires a person is the one where no complete answer is waiting to be retrieved, where someone has to figure out what the question actually is before they can begin to answer it. These people cannot be automated without first understanding what the customer's work requires.

The human role doesn't retain its value because AI stops improving. It retains its value where improvement in automation makes the remaining human work more visible. AI can make the known parts of a software decision faster to evaluate.

The value of human support moves toward everything you do not know yet.