Before You Hire an AI Engineer, Find the Work That’s Getting Stuck.

Your next AI project might begin with a sales inquiry nobody answered.

Or a quotation that took two days to prepare.

Or an expert spending the morning searching for information instead of using it.

None of these situations tells you which model to buy.

They tell you where to investigate.

That is the difference between starting an AI project and finding a business reason to build one.

If you are considering AI for your organization, here is the question I would ask before discussing tools, agents, or hiring:

What useful work is getting delayed, repeated, or left undone—and what would change if we improved it?

A real e-commerce experiment shows why that question matters.

One Company. Seven AI Experiments. Different Results.

A working paper published in October 2025 examined seven randomized experiments at a large international e-commerce platform.

The researchers tested AI interventions inside actual business workflows.

Selected results included:

These were separate comparisons against different baselines. The gains cannot be added together, and they do not represent a company-wide revenue increase.

But the variation is the useful part.

Putting AI into a workflow did not automatically make that workflow more valuable.

The baseline mattered.

The Detail Behind the Biggest Number

The customer-service experiment involved 44,614 customers.

One group had access to a generative AI agent before purchasing.

The control group received a scripted message indicating that customer service was unavailable.

Sales increased by 16.3% in the AI-assisted group relative to that control.

This does not mean AI outperformed an excellent human support team by 16.3%.

It means providing assistance outperformed an experience where effective assistance was unavailable.

The business opportunity was not simply “replace support with AI.”

It was:

Stop leaving a customer without an answer.

Your organization may have a different gap.

The point is to find it before building around it.

Three Places I Would Look First

The following are investigation starting points—not claims that every business needs a custom AI system.

1. Where Customers Are Waiting

Examples might include:

• Product questions that require manual research.
• Quotation requests waiting for information.
• Inquiries arriving outside service hours.
• Customers unable to find the right product.
• Repeated requests for information already held by the business.

A potential first intervention could be a source-grounded assistant or a quotation-preparation tool.

But the objective is not “respond to more messages.”

It is to help the customer take the next useful step accurately.

2. Where Experts Are Assembling Information

Consider a specialist who must:

• Locate several documents.
• Extract recurring fields.
• Compare versions.
• Reconstruct a case history.
• Draft a standard response.
• Check which policy applies.

A useful system might prepare the material for review.

That is different from making the final professional decision.

The test I would use:

Can the expert verify the output faster than completing the original task?

If checking the system requires repeating all the work, the system has not yet earned its place.

3. Where Growth Has Created a Queue

More sales can mean more requests, exceptions, handoffs, and internal questions.

A growing queue is worth investigating.

It is not automatically an AI opportunity.

The cause might be:

• Missing information.
• Unclear responsibility.
• A disconnected software system.
• A rule that could be automated conventionally.
• A genuinely difficult interpretation task.

Different causes require different interventions.

The right recommendation may be AI.

It may also be a better form or a straightforward integration.

What a Useful First AI Project Looks Like

Let’s make this concrete.

Imagine a distributor whose sales team prepares quotations manually.

Product specifications are in one file. Prices are in another. Availability requires confirmation.

A customer sends an inquiry.

The team spends time assembling an answer.

This is a hypothetical example, not a reported client engagement.

A bounded first version could look like this:

Customer inquiry
      ↓
Extract requested items, quantities, and units
      ↓
Identify missing or ambiguous details
      ↓
Retrieve approved product information
      ↓
Calculate using explicit business rules
      ↓
Prepare a draft quotation
      ↓
Salesperson reviews and approves

Notice what the system does not need to do:

• Set prices independently.
• Invent delivery dates.
• Approve discounts.
• Send binding offers.
• Access every database.
• Operate as an autonomous sales department.

The initial question is much smaller:

Can this approach help a salesperson prepare a correct, reviewable quotation with less effort?

That is a question we can test.

Measure the Work, Not the Demo

A quotation generator can produce a draft in seconds and still waste time.

Perhaps the wrong product was selected.

Perhaps the unit is inconsistent.

Perhaps the salesperson must verify every sentence against the original files.

For this hypothetical pilot, I would evaluate:

The phrase “total time” matters.

Count preparation, waiting, checking, and correction—not just generation.

And establish the acceptance criteria before looking at the final results.

You May Not Need to Fix All Your Data First

For the quotation example, I would begin by identifying the specific information the task requires:

• Product identifiers.
• Approved specifications.
• Prices and their effective dates.
• Units.
• Relevant sales conditions.
• The source and status of availability information.

That is not the same as launching a company-wide data transformation.

It is also not permission to ignore poor data.

The practical question is:

Is the information required for this bounded task sufficiently reliable, accessible, and authorized for the proposed use?

If not, that becomes part of the initial work.

A model should not be asked to compensate for missing commercial facts by guessing.

When I Would Recommend Waiting

Not every inquiry should become a development project.

I would pause a custom build when:

• The intended outcome is still unclear.
• The required information is unavailable or unauthorized.
• Nobody can evaluate the output.
• Review costs remove the expected benefit.
• The workload is too small to justify maintenance.
• A simpler solution can achieve the same outcome.
• The proposed autonomy exceeds what the organization can safely oversee.

“Do not build this yet” can be a valuable recommendation.

It prevents a successful demonstration from becoming an expensive operational obligation.

What an Initial Review Should Clarify

Before committing to implementation, I would want a clear answer to five questions:

1. What outcome matters?
2. Which workflow or capability should we investigate first?
3. What information and permissions does it require?
4. What is the smallest useful intervention?
5. What evidence would justify continuing?

The result should be a decision—not just a technology shopping list.

That decision might be:

• Improve the process first.
• Prepare a specific dataset.
• Use an existing tool.
• Develop a focused proof of concept.
• Run a limited pilot.
• Stop or revisit the opportunity later.

The value is knowing which path fits your organization.

Start With One Opportunity Worth Testing

You do not need to arrive with an architecture diagram.

You do not need to know whether you need an agent, a retrieval system, or a predictive model.

You need a business objective and enough context to investigate it.

That objective might be:

“We want customers to receive useful answers sooner.”

“We want specialists to spend less time assembling documents.”

“We want to test a new service without committing to a large platform build.”

The technology should follow the problem.

Not the other way around.

Considering AI for Your Organization?

I offer consultation on identifying suitable AI use cases, assessing data and workflow requirements, and designing focused implementation experiments.

If you have a specific opportunity—or need help selecting a practical starting point—share your organization's context through the inquiry form.

Discuss Your AI Implementation Opportunity

You will be asked about your objective, current process, available information, and important constraints.

No technical specification is required. Please do not submit confidential documents or access credentials.

The goal is to establish what is worth investigating before deciding what to build.

Explore my work and projects:

https://almodarresieh.github.io/

Submitting an inquiry does not book a meeting, confirm project acceptance, or guarantee an outcome.

Source and Scope

Fang, L., Yuan, Z., Zhang, K., Donati, D., and Sarvary, M. (2025). Generative AI and Firm Productivity: Field Experiments in Online Retail. Working paper, version 1, October 14, 2025.

https://arxiv.org/abs/2510.12049v1

The reported e-commerce results come from this working paper. Its experiments took place between September 2023 and June 2024 at one undisclosed platform.

Sales increases are not equivalent to net-profit gains or guaranteed returns elsewhere.

The distributor example, proposed architecture, evaluation criteria, and consulting approach are illustrative recommendations—not claims of completed client projects.