PRAPI Research · 2026-10-16

What Gets Non-Technical Teams to Adopt AI, and What Kills It

Most AI rollouts to non-technical teams fail on adoption, not capability: the tool works in a demo, then sits unused while the team routes around it. We asked operators who deployed AI to support, operations, sales, marketing and customer success teams for the one concrete thing that moved real usage, and where it died anyway. Their answers converge on a single rule: people adopt AI that lives inside the work they already do and cannot act irreversibly in their name.

10 contributors cited


Almost nobody we heard from blamed the model. The tools worked. What failed was where the AI sat in the day, what it was allowed to do on its own, and whether the people using it could check its work faster than they could do the work themselves. The fixes that moved usage were small, structural, and repeatable.

Pattern 1: Put the AI inside the work, not next to it

The most common failure was the blank prompt: a new tool, an empty box, and a team expected to invent uses for it. Kuber Sharma, Senior Director of Product Marketing at UiPath, described the switch that changed it for a product marketing team of about 20 people:

We stopped asking people to open a new tool and start from a blank prompt. We built the AI into the document they were already using. An analyst running a win-loss review opened their usual template, and the AI had already pulled the relevant competitive data into draft form. They were editing, not generating.

By his account, that move took usage from around 30% at week three to over 80% by week eight. Adarsh Kumar of The Dollar Craft saw the same thing with a four-person editorial team, where adoption sat at zero for three weeks:

We changed one concrete thing. We removed the chat box. We replaced it with a single button inside their existing workspace. They pasted a target keyword, clicked the button, and the AI delivered a structured brief in the background. Usage jumped to 100% within two days.

Kenneth Shen of Pigment made the AI output the default starting point for his customer success reps rather than an optional add-on:

We changed the default workflow so that when a CS rep opened a user profile, the AI summary was already there. They did not have to choose to use it. It was just part of how they prepared.

And Mahesh Shivnatri, a project delivery manager at Deloitte, reports the same mechanism on an enterprise service platform serving more than 85,000 employees, where AI case summaries were generated from ticket history automatically:

using AI cost the agent zero extra clicks. The proof for me was handling time, which settled at an average saving of about 10 minutes per ticket.

Pattern 2: The AI drafts, a person decides

The second pattern is about trust. Non-technical teams did not resist AI because it was complicated. Karmendra Pandey, Practice Architect in the AI & ML practice at TEKsystems, whose team rolls out production AI agents to operational and business teams, put it most precisely:

Non-technical users don't resist AI because it's complicated; they resist it because it can do something irreversible in their name.

His fix was structural: the agent never acts directly. It drafts a summary, a recommendation or a prepared action, and a person approves before anything happens. He knew it had stuck when the approval step stopped being a checkpoint and became the job itself, with new requests starting with "can the agent draft it first?"

Madhuri Somara, a product leader at Microsoft working on customer service AI, described a version of this that lets teams build trust before the AI acts at all:

The biggest adoption unlock I've seen for non-technical teams, especially in support and operations, wasn't training. It was letting them watch the AI be wrong safely before it ever acted.

In "shadow mode," the AI proposes what it would do on real cases while a human still makes the call, and the team reviews where the two differ. In her words, that "changed the conversation from 'will this replace me?' to 'why did it suggest that?'" Her sequence for rollouts: let the AI assist first, then recommend, and only then act.

Pattern 3: Draw a hard line around what the AI may do

Teams relaxed once they knew which work would never be handed to the machine. Louis Ducruet of Eprezto deployed an AI chatbot for customer support and made the boundary explicit:

Information goes to the bot. If a customer asks what a policy covers, that answer exists and does not change based on who is asking. Two kinds of cases never touch it. Anything sensitive, and the clearest example is a customer asking for their money back, and anything that needs an action in the back office the bot cannot perform.

Once the reps knew those cases always came to them, "they stopped treating the bot as a threat and started treating it as the thing that cleared their queue." He reports the bot now resolves about 70% of conversations, with one rep supporting more than 20,000 customers.

Pattern 4: Show the evidence, not just the answer

Teams ignored AI output they could not check quickly. Sidharth Gopakumar of Molecule built an account-health system for a customer success team, and the first version, a bare risk score per account, went mostly ignored:

Usage changed when every flag came with the two or three signals behind it, for example "three unresolved tickets about the same report, and logins down for a month." Then a CS manager could open the account, check the evidence in a minute, and decide whether to call.

Alex Chaidaroglou of Altosight reached the same conclusion with an AI-built weekly report in which every number links to its source:

Adoption dies wherever checking the output costs more than doing the task yourself.

People don't resist AI, they resist output they can't verify quickly.

