One Year, Seven Clients, One Diagnostic Method

The short version

Over the last year my colleague and I ran business diagnostics on small firms in Macedonia, in a donor co-financed programme, with a method built from one day of training and every framework we knew. We ran it on seven firms, and after every single one the method changed. Each founder broke it in a different place and left us a rule. From day one we wanted AI to support the diagnostic, and with every client the AI's share of the work grew, from one chat window to an AI that collects the data itself. In edition 18 I wrote about the AI roadmap I use with small firms. This is what happened when we put AI into our own diagnostic work.

In October 2026 I told this story on stage, at the 13th International CMC Conference of ICMCI in Bucharest, in a fifteen-minute case study slot, with my own hand-drawn slides. Fifteen minutes is short, so I wanted to share the insights from that talk here, in full, with the slides as the pictures.

This edition is that year, in the order we worked with the clients: what the founder trusted us with and asked, where our method broke, the moment I changed my mind, and the rule he left us.

A year ago

A year ago my colleague and I, two consultants from one small firm, were enrolled in a donor co-financed programme to run business diagnostics on small firms in Macedonia. In that programme a diagnostic means one firm, every department, and a report the founder can act on. Without the programme there would be no method to write about: it brought us to the firms, and it co-financed the work.

We had one day of training on how to use the existing frameworks, and it was a great training, an excellent experience for the two of us. It gave us the twelve departments a diagnostic has to look at, and everything we built afterwards still stands on those twelve. Putting AI into the diagnostic was our own idea, and we built it on top of what the training gave us. Based on what we learned that day we built our first framework and presented it at Global Entrepreneurship Week. The donor was happy with it. The framework was ours, and it was purely academic, in the method and in the wording. Our template ran on hypothesis, primary research and secondary research, where a hypothesis is a statement the research is there to test. The hypothesis was in that template from the start, and it took us five clients to learn how to let the data decide one. Then we met the first founder.

Client one, a mobile app studio

The first client was a mobile app studio of around twenty people, and its founder was the first to open his company to us. The founder's question was whether a fixed three-week MVP is the right next step, and what the company needs before it can sell one. One number from the record: around 70% of his sales came from three clients.

Our academic approach showed most here. Our report ran every framework we knew, PEST, Porter, KPIs, on the company, with no connection, no flow and no relevance between them. We also researched departments that did not apply to him, risk and governance for a twenty-person studio, because we had set out to cover every department.

He read the report and said: "I know all of this already." He was right, and with that one sentence he started rewriting our method.

The first rule started with how his studio worked. It sold development work to other companies, most of it to agencies that resold the work to their own clients, and every client arrived through a partner or a referral. So the studio was barely doing any marketing or sales of its own, and when we asked for the marketing and sales data, split by type of client, there was none. That gap told us something about the company on its own: nobody in the studio had the job of finding the next client. That is how we learned the first rule: when the company has no segment-level data, the missing data is a finding on its own, and it goes into the report.

The second rule came from his sentence. He had come to us with one question, the three-week MVP, and our report gave him back every framework we knew, run on things he already knew about his own company. A report that repeats what the founder already knows is not valuable to him, however correct it is. So the second rule: a founder pays for the problem he named, not for a tour of every department.

The AI at that point was ChatGPT and Claude, one chat for one task, used for market research and for reading documents.

Client two, an LED and electrical distributor

The second founder ran an LED and electrical distributor with fewer than twenty people, a bit less than €2 million a year and more than a thousand clients. He trusted us with three worries: stock that does not sell, staff costs, and seven price levels. His question was how much money is sitting in stock that does not sell, and what keeps adding to it.

This time we changed the method first. We asked the founder for his top three problems or opportunities, so the research had a direction. We still covered all twelve departments, but we read them through his three problems. That made it a hybrid: half the department-led diagnostic we started with, where every department gets the same attention, and half a problem-led one, where the founder's problems decide where we look.

Reading the departments through his problems is how we saw the dead inventory for what it was. Dead inventory is stock the company bought that has not sold for a year or more, money sitting on the shelves. He had guessed it at anywhere from a fifth to a half of his stock, and when we counted, it was a bit more than a fifth, the low end of his guess. And it was not one department's problem. It was part procurement, part sales, part marketing and part management, and no single department could see all of it from where it sat.

Then he opened his records to us, 84 files: ERP exports, Excel sheets, financial data with thousands of rows. The first client had given us seven. No single chat could hold 84, so we built a register. A register is one sheet with one row for every document the client gives us. The row says what the file is, what it relates to, for example finance, payments, sales or stock, and which findings we took from it. A finding is one thing a document shows about the founder's problems, written down so we can use it in the report. In his company, one finding was that over 20% of the stock had not sold in a year or longer.

The register is also what let the AI get through 84 files. We went through the documents one by one, across many chats, and in each document we looked for findings related to his three problems. Every finding went into the register next to the document it came from, so each new chat could start from the same list.

