How to optimize a company's workflows with AI: a real case study.

Introduction

In September 2026 I joined Attiva Servizi, a cleaning company in the Venice area: private homes, apartment buildings, deep cleaning, clearances, pest control. I work on experience design and artificial intelligence, and the company's privacy counsel officially appointed me AI Officer.

The biggest piece of work of these months is the web management system I'm building with Claude Code and a team of AI agents. It runs the warehouse, plans the operators' work, and handles quotes, leave, clock-ins and recurring jobs. It replaces a set of linked Excel files.

Here is how I set it up, with the numbers and the choices that worked. If you run a service company, or design tools for people who work in the field, most of these choices apply to you too.

The starting point: linked Excel files

Attiva Servizi wasn't starting from scratch. It had a serious system of Excel files: one for the warehouse, one for each year's consumption, one for planning, one for the schedule of recurring jobs, tied together by formulas and dashboards. It worked, and that made it hard to change.

The limits were clear to the people using it every day:

• Nothing got updated from the job site. To record the materials used, you had to be in the office, in front of the file.
• One person at a time can edit a shared file. The office and the warehouse couldn't work on the same data together.
• Moving work from one file to the next was manual. An accepted quote, the weekly plan and the deadlines lived in different places.
• No record of who changed what. A deleted row disappeared without a trace.

The goal was to keep everything the company had already learned to do with those files, and remove these four problems.

Before the code, the map

The first document of the project has no code in it: it's a table with every sheet of every Excel file, what it's for, which columns it has, which calculations it runs, which colours it uses to warn you, and its status in the new system (done, partial, missing). To write it, the agents read only sheet names and column headers, never a single row of data.

That map paid off three times. It set the scope of the first phase (warehouse and consumption only), it showed what was missing at any moment, and it kept me from redesigning what already worked. The new planning, for example, uses the same idea as the Excel file, which the office knew and trusted: you don't copy the plan every week, you only write down the exceptions.

Designing for the unexpected

In a cleaning company the rule is simple: who goes where, when, for how many hours. The real work is in the exceptions. Someone calls in sick at six in the morning, a client moves a visit, a van is at the mechanic's.

Planning starts from a formula the office can read out loud:

day = standard week + fixed-date visits + one-off jobs - absences ± changes of the day

The interface choices came from there:

• An unexpected event takes two clicks. "Sick from today to Friday": all of that person's shifts in those days become uncovered and land in the "To fix" panel, with a red number in the menu.
• "Find someone". On every uncovered shift the system suggests the people free in that slot, in order: who already knows the site, who is nearby, who still has hours left on their contract, who has the required training. Next to each name is the reason ("knows the site, +6 h free"), and one click covers the shift.
• "Just this once" or "From now on". When you drag a shift onto another person, the system asks a single question. The first answer is a change for that day; the second updates the standard week from that date, without rewriting anything.

Leave works the same way: operators request it from their phone, the office approves or declines with a reason, and while the request is pending the shifts of those days already show as uncovered. Nobody finds the gap on the day itself.

Never block the work

The ideal path of a job is linear: quote, confirmed order, planning, work done, invoice. In real life an emergency gets done before the order exists, and sometimes you record an invoice for work done before the system existed.

A system that forces people to follow the steps in order pushes them to keep data outside it, on scraps of paper. So I chose the opposite rule: any step can be skipped. The system never blocks the next step; it marks what's missing and puts it on the "To fix" list: jobs done without an order, confirmed orders not yet planned, work done and not invoiced. On every job a row shows the completed steps in green and the skipped ones in orange.

The office works at the speed of the day, and at the end of the week it knows what still needs sorting out.

Field work, from the phone

The system is an installable web app: the office opens it on the computer, operators use it on their phones. Three features changed the way people work more than the others:

• Material logs from the phone, even offline. Many job sites are basements or plant rooms with no signal. The log waits in a queue and goes out as soon as the signal is back, without duplicates. The job site is required: that's what tells you how much material each site consumes and whether the contract covers it.
• Clock-ins that serve as proof for the client. Start and end of the work with the job site and the position, read only at the moment of clocking in and checked against the site's radius. There is no tracking during the day.
• Site inspections by voice. A small separate app: whoever does the inspection dictates the description of the job, takes the photos, and the system prepares a draft quote with services suggested from the catalogue.