Where it still leaks

The operators were candid about where adoption died even when the tool worked.

Outside the workflow. Karmendra Pandey saw pilots die when they lived outside the team's daily workflow: "a separate portal or chat window nobody opened after week two." Sidharth Gopakumar saw the same: if people have to open a separate tool to see the output, they stop checking within a few weeks.

At the last step. Mirgen Hoxha of Motomtech runs an agent pipeline where drafts land in the team's group chat with an approve button, and the tap is the publish. On one stream built that way, 54 of 54 approved items went out. The steps that still needed a laptop did not:

Half of those approved items, 8 of 16, expired before anyone did. The draft was good and the decision was already made. The tool worked. The last ten minutes of human effort did not happen.

His advice: "Measure adoption at the final step, not the AI step."

When the AI answers what it can't know. Louis Ducruet's bot looked broken to everybody until it could reach the customer database: "adoption does not die because people are scared of AI. It dies when the tool is allowed to answer questions it has no way of answering."

When it replaces judgment instead of supporting it. Kenneth Shen's rollout worked for customer success and failed for marketing, where the drafts were "adequate but generic" and the team wanted creative control: "Adoption only works when the tool amplifies what the person is already good at instead of substituting for it."

After one confident mistake. Madhuri Somara warned that "one visible mistake can erase months of goodwill," and Sidharth Gopakumar tuned for fewer, better-explained flags because "one false alarm on a key account costs more trust than ten correct ones earn."

The through-line

Across every answer, the same rule held: put the AI inside work the team already does, let it draft rather than act, and make its output faster to check than to redo. Alex Chaidaroglou had the line for it:

You don't earn trust in an AI system the hundredth time it's right. You earn it the first time it catches you being wrong.

