Case Studies

Work we are allowed to describe.

Engagements in detail: the operation before, what existed already, what we built around it, and what changed in the way people work. Written plainly, and only about work we have done.

Discuss an Operational Problem Show Us Your Workflow

ERP integrationAI & LLM

Case study / Beverage manufacturing9 min read

From spreadsheet maintenance to operational intelligence

SAP held the data. Nobody could see raw materials, sales, or stock in transit. The gap was filled with Google Sheets, then with hours of maintenance. We built an AI knowledge layer and a transport visibility system around the ERP instead.

Client: Beverage manufacturer, name withheld
Region: Angola
Core system: SAP ERP
YOTT's role: Consulting + engineering

Read the case study

How these are written

If we did not measure it, it is not on the page.

Case studies are only useful when they can be trusted. These are the rules we hold ourselves to, including the parts that make a study shorter than it could be.

What we publish

Engagements we have actually delivered
The problem as the client described it
What was built, and what it was built around

What we avoid

Numbers that were never measured
Client names without written permission
Before-and-after claims we cannot back up

Engagements under NDA stay anonymous, and the details stop where the agreement does.

Your operation, described

The next case study could be your problem solved.

Bring one operational problem. We will tell you honestly whether software, automation, AI, or nothing at all is the right answer.

Discuss an Operational Problem Show Us Your Workflow