Paaugstināt cenas esošajiem klientiem

Kad izmantot

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.

Pirms sāc

• 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).

Ko izpilde pieprasa2

Ceļš10 soļi

1. S1

   Read the contractsaģents

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

   Izdarīts, kad 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 countryaģents

   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).

   Izdarīts, kad a written line per country: minimum notice, any form requirement, any prohibition.

3. S3

   Build the raise listaģents

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

   Izdarīts, kad the owner can see the whole list on one screen and the total uplift.

4. S4

   Decideīpašnieksvajag apstiprinājumu · īpašnieks

   Apstiprinājums · S4 · īpašnieks — izpilde apstājas, līdz nosaukts cilvēks ieraksta lēmumu

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

   Izdarīts, kad the decision is recorded: who, price, date, fallback.

5. S5

   Draft the noticeaģents

   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.

   Izdarīts, kad the draft matches the decision in S4 and every date clears every notice period.

6. S6

   Approve sendingīpašnieksvajag apstiprinājumu · īpašnieks

   Apstiprinājums · S6 · īpašnieks — izpilde apstājas, līdz nosaukts cilvēks ieraksta lēmumu

   Izdarīts, kad the owner approves the final text and the send list.

7. S7

   Send and logaģents

   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.

   Izdarīts, kad every affected customer has a sent notice logged with a timestamp before the effective date.

8. S8

   Handle responsesaģents

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

   Izdarīts, kad every response is logged as accepted · objected (owner decides) · churned.

9. S9

   Apply prices on the effective dateaģents

   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.

   Izdarīts, kad the next invoice for each raised customer shows the new price and no invoice before the date does.

10. S10

    Record and reportaģents

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

    Izdarīts, kad the owner has a one-page summary and the follow-up task exists.

Pārbaudes — kā zinām, ka izdevās

• 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.

Ja noiet greizi

Ko atstāj katrs solis

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.

Ko saglabāt

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.

Kā šī procedūra uzlabojas

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.