Contributors

  1. The biggest adoption unlock I’ve seen for non-technical teams, especially in support and operations, wasn’t training. It was letting them watch the AI be wrong safely before it ever acted. In the customer service deployments I’ve worked on, teams were wary of AI that closes cases or sends follow-ups on its own. What moved them was a “shadow mode.” The AI proposes what it would do on real cases while a human still makes the call, and the team reviews where the two differ. That changed the conversation from “will this replace me?” to “why did it suggest that?” Once people start scrutinizing the AI instead of fearing it, usage sticks. What kills adoption is the opposite: turning on automation and measuring only completion. An AI that closes a ticket that wasn’t actually solved creates repeat contacts, and one visible mistake can erase months of goodwill. Staff stop trusting it and work around it. Three things helped. Let the AI assist first, then recommend, and only then act. Make every AI action visible and reversible. And win over the respected skeptic on the team first. In one healthcare example, a physician coordinating care across many nursing homes engaged because the tool turned incoming requests into clear next actions. It removed a task he disliked instead of adding one. I knew it had stuck when teams started asking the AI to take on more, not less. Madhuri Somara, Senior Product Manager, Microsoft
  2. Team: product marketing at a large enterprise software company, about 20 people. Tool: a custom LLM layer built on top of competitive intelligence feeds and analyst research. What moved real usage was embarrassingly simple. We stopped asking people to open a new tool and start from a blank prompt. We built the AI into the document they were already using. An analyst running a win-loss review opened their usual template, and the AI had already pulled the relevant competitive data into draft form. They were editing, not generating. That switch — from blank to pre-populated — got us from around 30% usage at week three to over 80% by week eight. What killed adoption in the first three months: we started with the most enthusiastic people. Power users gave us great feedback, shipped great output, and made us think we had product-market fit. We did not. When we rolled to the wider team, we hit a wall of people who weren't skeptical of AI — they were just busy. They didn't have 20 minutes to learn a new workflow. The early adopter loop had completely hidden this. The moment I knew it stuck: a marketer who had been the most resistant asked me how to set up the briefing agent for a launch she was running. Without being asked. She'd figured it out herself and was showing a colleague. That's the only adoption signal I trust — unsolicited internal training. Name: Kuber Sharma Role: Senior Director, Product Marketing Company: UiPath
  3. I'm a Practice Architect in the AI & ML practice at TEKsystems. My team builds and rolls out production AI agents on AWS for enterprise clients. The end users are operational and business teams, not engineers — people whose daily work is document- and process-heavy, using the agent inside the tools they already work in. The one concrete thing that moved real usage was a trust mechanism, not training: the agent never acts directly. It drafts — a summary, a recommendation, a prepared action — and a person on the team approves before anything happens. Non-technical users don't resist AI because it's complicated; they resist it because it can do something irreversible in their name. Once the team understood that nothing goes out without one of them approving it, usage stopped being a pilot people were polite about and became the default way the work got drafted. I knew it had stuck when the approval step stopped being a checkpoint and became the job itself — reviewers editing drafts instead of creating documents from scratch, and new requests starting with "can the agent draft it first?" Where adoption died even though the tool worked: in the pilots that lived outside the team's daily workflow — a separate portal or chat window nobody opened after week two. The technology was fine; the placement was wrong. Every rollout that survived put the agent inside the tool the team already lived in, with the approval step where their existing sign-off used to be.
  4. We rolled out AI-generated case summaries to client service teams on an enterprise service platform that served more than 85,000 employees. What moved real usage was making it automatic: the summary was generated from the ticket history without anyone having to ask for it, so using AI cost the agent zero extra clicks. The proof for me was handling time, which settled at an average saving of about 10 minutes per ticket. In my experience, adoption dies when AI adds a step to someone's day, even if the output is good. People won't open another tab or write a prompt in the middle of a queue, so if the AI isn't already sitting in the workflow they use, they'll quietly route around it.
  5. We rolled AI drafting out to our marketing team. Blog posts, social posts and outreach replies are drafted by an agent pipeline, and a person approves every one before it goes anywhere. The one thing that moved real usage was making approval the last step. A draft lands in the team's group chat with an approve button, and the tap is the publish. No second system, no login, no copying text into another tool. On one stream built that way, 54 of 54 approved items went out. Adoption died on the steps that still ended in a browser. Some platforms only accept submissions through their own website, so after someone approved a draft, a person still had to sit down at a laptop, log in and paste it in. Half of those approved items, 8 of 16, expired before anyone did. The draft was good and the decision was already made. The tool worked. The last ten minutes of human effort did not happen. We knew it had stalled when our reminder fired right on schedule and the count of those laptop sessions over the previous five weeks was zero. A reminder does not fix that. Measure adoption at the final step, not the AI step, because a team will approve all day from a phone and still never do the part that needs a desk. Name: Mirgen Hoxha Role: CEO Company: Motomtech Mirgen Hoxha CEO, Motomtech (https://www.motomtech.com) Quotes are attributable to: Mirgen Hoxha, CEO of Motomtech
  6. The team was customer support at Eprezto, and what we deployed was an AI chatbot on customer conversations. The thing that actually moved usage was not training. It was drawing a hard line about which cases the bot handles and which go to a person. Information goes to the bot. If a customer asks what a policy covers, that answer exists and does not change based on who is asking. Two kinds of cases never touch it. Anything sensitive, and the clearest example is a customer asking for their money back, and anything that needs an action in the back office the bot cannot perform. Once the reps knew those always came to them, they stopped treating the bot as a threat and started treating it as the thing that cleared their queue. Where it nearly died is more interesting, because the tool worked. The bot answered knowledge questions well and still looked broken to everybody, because a customer asking for their policy number or how much they pay monthly is not a knowledge problem. That answer lives in our database, and the bot could not reach it. We had to put a programmer on building that access through APIs. Until that shipped, the reps were reading the transcripts and concluding the bot was useless. The moment I knew it stuck was when it started resolving about 70% of conversations and one rep could support more than 20,000 customers without the queue getting worse. The pattern I would give other operators: adoption does not die because people are scared of AI. It dies when the tool is allowed to answer questions it has no way of answering. Name: Louis Ducruet Role: Founder and CEO Company: Eprezto
  7. Name: Sidharth Gopakumar Role: Product Manager, Integrations and Reporting Company: Molecule Software Team and tool: our customer success team, which is not technical, and an AI-assisted account health system I built. It pulls support tickets, complaints, customer sentiment, and product usage into one risk signal per account, so the team can see trouble before a renewal conversation. What moved real usage: showing the reasons, not just the score. The first version gave each account a risk level, and the team mostly ignored it, because a red flag with no explanation felt like one more dashboard to argue with. Usage changed when every flag came with the two or three signals behind it, for example "three unresolved tickets about the same report, and logins down for a month." Then a CS manager could open the account, check the evidence in a minute, and decide whether to call. Product and CS also started working from the same signals instead of separate spreadsheets, so the flag became something both sides trusted. The moment I knew it stuck: the system flagged a large account for a cluster of unresolved tickets on one report. The CS lead called them that week, we fixed the report, and the renewal went through. Before, we would have heard about it at renewal. Where adoption stalls even when the tool works: when the flag shows up somewhere the team does not already work. If people have to open a separate tool to see it, they stop checking within a few weeks. The other failure is a confident wrong flag. One false alarm on a key account costs more trust than ten correct ones earn, so we tuned for fewer, better-explained flags rather than catching everything.
  8. Name: Kenneth Shen Role: Founder & CEO Company: Pigment (pigment.is) We rolled out AI-assisted career assessment interpretation to our customer success team. The tool helped CS reps explain complex assessment results to users in simpler, more personalized language. The one thing that moved real usage: making the AI output the starting point of every user conversation, not an optional add-on. We changed the default workflow so that when a CS rep opened a user profile, the AI summary was already there. They did not have to choose to use it. It was just part of how they prepared. Before that change, adoption was maybe 30 percent. Most reps would skim the AI summary and then explain things their own way. After it became the default starting point, usage jumped because the tool was removing a step they already did manually, not adding a new one. The moment I knew it stuck was when a rep told me she could not remember how she prepped for user calls before the AI summary existed. Where adoption died: we tried the same approach with marketing. The AI drafts it produced were adequate but generic. The marketing team wanted creative control, and the tool felt like it was replacing their judgment rather than supporting it. We pulled it. Adoption only works when the tool amplifies what the person is already good at instead of substituting for it.
  9. Hi Tom, Answering your query on what gets non-technical teams to adopt AI [PXE2]. *Team and deployment* I run a bootstrapped software company of four. Marketing and ops moved our weekly lead and performance reporting to an AI-built report. *What moved real usage: a standing job, not an invitation* Usage didn't move while AI was something people could try. It moved when the AI owned a deliverable: - The report lands every Monday, whether anyone asks for it or not. - Every number links to its source, so checking any figure takes seconds. *The moment it stuck* The week the report flagged our own lead tracking as wrong: misconfigured form triggers and spam submissions were inflating the totals. - The numbers had looked plausible, so nobody had questioned them. - Once it caught us being wrong, nobody needed a reminder to read it. *Where adoption dies (even when the tool works)* Anyone on the team can adopt any AI tool for any problem. That policy makes the failure pattern obvious: - Adoption dies wherever checking the output costs more than doing the task yourself. - People don't resist AI, they resist output they can't verify quickly. *Pull quote if useful:* "You don't earn trust in an AI system the hundredth time it's right. You earn it the first time it catches you being wrong." I can expand on any of these over email or a quick call if needed. If you want, once your article goes live, I can share it on my LinkedIn profile, whether you use anything from my email or not. Thanks! *Attribution: *Alex Chaidaroglou, Founder & CEO, Altosight <https://altosight.com/> — 15+ years in pricing, e-commerce, and SaaS *LinkedIn:* linkedin.com/in/alexchaidaroglou <https://www.linkedin.com/in/alexchaidaroglou/> *Headshot: * https://altosight.com/wp-content/uploads/2026/04/alex_chaidaroglou.jpeg
  10. Hi Tom, We rolled out a custom LLM content brief generator to our four person editorial team at The Dollar Craft. Adoption was zero for the first three weeks. The tool worked perfectly. The interface killed it. We initially gave the team a blank chat interface and a list of best practice prompts. Non technical marketing teams do not want to become prompt engineers. They stared at the blinking cursor and went back to their old manual Google Docs workflow. We changed one concrete thing. We removed the chat box. We replaced it with a single button inside their existing workspace. They pasted a target keyword, clicked the button, and the AI delivered a structured brief in the background. Usage jumped to 100% within two days. Adoption dies when you ask non technical teams to learn a new interface or learn how to talk to a machine. It thrives when you hide the AI behind a single button in a workflow they already understand. Best regards' Adarsh Kumar Founder, The Dollar Craft

Methodology

This report draws on direct responses to a research brief PRAPI posted publicly from October 8 to October 15, 2026. The brief asked operators who had rolled an AI tool out to a non-technical team to name the team and the deployment, the one concrete thing that moved real usage, the moment they knew it stuck or stalled, and where adoption died even though the tool worked. It stated that vendors pitching their own tools were not wanted.

Responses came through three channels: the MentionMatch source-request network, the Connectively source board, and the PRAPI response form on prapi.dev. We received 93 submissions. Each ran through an AI-detection check at intake; two were rejected as generic or templated and are excluded.

Ten contributors are quoted. Selection was editorial: we favored first-hand, specific accounts that answered the brief's questions, and set aside answers that promoted the respondent's own product, repeated another contributor's point, or could not be attributed to the person named. Every contributor quoted consented to named citation.

Quotes are verbatim from the submissions, trimmed for length. Figures such as usage rates, time savings, and resolution rates are the contributors' own reports and were not independently verified. Titles reflect what contributors provided, corrected where a public professional profile showed otherwise. Contributors speak for themselves, not for their employers.

Research conducted by PRAPI. GTM for founders running portfolios.

Research conducted by PRAPI. PR system for founders running portfolios. Try PRAPI →