top of page

When Your Team Stops Using AI

Writer: Branden Bell
Branden Bell
Sep 26
7 min read

Updated: Sep 27

One less step. An olive cord passes through cream paper loops, with an unnecessary terracotta loop removed, illustrating less duplicate work in an AI rollout.

Picture a familiar Friday afternoon. The new AI tool has produced a tidy client summary. Someone still needs to check the facts, paste it into ClickUp, update a spreadsheet and tell the owner which version to read.


By Monday, the team has gone back to its old notes.


That scene is illustrative, not a client story. But it gives you a better starting question than “How do I get everyone excited about AI?”


For AI adoption in a small business team, start by finding what the new workflow asks people to do twice. Then check whether they have clear inputs, a way to judge the output, permission to use the data and somewhere to get help. Training matters. So does removing work.


Our previous guide showed how to measure AI workflow savings after review and upkeep. This is the next test: can the people doing the job use the improved process without needing a rescue every time?



Ask to see the last abandoned attempt


Skip the general satisfaction survey for a moment. Ask one person to walk you through the last task where they tried the new method and went back to the old one. Use an approved example with private details removed where necessary.


Try these questions in order:


  • What were you trying to finish?

  • Where did you have to stop and find something?

  • Which part did you check or enter twice?

  • What made the old method feel easier at that point?

  • What would need to change for you to try again?


The useful answer is a moment, not a personality trait. “I didn't know which policy was current” points to source ownership. “I checked every line because the first answer made up a date” points to reliability. Neither problem is solved by another motivational announcement.


Listen for a different answer, too: “I'm worried this will be used to judge my performance.” Explain how the pilot evidence will be used, invite private feedback and address the concern directly. Don't treat every objection as a software problem or promise staffing outcomes you haven't decided.



Four places to look before buying another tool


These are practical diagnostic categories, not a validated adoption score.


The input is hard to find. People recreate background information in every chat. Give the task an approved source and a short, reusable brief. Assign someone to keep it current.


The answer is expensive to trust. The draft sounds good but lacks references, invents details or needs too much repair. Narrow the task and define the acceptance check. More fluent output doesn't remove the checking work.


The handoff is unfinished. The useful result lives in a chat while the next person works elsewhere. Decide where the accepted output belongs and who puts it there. A manual handoff can be fine for a pilot if it is explicit and counted.


The old process never stopped. Employees must use the AI method and still maintain the old version “just in case.” That may be sensible during a bounded comparison. Give the comparison an owner and an end condition so it doesn't become permanent duplicate work.


The OECD's 2025 SME workforce report, based on a 2024 survey of more than 5,000 SMEs across seven countries, found that barriers among non-adopters included fit with the work, information concerns and employee skills. That supports checking practical conditions, not assuming enthusiasm is the only missing ingredient. It does not establish why any particular team stopped using a tool after a week.



A kickoff summary with one less job attached


Here's a fictional walkthrough. The names, process and numbers are invented to make the decision concrete. It is not a completed implementation or a promised result.


A six-person service business wants to turn approved kickoff notes into a short delivery brief. Maya coordinates the project. Luis reviews the scope. The team keeps its delivery tasks in ClickUp.


The rollout that adds work


Maya copies approved notes into an AI tool, asks for a summary and checks the answer. She then pastes it into ClickUp and rewrites it in the owner's tracking spreadsheet. Luis adds a correction in chat. The spreadsheet and task now disagree.


In this illustration, preparing and reviewing the brief takes 18 minutes across everyone involved, entering the same information twice takes 8, and reconciling the correction takes 6. Total: 32 minutes. The previous method took 25 minutes for comparable work.


The seven extra minutes are a process problem to investigate. They don't prove that the model is useless or that Maya needs a longer training course.


The smaller redesign


The owner agrees that the accepted ClickUp brief will be the record for scope and next steps. The spreadsheet keeps a link and project identifier, not another copy of the narrative. Any accounting, contractual or recordkeeping requirements are checked before removing fields.


Maya uses the approved notes to prepare a draft containing three sections: confirmed decisions, open questions and proposed next actions. Luis reviews it against the notes and makes corrections in that same brief. Nobody treats a suggested owner or date as agreed until a person confirms it.


