A CRM cross-sell report has one job: tell you which existing customers to offer the things they don't buy from you yet. Most small companies can't answer that, because deals live in the CRM and what each customer actually bought lives in invoicing. Put the two together and you get a list you can start calling from on Monday morning.
The work nobody wants
Picture a twenty-person company that sells printer servicing, consumables and equipment rental. The sales rep knows some customers only ever order toner. Which ones exactly? Finding out means opening invoicing, exporting a year of line items, matching them to companies in the CRM where the names are spelled slightly differently, then hunting for gaps in a spreadsheet.
It happens once a quarter, if at all. A week later the spreadsheet is out of date and nobody remembers who edited it last. So the team calls whoever got in touch first, and everyone else keeps buying one product out of seven.
That customer has bought paper from us for five years. They found out we do servicing from a competitor.
— A sales meeting, paraphrased
What connecting the CRM and invoicing actually means
Claude knows nothing about your customers on its own. The model isn't what's missing. What's missing is a path between Claude and the data you already have. We build that path as a small MCP server: a narrow bridge that can read customers and deals from the CRM and line items from issued invoices.
The bridge doesn't copy anything into someone else's database. When a rep asks “which customers buy consumables but have no service contract?”, Claude fetches the data at that moment, under that rep's name and permissions, and answers with a list. Next to every name it shows what the answer rests on: the date of the last invoice, what the customer buys and what they don't.
Concretely: Raynet and Fakturoid
Take a common Czech setup: customers and deals in Raynet, invoices in Fakturoid. Both stay exactly as they are; we only add the bridge. A company with a few hundred active customers and several product lines usually has dozens of combinations nobody checks, and that is where cross-sell quietly leaks away (an illustrative estimate, not a measurement).
- Matches each CRM company to the invoicing customer by company ID (IČO), not by a name that's spelled differently in every system.
- Works out, for each customer, which product lines they buy and which they don't.
- Finds patterns: similar customers who buy A and B, set against those who only buy A.
- Ranks opportunities by volume, how long since the last order and open deals in the CRM, so nobody gets called twice.
- On request, drafts a short call brief with the customer's history.
For illustration: a small coffee wholesaler in Brno sells beans to offices and cafés. On Monday the owner asks which offices buy coffee but have never ordered machine servicing. A minute later there are twelve companies on the list. Three run a machine older than five years, and one has an open enquiry in the CRM that nobody followed up. That's how Monday starts.
What cross-selling with Claude won't do, and why that's good
Claude doesn't call or email the customer on its own. It doesn't decide whether an offer is appropriate. It doesn't know the owner complained about a delivery last month and now is the wrong moment, unless someone wrote that down. The rep knows, which is why a person reads the list rather than a mass-mailing machine.
That limit isn't a weakness. Give someone a list with reasons and they can check it, strike a name and come back to another in a month. Launch an automated campaign and you usually hear about the mistake from an annoyed customer. Harvard Business Review notes that winning a new customer costs five to twenty-five times more than keeping an existing one. The relationship with the customers you already have is exactly the thing not to gamble with.
What it would take
Not a year-long project. The bridge to your CRM and invoicing runs on your infrastructure, in your tenant, with your people's identities. You start with the one question sales asks most often and test it on real data. Once the query works, we save it as a shared skill: a “weekly cross-sell review” any rep can run, each with their own permissions.
What's left
A better model won't sign a single service contract by itself. You've had the data on who buys what for years. The only thing missing is the bridge between that data and Claude, and that's what we build.
If you'd like to see how this looks on your own data, write to us. A short call is enough to work out which systems to connect first and which question the first report should answer.