Then the register gave us something no single document could. A derived finding is two or more findings from different documents or different departments that, put together, give a new finding. In his company, one finding came from purchasing: orders followed what the supplier had available, with no signal from sales. Another came from sales: nobody was telling purchasing what clients were asking for. Put together, they gave a third one that neither department could see on its own: the same way of buying filled the shelves with stock that did not sell, and left four in ten products with buyers and nothing in stock.

His company left us two rules, and both came out of those shelves and those 84 files. The dead inventory sat across four departments, and none of them saw it whole, so problems sit between departments, not in them, and the derived finding is how we catch them. And the register: once every document has its row and every finding sits next to the document it came from, it no longer matters if you have 7 or 700 documents.

Client three, a business information platform

The third founder ran a business information platform with fewer than twenty people. He had a strong finance and data background, and he wanted every claim backed by a source. A cheaper competitor had come into his market and his growth had slowed since, so his question was whether the competitor is the reason.

We had the register, and we had not carried it into the report. Every finding in the register sat next to its document, but once a finding became a sentence in the report, the link to the document was gone. I said it plainly at the time: "Now I have a document that I can't verify, or defend in front of the client."

We processed the documents again from the start, and this time every claim that went from the register into the report carried its document and its paragraph with it. Here is an example: say we write that revenue grew by a fifth. In the report that sentence now points to the invoice file and the paragraph the number came from, so when the founder asks how we know, we open the invoice file and show him. That is the rule his background taught us: every claim, every finding that goes from the register into the report, points to its document and its paragraph.

The AI moved in the same engagement, from chats to one project per client. A project is a workspace inside the AI tool that keeps the master prompt, the standing instructions for that client, and the saved files, with many chats running inside it. So every chat about his company started from the same instructions and the same documents, and that became the second rule of his engagement: one client, one project.

Client four, a B2B SEO agency

The fourth founder ran a B2B SEO agency selling to software companies abroad, with around a dozen salaried people, as many contractors and close to €400,000 a year, and he was open with us about four problems. Two of them drove the work. Every client had come by referral, even after he built a sales process and hired a sales team so the agency could grow beyond referrals. And he had never seen the profit per client. His question was why the sales system is not bringing clients.

Here we went fully problem-led. We stopped reading all twelve departments through three lenses and let his problems decide how deep we go in each one. If the problem is marketing, we go deep on the marketing data and stay shallow on the rest. In his company sales went deep because every client still came by referral, and finance went deep because he had never seen the profit per client. The departments far from those two problems got a standard or a light look, so we spent the energy where the problems sat. That is the first rule he taught us: his problems, not our list of departments, decide how deep we go.

His Excel files had more than twenty tabs, with several tables inside each tab, and our AI made too many mistakes on them. That was a limit of our AI, so we started making files AI-readable. An AI-readable file holds the same data as the original, rebuilt into simple tables the AI can read without mistakes. We wrote a prompt that does the rebuilding and a check that it was done right, and before a file goes into the register, we rebuild it first.

During the same engagement an automation tool wrote findings into another client's register, and nobody had asked it to. I said it to the AI three times in eight days: "you should never update the registry until I approve the findings." So the second rule from his engagement is about what goes into the register: every file is made AI-readable before it goes in, and nothing goes in before a person approves it.

Client five, a PVC and aluminium joinery maker

The fifth founder trusted us with a plan he had already committed to: he was buying his own production hall, and he wanted to fill it with bigger work. His company makes PVC and aluminium windows and doors, with around ten people and a bit less than €500,000 a year. His question was how to build a route to €15,000 projects, and what inside the company has to change for that to hold.

He also put his plan for a new glass-cutting machine on the table, because glass felt like the step holding the workshop back, and he let us test it on his own cost sheets. This is where we introduced hypotheses the data can approve or deny. We wrote his plan as a hypothesis, a statement about the machine that his own records could prove or disprove, and we tested it on more than five hundred orders. He put his machine use at about a third. Measured, it was "a quarter, at most". Over 75% of his machine capacity was unused, so a new machine would have stood idle too, and the data rejected the hypothesis.

He let his own cost sheets have the last word on his own plan, and that is the rule he left us: the data approves or denies the hypothesis, not the founder and not us.

On the AI side we moved to Claude Code, the version of Claude that works on the files in a folder instead of inside a chat window. No more documents pasted into a chat. The AI works in the client's folder, with its rules and its lessons written down. And for the first time the report is built in code from the register and checked by a script before it leaves: 16 checks at the start, 89 today. Once the report was built in code, we could check it in code, and that is the second rule of his engagement: a script checks every report before it leaves.

Client six, a food business on delivery platforms

Three partners trusted us with the sixth diagnostic. Their bistro sells at the counter, through two delivery apps and through catering, with ten to fifteen people and around €400,000 a year. The partner who keeps the numbers was open with us: he called his own Excel broken. His question was what the business earns each month, and whether the prices are built on what the food really costs.

