A CRM report on average order value answers the one question total revenue hides: are you growing because customers spend more per purchase, or because more of them buy, and buy smaller? In most small companies someone builds that answer by hand from an export, slightly differently each time. It can be done so that leadership gets the same view every Monday morning.
The work nobody wants
On Monday morning the owner wants to know how last week went. The sales lead or an assistant opens the CRM, exports orders to a spreadsheet, deletes cancellations, removes by hand the one large deal that would skew the figure, and divides revenue by the order count. Then the same again for last month, so there is something to compare against.
It doesn't take all day, more like an hour or two. The worse part is that everyone calculates it differently. One week cancellations are subtracted, the next they are not. One week VAT is in, the next it is out. You end up with two numbers that can't be compared, and a meeting that argues about whose spreadsheet is right instead of talking about customers.
“Revenue is up. Nobody can say why.”
— A Monday meeting, abridged
What a shared average order skill actually means
Average order value (AOV) is a simple ratio: revenue for a period divided by the number of orders in that period. What matters is what goes into that number and what stays out. That is exactly the kind of decision that should be written down once and then simply reused.
With us, it is a skill in the skills library: a short, versioned procedure that says how the report is calculated. Net of VAT, without cancellations, orders above a set threshold reported separately, split into new and returning customers. In Anthropic's terms it is an Agent Skill, a folder of instructions Claude loads when a task calls for it. Claude runs it against CRM data through a small MCP server that carries the identity of the person asking. Nothing is copied anywhere, and nothing is indexed into a vendor's cache.
Concretely: Raynet, Shoptet and Pohoda
A typical smaller company keeps its orders in two or three places: an e-shop on Shoptet, deals in a CRM such as Raynet or HubSpot, invoices in Pohoda. Those systems stay as they are. We add the bridge. For a company with a few hundred orders a month (an illustrative scale), that means one MCP server per source and one skill that assembles the report from them.
- Pulls orders for the past week and for the same period last year, always under the same definition (net of VAT, no cancellations or returns).
- Splits the change in revenue into two parts: how many more orders came in, and how the average order moved.
- Shows the median next to the mean, so one exceptional deal does not distort the picture.
- Breaks the figures down into new and returning customers and the main channels (e-shop, sales reps, wholesale).
- Writes a short summary and flags whatever departs from a normal week.
Picture a small Prague company selling coffee and café equipment (an illustrative example). Quarterly revenue is up 18%. The report shows orders are up 24% while the average order fell by about 5%. Small e-shop customers are growing, and cafés are ordering smaller packs. That may well be good news for the business. It is simply different news from what the owner would read off total revenue, and it leads to different decisions: where to set the free shipping threshold, which bundles to offer, who a sales rep should call.
What the skill won't do for you, and why that's good
The skill does not decide whether a falling average order is a problem. It might mean you are losing large accounts, or that you are winning lots of small new ones. Same number, opposite meaning. That call belongs to someone who knows the customers.
Nor does the skill change its own definition. When leadership decides wholesale belongs on a separate line, the skill is edited, a new version is published, and from the next Monday everyone counts the same way. You can see who changed what, and when. The fact that nobody quietly rewrites the procedure is the reason you can trust it.
What it would take
Not a year-long project. We start by sitting down with whoever builds the report today and writing down the definition: what counts as an order, what gets subtracted, which segments leadership wants to see. We build MCP servers to the sources you already have and deploy them on your own infrastructure. We publish the skill to the library. From then on anyone with access can run the report under their own permissions, and every run lands in one audit trail.
What's left
Claude has been able to compute an average and write a sensible summary for a long time. What was missing was a connection to your orders and one shared definition to calculate by. The model is not the bottleneck. The gap between Claude and the data your company already has is the bottleneck. We close it.
If your Monday numbers are put together by hand, a little differently each time, write to us. In a short call we'll look at where your orders live and what the first report would look like.