Product reports from a CRM tend to share the same fate: revenue is visible, what it is made of is not. Your CRM will tell you last quarter's sales in one click. Which three items in the price list carry most of the margin, who buys them, and what they get bought with? That is an afternoon in a spreadsheet. This article is about asking Claude that question in plain words and getting the answer straight from data you already have.
The work nobody wants
A product report usually gets made like this. Someone in sales exports deals from the CRM into a spreadsheet. Line items are written differently from deal to deal: a full name once, a product code the next time, a typo after that. Half a day goes into making the rows add up at all. Then comes a pivot table, a chart and an email to management.
A month later it happens again, with a different question. The CEO wants to know why one product line is slipping. The head of sales asks which products get bought together, so the team knows what to offer. Finance wants a list of items that sold twice all year and still occupy the warehouse and the price list. Every question means a new export and another afternoon. So most of them never get asked.
We know how much we sold. We don't quite know what, or to whom.
— Management meeting, abridged
What connecting Claude to your CRM actually means
Claude is a language model made by Anthropic. It can read, calculate and explain, but on its own it cannot see your CRM. The bridge between the two is a small MCP server. MCP (Model Context Protocol) is an open standard that lets AI connect to tools and data. Think of it as a socket with a fixed shape: your CRM is in the wall, Claude is the plug.
The server does not hand Claude a copy of the whole database. When the sales director asks “which products are driving revenue in Brno this year”, the server signs in to the CRM as that director, pulls only the deals they are allowed to see, and Claude builds the answer from those. The data stays in your CRM. Only what the answer needs travels to Claude.
Concretely: Raynet CRM and invoicing in Pohoda
Take a company that tracks deals in Raynet CRM and issues invoices in Pohoda. Both systems stay exactly as they are. Next to them sits a bridge that can read deal line items and the invoiced reality behind them. For a company with a few hundred deals a year and a price list of a few hundred items, this is weeks of work, not months (an illustrative estimate).
- Normalises product names across deals, so “Service A” and “service package A” count as one item
- Ranks the range by revenue and margin into groups A, B and C, the classic ABC analysis
- Finds pairs and trios of products that are often bought together and suggests them as cross-selling tips
- Compares what sales marked as won with what was actually invoiced in Pohoda
- Flags items that have not sold at all in the last twelve months
Picture, for illustration, a small fasteners wholesaler in Olomouc. On Monday morning the owner asks: “Which construction firms buy screws from us but have never been offered wall plugs?” A few seconds later there is a list backed by numbers from the company's own CRM, with links to the deals Claude worked from. The example is made up, but this is exactly the kind of question that goes unasked today.
What product reports with Claude won't do, and why that's good
Claude will not decide to drop a product from your price list. It will tell you that a C item sold three times last year and that two of your biggest customers are among the buyers. Whether to keep it for the relationship or cut it is a business judgement. That stays with you.
Nor does it rewrite anything in the CRM. For reporting, the bridge is read-only. When Claude hits deals with no line items filled in, it does not guess what should have been there. It says how many such deals there are and marks the report as incomplete. The fact that it fills in nothing on its own is the reason you can trust its numbers.
What it would take
It starts with one question management asks today and waits a week to have answered. We build an MCP server for it that reads from your CRM, and from accounting if needed, and runs on your infrastructure under your own tenant. Every query leaves an audit record: who asked, what they asked and which data Claude answered from. No year-long project, no new data platform. Once a report proves itself, we put it in the skills library, and anyone on the team can run the same monthly overview the next morning, with their own permissions.
What's left
The model will run an ABC analysis and spot product combinations more willingly than anyone in sales wants to do it in a spreadsheet. It is not the bottleneck. The bottleneck is the gap between Claude and the data already sitting in your CRM. That gap is what we close.
If you have a question about your product range that nobody has time for today, write to us. On a short call we will look at where your sales data lives and what a first report would need.