Menu
The company didn't mean to create a second class of users.
Policy, contracts, and regional constraints put one part of the organization on a different approved AI tool than the rest. From headquarters, the decision can look clean. From the team on the second tool, it can feel like they got the lesser path.
They still show up. They still try. They also start saying they feel left behind.
That isn't mostly a feature-checklist problem. It's a second-tool confidence gap: people are using what they're allowed to use, and they don't believe it can carry their work as far.
The fix that keeps the company safe is not a workaround. It is enablement on the approved tool they actually have, with honest parity where parity is possible, and a clear answer when someone asks how to route around policy.
Two tools can both be "AI" and still create a lived hierarchy.
People compare notes across regions. Someone describes a smoother path on the primary tool. Someone on the second tool hears that and concludes they are stuck with a weaker version. Even when leaders wish they could consolidate to one stack, the split remains for real reasons: contracts, data residency, vendor access, risk.
If enablement only celebrates the primary tool, the second-tool team learns a quieter lesson: good AI happens elsewhere. Usage may continue. Confidence does not.
Confidence recovers when people see strong work on their approved tool, on jobs they own, with coaching that doesn't apologize for the stack every five minutes.
We keep seeing the same picture without needing a named account to make the point.
Leadership hates running two major tools and wishes consolidation were simple. Day to day, one path feels smoother than the other. Teams on the second tool describe feeling left behind. Relayed in paraphrase, the emotional content is clear even when the exact wording is soft: they believe they got a worse version. Then a leader on that same path discovers a capability midstream and realizes they had no idea the approved tool could do it.
That last beat matters. Some of the gap is real platform constraint. Some of it is undiscovered capability on the tool they already have.
That is one problem, not permission to break policy. You don't need a workaround first. You need training and proof on the approved path.
Same tool is simpler for standards, support, and confidence. It is not always available.
When policy requires a split, stop treating "eventual consolidation" as the enablement plan. Consolidation may remain a strategic wish. Enablement has to work this quarter on the tools people are actually allowed to open.
A practical stance:
"Same tool someday" is not a curriculum.
Design enablement for the stack in the room.
If training materials are written for the primary tool and then lightly adapted, second-tool users will feel the adaptation. Build the session for them.
Be direct.
Workarounds that dodge regional, contractual, or security controls are not clever enablement. They are risk the company already decided not to take. Leaders who have lived this usually name contract risk out loud for a reason.
Useful response pattern:
Never publish workaround steps. Never wink at them in community posts. The durable page's job is confidence on the approved tool, not a map around policy.
Should every team be on the same AI tool?
Same tool is easier for standards and confidence when risk and contracts allow. When policy requires a split, enablement must still run on each approved tool. Waiting for consolidation freezes capability. Train what people can open now.
How do you train people on the tool they're approved to use, not the one they want?
Build the session for the stack in the room. Demonstrate on owned jobs, leave keepables that work there, surface undiscovered capability on purpose, and name real constraints honestly. Do not run a primary-tool curriculum with a thin adaptation layer.
What do you tell teams who ask about workarounds?
Acknowledge frustration, refuse the bypass, restate the approved path, and offer real help on that path. Route consolidation or exception requests through proper channels. Do not suggest VPN or policy dodges. Contract and security risk are the point.
If the pattern on this page sounds familiar, start with the free AI Operations Reality Check. One everyday workflow. No pitch deck.
If you want a bounded diagnostic and a written next-step memo, the AI Operations Review is the paid step after that ($997, not an open-ended contract).
Susan Westwater is the CEO and Co-Founder of Pragmatic Digital. She helps mid-market and PE-backed teams move from scattered AI pilots to governed, measurable workflows that actually deliver operating leverage. With 25+ years in CX and brand leadership at Leo Burnett and Ricoh USA, Susan specializes in turning AI ambition into repeatable systems that protect brand voice and reduce revision cycles. She is co-author of Voice Strategy and Voice Marketing.
Weekly insights on AI adoption, workflow, and what's actually working in mid-market organizations.