They gave us 580 files, and this time the first failure was ours: same files, different numbers. Each time we processed the files again, some numbers came out different, and we kept adding new versions of the register to fix them. We stopped at seventy-four versions of the register and started again from zero. In my words at the time: "We've realized that some of the underlying facts are no longer facts, so rather than keep adding versions, we've decided to start from scratch."

On the restart the method got its chain. It starts at the founder's claim, what he tells us about his own business, and picks the research area the claim belongs to, which is where we look. The claim becomes a hypothesis, what might be true. The hypothesis becomes a research question, what we need to know to test it. The question shows the data gaps, the data that is missing, and documents and outside research close them. The report then confirms or denies what the founder told us. Each step has its own template and checks behind it, more than one article can carry, but the order of the steps is the method. That chain is the rule their engagement left in our method: every report starts from what the founder claims, and confirms or denies it.

The AI got two new jobs here. On the restart it wrote nine hypotheses for one area, and eight of them were proof of the first one. So now the AI proposes and the consultant shortlists: the AI writes the candidate hypotheses, and the consultant picks the ones worth testing. And we taught Claude Code to collect the data itself: rather than asking the partners to send exports, it opens the delivery apps and the till software and pulls the reports we need.

Their 580 files also left us the rule that came out of our own failure, the one the seventy-four versions taught us: same files, same numbers, however many times we process them.

Our own firm

Then we ran the diagnostic on ourselves, and it found in us what it found in them: 145 findings. We also found numbers that were not correct, and we noticed them only because we know our own business well.

So we added control gates at every stage. A control gate is a check in code that the work has to pass before it moves on: code checks the data, checks the narrative, checks everything, and catches the AI's mistakes before they reach a report. That is the rule our own wrong numbers left us, and the gates now catch what we used to catch by eye.

We also changed our own reporting. Our KPIs sat in one complicated Excel, the same kind of file the fourth client's workbooks had taught us to rebuild, so we moved them into simple sheets the AI can read, and the AI watches them every week.

Client one to client seven

Put side by side, the first client and the last one look like two different methods.

Method. Client one got the frameworks we had learned, PEST, Porter and KPIs run on every department, with no connection between them. Client two got a hybrid, the twelve departments read through the founder's top three problems, and with client four we went fully problem-led, so his problems set how deep we go in each department. Client five brought the hypothesis that the data approves or denies, and client six gave us the chain that holds it all, from the founder's claim through the hypothesis and the research question to a report that confirms or denies what he told us. Client seven, our own firm, gets that one chain.

AI. Client one had ChatGPT and Claude, one chat for one task. With client two's 84 files the AI worked across many chats from one register, and with client three it moved into one project per client, with a master prompt and the saved files. Client four's workbooks had to be made AI-readable before our AI could read them without mistakes, and at client five Claude Code worked in the client's folder and built the report from the register. At client six the AI started collecting the data itself and writing the candidate hypotheses for us to shortlist, and by client seven it reads, counts, collects the data and drafts, and watches our KPIs every week.

Artefacts. Client one got a deck built on those frameworks. Client seven gets a kit of five pieces that moves from client to client. The data room is the shared folder that holds every document the client gives us, and the register keeps one row for every document, with the findings taken from it. The AI-readable files are the client's workbooks rebuilt into simple tables, the templates sit behind each step of the chain, and the scripts build the report from the register and check it before it leaves.

Verification. Client one's report was read by the programme's reviewer after delivery. From client three on, every claim in the report points to its document and its paragraph, and from client four nothing enters the register before a person approves it. At client five a script started checking every report before it leaves, with 16 checks at the start, and after the seventy-four versions at client six the same files have to give the same numbers. On our own firm the control gates added a check at every stage, and client seven's report passes 89 checks before it can leave.

And what did the six small Macedonian firms have in common? Each one grew around its founder, who still carries most of the decisions, and many of those decisions are made on experience rather than on data. In all six the record was missing or unread, and in all six the cause sat in a different place from where the problem showed. Six founders let us look at all of this inside their own companies, and every rule in this edition came out of that.

The consultant on top of AI

AI can help a lot, but the consultant is the smart person. AI does the analytics and drafts the reports. The consultant is the one who converts the owner's claims into hypotheses and research questions. If we miss the questions, we miss what data we are looking for, and we miss the report.

Look at what the AI took over from client to client: a chat, a register, a project, AI-readable files, Claude Code in the client's folder, the data collection and the weekly watch over our KPIs. Not one of those steps wrote a question for us. The competitor, the glass-cutting machine and the monthly earnings became research only because a consultant turned what the founder told us into a hypothesis the data could confirm or deny.

A stable framework is a never-ending process.

The version we run today was written by this year's seven clients, none of whom set out to.

I am grateful to every one of them. They trusted us with their companies and gave us the chance to learn from them, and the programme is what brought us to them.

So my question to you, as one consultant to another: what did your last client break in your method, and which rule did you keep?

If this was useful, subscribe to Anatomy of Consulting on LinkedIn, and the next edition comes to you.