For clock-ins I did the legal work before the technical work. Only the administrator can flip the switch that turns them on, and only after the written notice to the operators, the data protection impact assessment and the opinion of the labour consultant. While it's off, the app hides the feature and the database rejects clock-ins.

A team of AI agents, with written rules

I built the system with Claude Code and a team of agents, each with a role: infrastructure and security architect, data and Excel migration analyst, database developer, interface developer, security and quality reviewer. I decide, design and review.

The rules that held up over five weeks:

• A handover document. Whenever someone starts or finishes a piece of work, they write what they're doing, on which branch, the outcome and what's left. A new agent reads that file and knows where to pick up.
• One branch per feature, green tests before merging. The security reviewer checks every block before it goes into the main version.
• Precise instructions, no open choices. At the start an agent used up to 800,000 tokens on a task, because it read a lot and tried everything. With fixed-format instructions (the goal in one sentence, the files to touch already listed, the steps already decided) we went down to 140,000-250,000.
• Small jobs without agents. A colour, a label, a filter: I change those myself in the conversation. An agent is worth it when a task touches the database, the app and the tests together.

The most useful lesson is about my own role. Code gets written fast now. What slows things down are the decisions nobody has made: who sees prices, what happens if an operator leaves a clock-in open, which step can be skipped. Every decision is written in the project documents, with its date and its reason.

Privacy first

A management system holds a company's most sensitive data: clients, contracts, prices, people. And everything an AI reads leaves the computer. Hence the rules that Claude and the agents follow without exceptions:

• Development happens only on made-up data. A local database, fake clients and fake job sites. Real data never goes through the AI.
• Only one person uses the keys. The AI prepares the commands that touch the real database and I run them; the output shows only counts, never names or values.
• Only code goes into the repository. An automatic check rejects Excel files, photos, keys, bank details and tax codes before every commit.
• Only the data you need. No bank data, servers in Europe, two-factor authentication for anyone who sees sensitive data, and on every table the rule "everything forbidden, except what is allowed".

These are the same rules that, as AI Officer, I ask the whole company to follow when it uses AI.

AI where it pays off, rules where they're enough

Optimizing with AI doesn't mean putting a model everywhere. For site inspections, the first idea was to have AI suggest the quote lines from the dictated description. It worked, but it cost a few cents per inspection and sent the text outside the company.

We went another way: the iPhone's dictation for the voice and, in the quote, a button that matches the text against the names and keywords of the services in the catalogue, plus a list of synonyms ("windows", "glazing" and "panes" lead to the same service). It also picks up spoken frequencies, like "twice a week". It costs nothing and the text stays inside the company. The Claude API remains an option for when it's really needed.

AI built the tool. Inside the tool, simple rules that the office understands and can adjust on its own are often enough.

The numbers, after five weeks

The first commit is from 11 October; the next day the real data had been imported from Excel, and since mid-October the office has been using the new system. New features come from my requests and the office's, almost every day, and each request has its date in the project documents.

How to apply it to your company

If you want to streamline your company's workflows with AI, these are the steps I would take again:

1. Map what exists. Files, sheets, columns, calculations, who uses them and when. The system you already have holds years of decisions.
2. Pick a small scope. We started with the warehouse and consumption. Everything else came once that part worked.
3. Design the exceptions. Ask the office what happens when things go wrong, and start there.
4. Don't block the work. Let people skip steps and keep track of what's missing.
5. Write the rules for the AI before you start. What it can read, what it must never touch, who approves what.
6. Use AI to build, and simple rules where they're enough. Every model in production costs money and sends data out: it has to be worth it.

FAQ

Do you need a developer to build a management system with AI?

In my case, no: I design and coordinate, and Claude Code and the agents write the code. You do need product and security skills to decide what to build, check what comes back and protect the data.

How long does it take?

The first version of the system, with the warehouse and the real data imported from Excel, was ready in two days. In five weeks it reached 824 commits and covers almost all of the office's work.

Does client data end up with the AI?

No. Development runs on made-up data, and a person runs the commands on the real database, with an output that shows only counts.

What should you digitize first?

The part that causes the most retyping and the most errors. For Attiva Servizi it was the materials used on job sites: recorded in the office after the fact, with the job site not always filled in.

Conclusion

The system grew out of an Excel system that worked and an office that already knew what it wanted. AI made it possible to build it in a few weeks with a single person leading. The design work was everything else: understanding the unexpected, deciding what not to block, putting privacy before convenience.

If you're thinking of doing the same in your company, or want to understand whether it makes sense in your case, write to me.