Contracts & Renewals

In QUIXOTIC, a contract is a contract. It doesn't multiply every time something changes.

The usual problem

In most systems in the sector, any modification creates a new contract: a price change, a power adjustment, an add-on like a virtual battery, a renewal. The result is that a customer with a single supply point can accumulate seven contracts in a year. None of them reflect reality.

This has direct consequences. If the CRM is fed by this data, the customer view gets contaminated. When someone wants to check a renewal, find the active contract, or handle a complaint, they have to navigate between artificial contracts to find the real one.

How it works in QUIXOTIC

Changes are recorded as modifications within the original contract. The Contract gets updated, keeps its version history, and remains a single record.

→ Price or tariff change: the variable is updated, no new product or contract is created
→ Power adjustment: the relevant parameter is modified within the existing contract
→ Adding an add-on (virtual battery, extra service): it's incorporated into the existing contract
→ Renewal: the contract renews without losing traceability to the original

Full flexibility

Some energy suppliers have worked for years with a new-contract-per-change model. They're used to it, and their internal processes depend on it. QUIXOTIC supports both models. If you'd rather have a price change generate a new contract, you can configure it that way.

The difference is that you're not forced to. It's an operational decision, not a technical limitation.

A true view of the customer

When you open a customer's profile in QUIXOTIC, you see their real contracts. Not a list of technical artefacts generated by the system. If it's a contract, it's a contract. If there have been changes, they're there as history, not as duplicates.

This simplifies daily operations, reduces errors in renewals, and removes the need to cross-check data between the ERP and CRM to know what's really going on with each customer.

‍