aistack
Book consultation →
← All articles
Sales & CRM

A service contract built from customer history, not an empty template

Before a renewal, a sales rep loses hours digging through what the customer actually bought last year. Claude pulls it from the CRM and Pohoda in a minute — and suggests what to add.

June 2026·7 min read·Milan Janoštík·
ClaudeMCPCRMPohoda
Infographic showing data flowing from CRM and accounting system through an MCP bridge into a prepared service contract proposal.

Renewing a service contract should be routine. Instead it's the same theatre every year: the rep opens the CRM, searches for what the customer bought last year. Switches to Pohoda, scrolls through invoices. Tries to find the email thread where the second device stopped working. An hour and a half later, they have a rough summary — and still start from a blank template.

The work nobody talks about

Preparing for a renewal is never listed as a problem in any sales playbook. It's just "looking up a few things." But in a company with twenty or fifty active service contracts, that "few things" adds up to days per year. And because it's invisible work — nobody tracks it, nobody measures it — it stays.

The result is predictable: the rep doesn't have time to prepare properly for every customer. They show up with last year's contract and offer an extension. They give a discount. They don't ask whether the customer added a new location, bought new equipment, or moved their warehouse. The data that would alert them is in the systems — it just never got pulled together.

The customer had three extra service calls in Q4 last year. The rep didn't know. The contract renewed at the same price.

Typical renewal prep scenario, abridged

What connected actually means

AI stack doesn't build a chatbot that "knows your customers." It builds an MCP server — a small, focused connector — that lets Claude read your CRM and Pohoda under the identity of a specific rep. Claude sees exactly what the rep would see if they opened the system manually. Nothing more, nothing less.

The rep writes: "Prepare a customer summary for Novák s.r.o. before the renewal." Claude opens the CRM via MCP — records, service notes, call logs. Switches to Pohoda — invoices for the past twelve months, orders, any overdue flags. It assembles the summary and suggests what to add to the new contract. The whole thing takes a minute.

The rule the bridge holds
Claude never sees more than the rep does
The MCP server carries the user's identity and permissions into every system. If the rep doesn't have access to another team's contracts, neither does Claude. Data doesn't sit in any external cache. Nothing is copied outside your infrastructure.
CRM + Pohoda → MCP bridge (your identity) → service contract proposal

Concretely: Pohoda and your CRM

Pohoda stores invoices, orders, and inventory movements. A CRM — whether Raynet, Pipedrive, or HubSpot — stores call records, opportunities, and contact history. Together they form the complete story of every customer. These systems stay as they are. An MCP server is added that lets Claude read them — under the rep's permissions, in their context.

  • Invoice summary for the past 12 months — what the customer bought and for how much
  • Service calls beyond the contracted scope — a signal to expand coverage
  • CRM records — open opportunities, unresolved issues, promised discounts
  • Draft contract content — specific line items, not an empty template
  • Risk flags — a customer with repeated late payments or an unresolved service ticket

An IT firm with twenty active service contracts could save a full day of rep time per renewal cycle this way. Instead of switching between systems, the rep gets a summary in a minute — and walks into the meeting with a concrete proposal, not the question "so what happened last year again?"

What AI won't do in a renewal — and why that's good

Claude doesn't send the proposal to the customer. It doesn't approve a discount. It doesn't sign the contract. It doesn't decide whether a customer is strategic or worth letting go. Those things belong to the rep — deliberately, not as a technical limitation.

Precisely because the bridge has a clear boundary, it can be trusted. The rep knows what Claude saw and what it didn't. They know the data doesn't leave their infrastructure. And they know the output is a draft — not a decision. That's exactly the kind of contract that makes sense to make with AI.

~1.5 hrs
Average manual prep time for a service contract renewal [ILLUSTRATIVE]
<2 min
Customer summary via MCP bridge [ILLUSTRATIVE]
40%
Sales teams that consider their CRM data unreliable (HubSpot 2023)

What it would take

The MCP server for your CRM and Pohoda is built once. It runs on your infrastructure — not our server, not a vendor cloud. The rep logs in with their own account and Claude gets access under their identity. No year-long implementation project. No data migration. The systems you have today stay in place.

CRM (Raynet / Pipedrive / HubSpot)Pohoda — invoices and ordersMCP server (your infrastructure, your identity)Claude — summary + contract draftRep — decides and sends

What's left

The model is not the bottleneck. Claude can compile a customer summary accurately, quickly, and without the errors that come from switching between tabs. What held it back was the gap between it and the data your company already has — in the CRM, in Pohoda, in the order history. That gap is what we close.

If renewing service contracts takes more of your sales team's time than it should, write to us. A short call is enough to figure out what makes sense to connect first.