Raise prices for existing customers

When to use

Existing customers pay less than the company now needs or wants to charge. Not for a price change inside a live public tender or a quote not yet accepted — use sales.prepare-offer. Not for chasing invoices that are simply unpaid at the old price — use money.chase-overdue-invoice. If the raise is really a renegotiation with one strategic customer, do it as a conversation first; this playbook is for the repeatable case.

Before you start

• The owner has named the reason, the size and the intended effective date.
• Every affected customer's contract is in the agreements module, or its missing price clause is known.
• It is decided whether all customers are raised, or only a segment (e.g. all but the three largest).

What a run requires2

The trail10 steps

1. S1

   Read the contractsagent

   For each affected customer, find the price and any price-change clause: fixed price, indexation, notice period, unilateral-change right.

   Done when each customer has one of: clause permits with X days notice · clause silent · price fixed until <date>.

   ⛔ A "prices may be changed" clause does not override a fixed term price or, for consumers, the fairness test — flag it, do not assume it.

2. S2

   Check the law per countryagent

   For consumer customers, check what notice and grounds the country requires for changing a contract price (LV: likumi.lv — Consumer Rights Protection Law; LT and EE equivalents on their official legal portals).

   Done when a written line per country: minimum notice, any form requirement, any prohibition.

3. S3

   Build the raise listagent

   Per customer: current price, new price, % change, contract constraint from S1, revenue at risk. Sort by revenue.

   Done when the owner can see the whole list on one screen and the total uplift.

4. S4

   Decideownerneeds approval · owner

   Approval · S4 · owner — the run stops until a named person records the decision

   Confirm who is raised, by how much, the effective date and what happens to customers who object.

   Done when the decision is recorded: who, price, date, fallback.

5. S5

   Draft the noticeagent

   One page per segment: what changes, the new price, the effective date, why, who to contact. Date it so the longest notice period from S1/S2 is met.

   Done when the draft matches the decision in S4 and every date clears every notice period.

6. S6

   Approve sendingownerneeds approval · owner

   Approval · S6 · owner — the run stops until a named person records the decision

   Done when the owner approves the final text and the send list.

7. S7

   Send and logagent

   Send each notice from the company's role address (not a personal mailbox) via the mail module; record per customer: notice sent, channel, date, effective date.

   Done when every affected customer has a sent notice logged with a timestamp before the effective date.

8. S8

   Handle responsesagent

   Objections go to the owner with the customer's history; discounts or delays only by owner decision.

   Done when every response is logged as accepted · objected (owner decides) · churned.

9. S9

   Apply prices on the effective dateagent

   Enter the new prices in the billing module effective from the agreed date — not earlier. Spot-check the next three invoices against the list from S3.

   Done when the next invoice for each raised customer shows the new price and no invoice before the date does.

10. S10

    Record and reportagent

    Log the run: list, notices, reactions, uplift realised vs expected; flag churned customers for sales.win-back-customer.

    Done when the owner has a one-page summary and the follow-up task exists.

Checks — how we know it worked

• For every raised customer: notice date + notice period ≤ effective date (read the dates back, per customer).
• Every contract clause from S1 was respected — no customer with a fixed price was raised.
• The first invoice after the effective date shows the new price; the last before shows the old.
• No notice was sent from a personal mailbox.

If it goes wrong

What each step leaves behind

1. S1each customer has one of: clause permits with X days notice · clause silent · price fixed until <date>.
2. S2a written line per country: minimum notice, any form requirement, any prohibition.
3. S3the owner can see the whole list on one screen and the total uplift.
4. S4the decision is recorded: who, price, date, fallback.
5. S5the draft matches the decision in S4 and every date clears every notice period.
6. S6the owner approves the final text and the send list.
7. S7every affected customer has a sent notice logged with a timestamp before the effective date.
8. S8every response is logged as accepted · objected (owner decides) · churned.
9. S9the next invoice for each raised customer shows the new price and no invoice before the date does.
10. S10the owner has a one-page summary and the follow-up task exists.

Evidence to keep

The decision in S4 (who, when) · per-customer notice log with timestamps · the sent notice texts · the S1 clause findings · the S9 invoice spot-checks · the reaction log.

How this playbook improves

After every run ask: did any notice miss its notice period, and which step caused it? How much uplift was realised vs expected, and how much was lost to discounts or churn? Did any customer learn of the raise from an invoice? A new version changes the step that failed and says so in its change note.