# Revenue and margin

> **What you will learn**
> How to judge the third question, why this area gets pushed back, and how to
> check whether you are ready for it.

## The question

> **Does it directly affect revenue or margin?**

"Directly" is the operative word. Almost every project helps revenue eventually,
by some route. What is being asked here is **whether the path is short.**

| | Path |
|---|---|
| Indirect | meeting-notes automation → time saved → more selling time → maybe revenue? |
| **Direct** | price optimisation → **revenue** |

## What falls under this principle

### 1. Dynamic pricing to optimise revenue

Price is the variable that touches revenue **most directly.** And in most
organisations price **rarely changes.** Changing it needs justification,
justification needs research and analysis, and that takes a long time.

Watch what happens when that cycle shortens:

```
Adjust quarterly  →  react to market changes 3 months late
Adjust weekly     →  react one week late
```

Fast reaction is itself revenue. If a competitor cut prices and you find out
three months later, the churn in that window does not come back.

### 2. Real-time competitor price sensing

To adjust price you have to **know today's market price.** Done by hand:

```
12 competitors × 40 key products = 480 prices to check
Doing it weekly: one person, all day
In reality: monthly, and only the top 10 products
```

**Most organisations set prices without knowing the market price.** Not from
ignorance — because checking is expensive.

### 3. P×Q optimisation to maximise profit

Revenue is **price (P) × quantity (Q).** Raise price and quantity falls; lower
it and quantity rises. Where profit peaks differs by product and by season.

With a handful of products a person can do it by feel. With hundreds they
cannot. So most apply **the same margin rate to everything.** That is not
optimal.

**Impact: direct financial results**

## Why it gets pushed back — many prerequisites

```mermaid
graph TD
  A["To do revenue work"] --> B["price data must be organised"]
  A --> C["demand and sales history must exist"]
  A --> D["authority and process to change prices"]
  A --> E["ability to track the outcome"]
  B --> F["Most stall here"]
  C --> F
```

### Where it actually stalls

| Prerequisite | The common reality |
|---|---|
| Price data is organised | several spreadsheets, exception rules only one person knows |
| Sales history exists per product | it does, but in separate systems that are hard to join |
| You can change prices | needs head-office approval, locked by distributor contracts |
| You can track the outcome | no record of price changes, so no before-and-after |

**The last row catches people most often.** Change a price with no record of
when, what, and why, and you cannot prove the effect.

## Checking whether you are ready

Answer these five. **If any answer is "I don't know," solving that first is
faster.**

```
1. Can you pull per-product cost right now?
2. Can you see monthly per-product sales for the last 12 months?
3. When did you last change a price, and what happened?
4. Whose approval do you need to change a price? How many days?
5. Do you know competitor prices right now? When were they checked?
```

Most organisations stall on 3 and 5.

## What you can do anyway

Missing prerequisites do not mean you can do nothing. **Make the preparation
itself the project.**

| If you lack | Do this first |
|---|---|
| Competitor prices | automate price research (start as a cost project) |
| Sales history scattered | automate data collation |
| No price-change history | build the change-record system |

The interesting part is that **most of these preparation projects are cost
projects.** The advice to do cost reduction first lines up here too — the
prerequisites for revenue work get built along the way.

## Real cases

- [dynamic pricing, 4% revenue increase](/ax-consulting/cases/dynamic-pricing-revenue-optimization)
- [global price research automation](/ax-consulting/cases/global-price-research-automation)

The second is exactly the **"make the preparation the project"** shape.

## Common misconceptions

### "Revenue matters most, so shouldn't we start here?"

Importance and sequence are different things. The most common failure pattern is
this:

> Start with a revenue project → four months of data cleanup → nothing to show
> → momentum lost

The advice is not to do the big thing **later**; it is to **build one proof
first.** Produce a cost result in three months and you earn the credibility to
be given four months on a revenue project.

### "We're in an industry where we can't change prices."

Even with fixed prices, **margin** moves.

- Negotiating procurement rates (price on the buying side)
- Product mix optimisation (what to sell more of)
- Discount and promotion efficiency
- Churn prevention (retention is revenue)

Do not read "price" narrowly as list price.

---

## Check yourself

**1. What is the test for "direct impact"?**

<details>
<summary>Answer</summary>

**Whether the path is short.** Almost every project helps revenue eventually.
Direct means almost no intermediate steps, like "price optimisation → revenue."
</details>

**2. Which prerequisite stalls revenue projects most often?**

<details>
<summary>Answer</summary>

**No price-change history** and **not knowing competitor prices.** The former
especially — change a price and you cannot compare before and after, so the
effect cannot be proven.
</details>

**3. What do you do when the prerequisites are missing?**

<details>
<summary>Answer</summary>

**Make the preparation the project.** If you do not know competitor prices,
automate price research; if data is scattered, automate collation. Most of these
turn out to be cost projects, which lines up with the advice to do cost
reduction first.
</details>

---

That is all three principles. Now, how to decide which goes first →
[Sequencing](/guide/ax-sequencing)