The handoff has a clear finish: the reviewer accepts the brief, unresolved questions remain visible, and the next teammate knows which record to use. If the AI output is unreliable, Maya can write the same brief manually. The single-record improvement still has value.


Proposed test: run five comparable kickoff briefs through the revised method. Record preparation, review, handoff and later repair time, including failed attempts. Involve the people receiving the brief. Five examples can expose friction, but cannot establish long-term reliability or a statistically dependable time saving.


Keep the change only if the evidence supports it: the team can find the current brief, scope is accurate and total effort is acceptable. If review still consumes the benefit, reduce the AI task to organizing the notes or return to the manual brief. Don't force the larger workflow to justify a license.


For ownership, statuses and handoffs in the workspace itself, use the ClickUp workflow hub. The goal is a dependable place to work, whatever prepares the draft.



Teach the awkward example


A clean demonstration shows where the buttons are. A useful practice session also includes a missing deadline, contradictory notes or a request the tool should leave unresolved.


Ask each participant to complete a small example, explain what they checked and show how they would get help. Make the source material and review criteria available afterward. Give people working time to practice, not homework squeezed into an already full day.


Don't expect the same lesson to serve everyone. In Generative AI at Work, Brynjolfsson, Li and Raymond studied a customer-support setting and found that effects varied substantially across workers. Less experienced workers benefited differently from the most experienced workers. That is evidence from one setting, not a forecast for your team. It is a good reason to look at role-specific work and quality rather than a single company-wide usage target.


An experienced teammate might need the freedom to skip an unhelpful suggestion. A newer teammate might need an example of what a checked, acceptable brief looks like. Both need permission to report a bad output.


Use the existing messy-input testing checklist to choose practice cases. Keep client-facing actions under the agreed review boundary while people learn.



A small reset you can run next week


This is a proposed exercise, not a research-tested timetable. Stretch it if the work happens less frequently.


  1. Observe one attempt. Find the exact point where someone abandons or works around the new process. Record the reason without turning it into a performance ranking.

  2. Choose one repair. Remove an unnecessary duplicate, clarify an approved source or make the acceptance check explicit. Keep necessary controls.

  3. Practice with a realistic example. Include an ambiguity. Have the person doing the work and the reviewer agree on what “finished” means.

  4. Try ordinary work with support available. Name the person who handles exceptions and where feedback goes. Keep a usable fallback.

  5. Make a decision together. Continue, revise or stop based on accepted outputs, total effort, unresolved problems and the team's account of the work.


A compact log needs only the work item, whether the new method was suitable, whether it was tried, whether its output was accepted, the reason for any fallback, and time spent repairing it. Track issues by workflow before tracking them by person. Collect only what the pilot needs.


Logins tell you that someone opened the tool. They don't tell you whether the next teammate received a usable result. The latter is the habit worth building.



Questions about team AI adoption


Should everyone use AI every day?


Not as a default target. Define the jobs where it is useful and appropriate, then measure those jobs. Someone handling work outside that scope may have no reason to open the tool that day.


What if the team says the old way is faster?


Observe comparable work and count the whole process, including review and repair. If the old method wins at the required quality, keep it while you investigate. Adoption is not a reason to accept worse work.


How much AI training does a small team need?


Enough to perform the chosen task, check the result, handle uncertainty and use the fallback. Start with a role-specific exercise and follow-up support. Add training when observed problems show what is missing.


Can this approach work with Claude, ChatGPT or Codex?


Yes as a process-design approach, not a claim that those products have identical features. Use an approved setup, verify current access and data rules, and define the boundary between drafting and acting. A Codex-built integration also needs testing, ownership and support.


When should we bring in outside help?


When you can't identify where the friction comes from, the workflow crosses several tools or nobody owns implementation and follow-through. Bring examples of abandoned attempts and the accepted output you need. Those are more useful than a list of features to buy.



Bring the part people keep working around


I review existing business processes and implement practical improvements with Claude, ClickUp and ChatGPT/Codex. That includes the handoffs, checks and training that make the change usable by the team.


If the new tool has become another task on everyone's list, bring one recurring workflow for a process review. Start with the step people keep avoiding. There may be something useful to remove before there is anything else to build.


Comments


bottom of page