DEV Community

Tzvi Boxer
Tzvi Boxer

Posted on

What Tzvi Boxer Looks for Before Recommending Any AI Tool

People often ask me which AI tool I recommend. The honest answer is: I rarely start with a tool.

I start with whether recommending AI at all would be responsible. After more than twenty years helping organizations modernize systems and streamline operations — and after watching unused licenses pile up beside unfinished pilots — I have a filter I apply before I put my name next to any product suggestion.

That filter is not anti-AI. It is anti-waste. AI can create real leverage when the business is ready. When it is not ready, a recommendation is just an expensive way to look modern.

Here is what I look for before I recommend any AI tool.

1. A problem statement a frontline team would recognize

If leadership says “we need AI” and the people doing the work cannot name the pain in one sentence, I do not recommend a tool. I recommend clarity work.

A usable problem sounds like: “Our intake team re-keys the same customer details into three systems,” or “Managers spend half a day each week summarizing the same status updates.” A non-usable problem sounds like: “We want to be innovative,” or “Competitors have AI.”

Tools amplify the problem you actually have. If you cannot name it, AI will amplify fog.

2. Evidence the work is repetitive or pattern-based

AI earns its keep on volume with patterns: classification, drafting with review, triage support, anomaly flags, summarization of known document types. It struggles when every case is a unique political exception or when senior judgment is the product.

Before I recommend AI, I ask: Could a capable new hire be trained with examples and a checklist to handle most of this? If yes, automation or AI may help. If every instance requires a different senior call, I look at process design first — not a demo calendar.

3. Data that is usable enough to trust an output

I do not need perfect data. I do need honest data.

Before recommending a tool, I want to know:

  • Where the relevant information lives today
  • Who updates it and how often
  • Whether conflicting “sources of truth” already exist
  • Whether the business is comfortable with what the vendor will see
  • Whether someone can explain a wrong output when one appears

If the inputs are a mess of folders, duplicate CRM fields, and tribal knowledge, my recommendation is usually cleanup, integration, or simpler reporting — not intelligence layered on top of fiction. Confident nonsense destroys trust faster than no tool at all.

4. A named internal owner with calendar time

I will not recommend a tool that only has a budget sponsor and no operator.

Ownership means a person responsible for day-to-day use, access control, vendor relationship, escalation when outputs are wrong, and the decision to expand, pause, or retire. Committees do not own systems. People with time on their calendars do.

If no one has bandwidth, the organization is not ready — regardless of how impressive the ROI slide looks. Unused AI is still an operational decision. It just looks quieter on the invoice until renewal.

5. A success metric and a kill criteria written before purchase

“We’ll know it when we see it” is not a measurement plan. Before I recommend anything, I want two numbers or outcomes on paper:

  • What “good” looks like in 30–60 days (hours saved, error rate down, cycle time cut, quality of drafts accepted, tickets correctly routed)
  • What “stop” looks like (no usage, no measurable change, trust eroded, data risk unacceptable)

Without a kill criteria, every mediocre pilot becomes a zombie subscription. With one, the business can learn without pretending every experiment must succeed.

6. Fit between risk profile and use case

Not every AI use case belongs in every business. I look at privacy, customer impact, regulatory exposure, and how wrong an output can be before a human catches it.

Low-stakes internal drafts with review are different from customer-facing answers with no oversight. Recommendation without risk framing is incomplete advice. Responsible AI — privacy, security, transparency, and human oversight — is not a slogan at the end of a deck. It is part of whether I say yes.

7. Whether a simpler intervention would beat the model

This is the step many buyers skip because it feels less exciting.
Before recommending AI, I ask what would improve if we:

  • Documented ownership and definitions
  • Cleaned fields and retired duplicate sheets
  • Added rules-based automation for predictable steps
  • Trained the team on the tools they already own

If a checklist or a Zap solves eighty percent of the pain, I recommend that. AI is not a status symbol. It is a layer you add when simpler layers are insufficient.

How this filter shows up in a real conversation

A typical engagement does not start with a feature matrix. It starts with listening:

  • What breaks when volume rises?
  • What work repeats every week that nobody loves?
  • What data would a model see, and who trusts it?
  • Who will own this after the vendor onboarding call ends?
  • What will we measure — and what will we refuse to buy until we can?

Only after those answers exist do I map options: process fix, automation, AI with human review, or wait. Sometimes the best recommendation is delay. That recommendation protects trust.

What I refuse to recommend

I decline to recommend AI when:

  • The problem is political ownership, not pattern work
  • Data quality is fiction and nobody wants to admit it
  • There is no internal owner with time
  • Success is defined as “we launched something”
  • The use case requires unchecked customer impact the business cannot absorb

Saying no is part of the job. Strategy includes restraint.

A short checklist you can steal

Before you buy — or before you ask a consultant to recommend — run this:

  1. One-sentence problem both leadership and frontline accept
  2. Pattern or volume that justifies learning/support from a model
  3. Usable data and an explanation path for wrong outputs
  4. Named owner with real calendar capacity
  5. 30–60 day success metric plus kill criteria
  6. Risk framing that matches the use case
  7. Proof that simpler options were considered first

If you can check those boxes, AI recommendations become easier and safer. If you cannot, the tool was never the missing piece.

The point of a recommendation

My job is not to help a business look current. It is to help the business make work more reliable, measurable, and sustainable. Sometimes that means AI. Often it means clarity, process, and automation first.

When I do recommend an AI tool, it is because the organization is ready to use it — not because the market is loud this quarter.

Judgment before purchase. That is the whole filter.


About the author: Tzvi Boxer is a technology consultant and AI strategist based in Columbia. He helps organizations modernize systems, streamline operations, and decide where AI and automation actually add value — and where they don’t. Remotely, he works with Optimal Targeting on practical AI and high-authority content strategy. He is the author of The Practical AI Playbook. More at https://www.tzviboxer.com/.

Top comments (0)