Few small companies have a CRM report on discounts. The reason is simple: a discount lives in two places. In the CRM it is a reason ('long-standing customer', 'a competitor quoted lower'). In Pohoda it is a number on an invoice. Anyone who wants to know how much margin discounts took last quarter has to join the two by hand, so usually nobody does.
The work nobody wants
A salesperson gives a discount because the deal needs to close. They type a few words in the CRM about why. The invoice then leaves Pohoda at a price that differs from the price list, and nobody names the gap. Sometimes the discount arrives later as a credit note. By month end there is a pile of reasons in one system and a pile of numbers in the other, each with the customer's name spelled slightly differently.
When the owner asks what discounts cost us, the exporting starts. Deals from the CRM into one spreadsheet, invoices from Pohoda into another, matching by company name, chasing the rows that didn't match because one says 's.r.o.' and the other doesn't. An afternoon of work, and a result nobody fully trusts, because half the rows passed through someone's hands.
And a discount doesn't come off revenue, it comes off margin. A simple example: a company sells at a 25 % gross margin and gives 10 % off. It doesn't lose a tenth of the profit on that deal, it loses 40 %. McKinsey's well-known pricing analysis found that for the average large company, a 1 % improvement in price at steady volume would lift operating profit by roughly 8.7 %. The same works in reverse, and for a small company with thin margins it hurts more.
'We gave the discount because it was needed. What it added up to over the year, we never counted.'
— A quarterly review, abridged
What connected actually means
Claude can calculate, compare and explain. On its own, it can't see into your CRM or into Pohoda. That gap is closed by a small, focused MCP server: a bridge through which Claude asks the system where the data already lives. Nothing is copied into yet another spreadsheet, and nothing is stored in someone else's cache.
The bridge carries the identity of the person asking. When the sales director asks, they see every deal. When a salesperson asks, they see their own. Claude then joins the discount reason from the CRM with the invoiced amount from Pohoda and answers in one overview: how much, to whom, why, and who approved it.
Concretely: your CRM and Pohoda
Nothing changes for the company. Sales keeps working in its CRM, whether that's Raynet, Pipedrive or HubSpot, and invoicing keeps running in Pohoda. Two small bridges are added, one to each system. For a company issuing a few hundred invoices a month, this is typically a few days of setup, not a year-long project (an illustrative estimate).
- Finds the list price, the quoted price and the recorded discount reason on every CRM deal.
- Locates the matching invoice in Pohoda and checks what the deal actually sold for, including later credit notes.
- Calculates how much each discount took from gross margin, not only from revenue.
- Groups discounts by salesperson, customer type and recorded reason.
- Flags deals where the invoiced price differs from the approved quote.
Picture a Brno company with eight salespeople supplying office equipment (an illustrative example). The director types: 'How much did discounts above 15 % cost us in Q1, and who gave them?' A few moments later there's an overview that would otherwise take an afternoon to assemble. In it, they might find that most of the discount money didn't go to new customers, the ones discounts are usually justified by, but to regulars who would have bought anyway.
What a discount report won't do, and why that's good
Claude doesn't decide whether a discount was right. It sees numbers and recorded reasons. It didn't hear the phone call in which the customer said they would otherwise walk. That judgement stays with the salesperson and management, as does the decision to tighten approval rules.
Claude also changes nothing in the CRM or in Pohoda. The bridge is read-only. No invoice corrects itself and no price list gets rewritten. That is exactly why the report can be relied on: it shows what is really in your systems and leaves decisions to the people accountable for them.
What it would take
A short conversation about which CRM you run and who has access to what. Then two MCP servers on your own infrastructure, wired to the permissions that already exist. We save the discount report as a skill in your shared library. Tomorrow morning anyone in management can run it with the same question and get an answer scoped to their own rights.
What's left
Working out what discounts cost takes Claude a few seconds. That was never the problem. The problem was that the reason and the price sat in two systems that don't talk to each other. The model is not the bottleneck. The gap between Claude and the data your company already has is the bottleneck. We close that gap.
If you'd like to know what discounts cost you last quarter, write to us. A short call is enough for us to tell you what connecting your CRM and Pohoda would involve.