Zendata
Implementation

Where to start with AI in the company (without epic projects)

4 min read
Watch the video

Start from the problem, not from the technology. A useful first AI project comes from a repetitive process where people today waste time searching, copying, or reconstructing information—not from the appeal of a new model.

Which problems make good starting points

Typical examples we often see:

  • internal requests bouncing between offices;
  • customer care searching for information in too many places;
  • back office spending hours on recurring reports;
  • documentation that cannot be found exactly when it is needed.

The practical criterion is simple: frequency and shared pain.

  • If three people feel the problem once a month, it is usually not the right starting point.
  • If thirty people feel it every week, there is value to demonstrate there.

Why epic projects often fail

Starting from “let’s transform the company with AI” or “let’s put some AI in because it looks cool” produces long projects that are hard to feel and hard to adopt. After months, people’s daily work has not changed.

A good first project is small but changes a habit. Something people can touch and recognize as useful. Credibility is born there. Then you expand.

Data on AI adoption in Italian enterprises, such as Istat 2025, and OECD analyses on SMEs remind us that skills, processes, and organization weigh as much as technology. The European context of EDIHs also confirms that digital transformation accelerates when there is structured support and concrete use cases, not only announcements.

A simple framework: frequency, pain, visibility, feasibility, measurability

Before choosing, score the use case on five axes:

  1. Frequency: how often it happens;
  2. Pain: how much time, error, or frustration it creates;
  3. Visibility: how clear the improvement is to people;
  4. Feasibility: available data, risk, integrations, and ownership;
  5. Measurability: clear before/after metrics.

A “nice” idea without data, with high risk, or without an owner is not a good first project.

Examples of first use cases and how to measure them

Typical use cases, if the perimeter is solid:

  • classifying emails and tickets;
  • generating recurring reports;
  • intelligent search over internal documents;
  • summarizing meeting notes and procedures;
  • supporting preliminary screening of requests.

For each one, define simple metrics: average time, error rate, number of handoffs, percentage of citable answers, internal satisfaction.

On a well-scoped pilot, a 30–60 day horizon can be realistic for an observable, communicable result. It is not a universal guarantee or an automatic synonym for ROI: it is a project approach to learn quickly and build trust.

Why quick wins matter (beyond time savings)

Early results are not only about “making the numbers work.” They serve to:

  • show people that the tool works;
  • give management concrete evidence;
  • legitimize next steps with more discipline and less hype.

That flywheel starts adoption. Without it, you often keep an epic project that never changes habits.

FAQ

How much does a first project cost?
It depends on the perimeter. You can start with a contained investment if the use case is narrow and the data is accessible.

Do you need an in-house data scientist?
Not necessarily for the first projects. You need clarity on the problem, process ownership, and a partner able to take the solution into production.

What if the first project fails?
Learn quickly and restart. A small, fast failure costs less than an epic program that never reaches people.

Does speed automatically mean ROI?
No. Speed helps you learn and reduce risk. Economic return must be measured on the use case, not assumed.

Sources

Explore the series

If you want to choose the first use case with a method, we can run a prioritization session with a scorecard on frequency, pain, visibility, feasibility, and measurability. Write to us at info@zendata.it or visit zendata.it.

Pietro Ciattaglia, CEO of Zendata AI, Rome