An AI adoption session with me looks like this: one to two hours in which the managers throw every pain point they have at me, then one to three processes, each with a measurable target. The last one ran 3.5 hours, at a bike brand with two branches and online sales, and we handled two processes.
The first was expense management: every receipt was logged by hand through a Monday form (monday.com, the work-management tool), photographed and uploaded manually to Drive — a few hours a week of the manager’s own time. At month end they compared the monthly statement on the credit-card issuer’s site — in Israel the card companies run their own cardholder portals — against the file in Monday, and roughly 15% of expenses turned out to be undocumented.
That is not a theoretical pain. In Israel an expense with no receipt behind it is not a “recognized expense” — it cannot be deducted — and for a limited company it also makes the tax filing messy. So the manual process was not just eating the manager’s hours: every receipt that falls through is an expense that will not be recognized at year end.
Why this happens in businesses that are growing
This business is successful and growing fast, and that is exactly the problem. The bigger it gets, the more complicated the day-to-day becomes and the deeper the managers get pulled into it. There is no moment to lift your head and redesign the processes for scale.
So you get processes built when the business was half this size, kept alive by a human moving information by hand. They fail quietly — 15% of expenses going missing is the kind of failure nobody notices until somebody counts.
How a session like this is structured
One to two hours of venting
We start with an hour or two in which the managers throw every pain point they have at me. No agenda, no order. Part of that is process mapping and part is just unloading — which has value on its own. In a growing business there are not many chances to say out loud what is broken without someone demanding a solution on the spot.
What I am listening for is places where information sits in one system and is needed in another, with a person acting as the transfer pipe. That is almost always where the wasted time lives.
Pick one to three processes
Then we define one to three processes to improve — no more than that. Each gets a measurable target, and I check that the target produces real ROI. Broadly, a good target falls into one of four categories:
- Employee working hours
- Manager working hours
- Reduced costs
- Increased revenue
If the target does not land in one of those four, it is not a target. “Work smarter” is not something you can look at on the last day of the month.
Capping it at a small number is not modesty. In my experience, a session that touches eight things leaves eight half-built things, and they do not survive the first busy week.
Put Claude in the middle
Then the work starts. In the overwhelming majority of these processes I am not inventing anything clever: I break down the data silos and put Claude in the middle using connectors. Some are official and already exist, and some I build on the spot, during the session.
That is why I work in Claude Code and not only in a chat window. When a connection is missing, you can build it that day instead of adding it to a wish list.
Worth saying what this is not: I am not replacing their systems. Monday stays Monday, Drive stays Drive. The goal is to break the barrier between systems, not to start a migration project in a business with no spare time.
Make sure they can continue without me
Once Claude sits in the middle and the connections work, they can keep going without me — scheduled tasks for anything on a fixed rhythm, Cowork for everything else. That is the real test: if they need me for the next change, I did not do the job.
The receipts: the concrete case
The first process is the one I opened with. It is worth taking apart, because it looks like a lot of other processes I run into.
The old flow was: someone photographs the receipt, uploads it to Drive by hand, then fills in a Monday form to log it. Three human touches per receipt. In a business with two branches and online sales, that adds up to a few hours a week — the manager’s own hours, not a junior employee’s.
Worth pausing there. Logging receipts is the kind of task you would expect to be delegated, and it was not. When work sticks to the most expensive person in the business, the process is usually not defined anywhere — it is held in someone’s head.
Then the control step. At month end they compare the card statement against the file in Monday and look for holes. The gap was around 15%. So the process was not only expensive, it also did not work — and reconciliation is a detection mechanism, not a correction one. It tells you, a month late, what you already lost.
Notice what that gap does to the numbers. If 15% of expenses never get logged, the file in Monday is not the business’s expense picture — it is 85% of it, and anyone reading it is reading a partial one.
The solution itself was relatively simple to build. That is almost always the case, and it is the point: most of the time in a session like this goes into understanding and defining, not building. The hard part is agreeing what the process should do and how you will know it worked.
What I do not have is the after number. The next month-end comparison — same statement, same file — is the one that says whether the gap closed. Until then this is a before number and nothing more.
The second process
The second process we handled was customer service. It is involved enough to deserve its own post, so I will write it up separately.
What actually happened there
Technically I built nothing impressive there. No algorithm, no model, nothing anyone would write a paper about.
What happened is that a business owner watched Claude Code and Cowork do things rather than answer questions, for the first time. That is probably worth more than any process we built that day — once someone has seen it, they start spotting the next ones on their own.
All the credit for the hard part goes to the people in SF driving this. I enjoy bringing up the rear for them here in Israel.
What I took away from it
What came out of that day is a business slightly more ready to grow than it was that morning — not because I added an impressive capability, but because two central processes now have a definition and a target instead of leaning on someone’s memory.
The most important thing in a session like this is not the tooling. It is refusing to touch more than three processes, and insisting each one has a number you can look at when the month closes. A fast-growing business does not suffer from a shortage of improvement ideas — it suffers from a surplus.
The tools will keep changing every few months. What does not change is the question of where a person is still acting as the pipe between two systems, and what that costs in hours and in money. If this sounds like something your business needs, this is what the process looks like on my end.