Pricing Strategy and Business Model Questions

Direct answer

A good enterprise discount policy gives discounts for something the company wants (a bigger or longer commitment, prepayment, a reference) rather than for pressure, sets pre-approved ceilings that rise with contract size, routes anything beyond the ceiling through an approval ladder with a hard cap, and equips account executives (AEs) with a value case so the conversation is "what is this worth to you" rather than "how low can you go". The aim is to protect price realisation (the share of list price actually collected) and avoid discount leakage (discounts given without a matching trade or approval).

The policy artifact (illustrative values to be calibrated)

Pre-approved ceiling by ACV (annual contract value, the yearly value of a contract at list price)

Give-get points (extra discount earned by concessions from the customer)

Approval ladder (by total discount off list)

Rules that make the table work: discounts apply to the platform fee and not to services; any discount must be tied to a stated give; the same discount at renewal is not automatic (the renewal quote starts from the contracted price with a stated uplift); end-of-quarter timing is not a valid reason; and every exception is logged with its reason. The hard cap also limits the earned points: total discount is never above 25% in any band, so in the $500k and above band (a 20% ceiling plus up to 6 earned points would be 26%) earned points stop at 5 and there is no deal desk step above them, while in the lower bands the deal desk step sits between the manager limit and the 25% cap. Anything past 25% is restructured, not approved.

How I would set the numbers

Do not copy a benchmark. Pull the last two to three years of closed deals and compute, by ACV band: win rate by discount depth, average discount, price realisation, and renewal and expansion by discount depth. Look for the knee, the discount level beyond which win rate stops improving (deals above it are being given away, not won). Set ceilings just below the knee, and check results for confounding, since reps give bigger discounts to harder deals, so higher discount can correlate with lower win rate without causing it. Then monitor the policy: discount leakage, exception rate, and time to approve (a slow ladder makes reps route around it).

What AEs get to justify a discount in customer-value terms

• A value case template: the customer's baseline cost or loss (for example hours spent, incidents, revenue at risk), the quantified improvement, and the payback on our price. The Solutions Architect validates the technical assumptions and sizes the scope.
• An ROI calculator that updates when scope or price changes, so the conversation can move from price to scope (for example fewer modules or a phased rollout) before price.
• Reference customers and proof points of similar deals.
• A trade script: "if we can do X percent, we need Y from you" so each concession gets a counter-concession.

Worked example

A $180,000 ACV deal falls in the $150k to $500k band: ceiling 15%. The customer commits for three years (+3 points) and prepays annually (+2 points), so the sales manager can approve up to 20%, giving $180,000 x 0.80 = $144,000 per year. The customer asks for 25%, which is $135,000. That is $9,000 a year below the manager limit and 5 points past it, beyond the 3 points the deal desk can add, so it needs the head of sales and finance with a written value case; my counter is 18% ($147,600 per year) for the three-year prepaid deal, and a phased scope if budget is the real barrier.

Trade-offs and pitfalls

• Too rigid a policy loses strategic deals; too loose trains customers to wait for the quarter-end discount. Keep an exception path with a cost (written case, senior approval).
• Cap the ladder and report exceptions, or the exception becomes the norm.
• Discount depth also affects renewal expectations and the price referenced by other customers, so reuse of the discount must be controlled.
• Align commissions: if reps are paid on bookings regardless of discount, the policy will be gamed; pay on price realisation or discount-adjusted value.

Direct answer

Frame it as a contextual bandit (an algorithm that picks one action per customer using their features and learns from each outcome) over a small set of price points, not as full reinforcement learning, unless prices today demonstrably change which state the customer is in tomorrow. Represent each customer by context (tenure, recent usage), score each price with a purchase-probability model that shares information across prices, pick prices by Thompson sampling (draw a plausible model from the posterior, the model's current range of plausible values given the data so far, and act on it), bound the exploration cost with price guardrails and a small exploration share, add fairness constraints on how far prices may differ between similar customers, and prove it offline with inverse-propensity scoring on logged randomised prices before any live launch.

The essentials are the bandit framing, Thompson sampling, a cap on exploration cost, fairness limits and the inverse-propensity evaluation. The Lagrangian churn penalty, doubly-robust estimators and the reinforcement-learning comparison are refinements for follow-up questions.

Design

Problem framing. State is the context $x$, what you know about the customer right now (tenure, usage trend, plan). Action is the choice you make, one of K price points (say $9, $11, $13). Reward is what you want to maximise, here margin over a horizon rather than a click or a single-session sale. Reinforcement learning (RL) is the right frame only if today's price changes tomorrow's state in a way that matters (a high price now drives churn that removes all future orders). Handle that in a bandit by defining reward over a long enough window (for example 90-day margin) or by subtracting a churn penalty, and move to RL only with a trustworthy simulator or rich logged data, since RL's exploration is costly with real customers.

How arms are represented and updated. Each price point is an arm. Rather than K separate models that learn slowly, fit one purchase model such as a Bayesian logistic regression (a purchase-probability model that keeps a range of plausible coefficients instead of one fixed set) with features: context, price, and price-by-context interactions (letting the effect of price differ by tenure, for example). Prices share information through the price coefficient: the model has one number saying how much purchase probability falls per dollar, so every customer shown $9 or $13 also teaches it about $11, which nobody may have seen yet. Thompson sampling then draws coefficients from the posterior, scores each price by expected margin $(\text{price} - \text{cost}) \times P(\text{buy})$, and picks the best. Update in daily batches so that a customer's price is stable (assign once per customer per period, never per page view).

A tiny worked draw, using the new-customer purchase rates from the logs below (30% at $9, 24% at $11, 15% at $13) and a unit cost of $4. The model's current best guess favours $11, but it is uncertain. On one draw the sampled purchase probabilities are 0.28, 0.25 and 0.17, giving expected margin (price - cost) x P(buy) of 5 x 0.28 = 1.40, 7 x 0.25 = 1.75 and 9 x 0.17 = 1.53, so it shows $11. On another draw they are 0.31, 0.21 and 0.19, giving 1.55, 1.47 and 1.71, so it shows $13 and learns whether $13 really sells better than the logs suggest. That occasional pick of a price that looks second-best is the exploration; as data accumulates the draws tighten and the choice settles. The numbers are illustrative draws.

Constrained optimisation. The business constraints are a churn cap and a minimum margin. Use a Lagrangian (a way to fold a constraint into the objective by charging a price, $\lambda$, for breaking it): reward becomes margin minus $\lambda$ times predicted churn probability, with $\lambda$ tuned until the aggregate churn constraint just binds. Illustration for a tenured customer, unit cost $4, with purchase probabilities 0.45, 0.42, 0.38 and predicted churn probabilities 3%, 5%, 8% at $9, $11, $13. With $\lambda$ = 0, expected margins are 2.25, 2.94 and 3.42, so $13 wins. With $\lambda$ = 10 (each churn costs the business $10 of future margin) they become 1.95, 2.44 and 2.62, still $13. With $\lambda$ = 20 they become 1.65, 1.94 and 1.82, so $11 wins. Raising $\lambda$ moves prices toward the lower-churn options until total churn falls to the cap, and that is the value you tune. Enforce the margin floor by removing arms below it per customer. A cleaner alternative when you have several products is to solve a small optimisation each period (maximise expected margin subject to cohort-level churn and margin constraints), with the bandit supplying the demand estimates.

Cost of exploration. Limit arms to a band around the current price, keep a margin floor on every arm, cap the share of traffic that explores (for example 10 to 20%), and track regret (the margin lost against the best arm in hindsight). Stop exploring in segments where the posterior is already tight.

Fairness. Use only features customers would accept as legitimate (tenure, usage, plan), and exclude protected attributes and close proxies such as precise location. Cap the dispersion of prices among similar customers (for example, the highest price offered to a cohort (a group of customers with similar tenure and usage) at most 1.2 times the lowest), never price on signs of urgency or vulnerability, and audit price outcomes by group after launch. Personalised pricing rules differ by jurisdiction, so involve legal.

Offline evaluation

If past prices were assigned at random with known probabilities, you can estimate what a new policy would have earned. Inverse-propensity scoring (IPS) keeps only logged rows where the logged price equals the new policy's choice and weights each by one over the probability of that price being shown (the propensity: the chance the logging policy had of showing that price). The pinned example below has two contexts and three prices, each shown with probability 1/3 over 200 impressions per cell. Run it as is.

# Offline evaluation of a context-dependent price policy from logs where the price was assigned uniformly at random
UNIT_COST = 4.0
PRICES = [9.0, 11.0, 13.0]
PROPENSITY = 1 / len(PRICES)                 # each price was shown with probability 1/3
# purchases out of 200 impressions for each (context, price)
purchases = {("new", 9.0): 60, ("new", 11.0): 48, ("new", 13.0): 30,
             ("tenured", 9.0): 90, ("tenured", 11.0): 84, ("tenured", 13.0): 76}
logs = []                                    # one row per impression: (context, price shown, margin earned)
for (ctx, price), bought in purchases.items():
    logs += [(ctx, price, price - UNIT_COST)] * bought + [(ctx, price, 0.0)] * (200 - bought)

def ips_value(policy):
    """Inverse-propensity estimate of average margin per impression if `policy` had chosen the price."""
    return sum(m / PROPENSITY for ctx, p, m in logs if policy(ctx) == p) / len(logs)

def effective_sample(policy):
    matched = sum(1 for ctx, p, _ in logs if policy(ctx) == p)
    return matched, len(logs)

logging_value = sum(m for _, _, m in logs) / len(logs)
policy = lambda ctx: 11.0 if ctx == "new" else 13.0
fixed_11 = lambda ctx: 11.0
print("logging policy (uniform random): %.3f margin per impression" % logging_value)
print("always $11 (IPS):                %.3f" % ips_value(fixed_11))
print("new->$11, tenured->$13 (IPS):    %.3f" % ips_value(policy))
print("rows the candidate policy agrees with: %d of %d" % effective_sample(policy))

Output:

logging policy (uniform random): 2.190 margin per impression
always $11 (IPS):                2.310
new->$11, tenured->$13 (IPS):    2.550
rows the candidate policy agrees with: 400 of 1200

Reading it: a policy that charges new customers $11 and tenured customers $13 is estimated at 2.550 margin per impression, against 2.190 for the logging policy and 2.310 for always charging $11. The policy agrees with only 400 of the 1,200 logged rows, so its estimate rests on 400 rows. That is why a bootstrap confidence interval must accompany any IPS number before a decision. This reward is margin from conversion only; real use adds the churn penalty and a dispersion check.

Further offline safeguards: check overlap (every price the policy picks must have had a real chance of being logged, otherwise weights explode), compare against two variants (self-normalised IPS divides by the sum of the weights instead of the row count, which reduces the swings; a doubly-robust estimator combines a purchase-model prediction with an IPS correction, so it stays accurate if either the model or the weights are good), and backtest (replay the policy on past periods) on several time slices. If no randomised logs exist, you cannot evaluate this offline honestly: run a randomised exploration phase first.

Launch plan

Shadow mode (compute prices, do not show them), then a small live test with a kill switch and the guardrails above, then ramp. Success criteria are margin per customer and churn against the flat-price control, plus the dispersion audit.

Trade-offs

The bandit adds complexity over a few well-chosen segment prices. If the interval around the policy's gain overlaps zero, ship the simpler segment pricing instead.

Direct answer

Report six KPIs (key performance indicators, the measures you track), in this priority order: (1) plan-page conversion to paid, (2) realised average revenue per account, (3) downgrade and cancellation-request rate, (4) churn at renewal (logo and revenue), (5) net revenue retention, and (6) discount rate and win rate on sales-assisted deals (deals a salesperson works, as opposed to self-serve checkout). Four are leading indicators (they move within days or weeks and predict the outcome) and two are lagging indicators (they confirm the outcome after months). Priority combines two things: how much the number decides whether the price change stays, and how soon you can read it. So the first three tell you early whether to worry; churn and net revenue retention deliver the final verdict.

The six KPIs

Count: six KPIs, four leading (1, 2, 3, 6) and two lagging (4, 5).

Definitions with a worked example

Take a cohort that paid $100,000 per month a year ago. Over the year those same accounts added $12,000 of expansion (more seats or upgrades), lost $5,000 to contraction (downgrades) and lost $9,000 to churn (cancellations).

• NRR = (100,000 + 12,000 - 5,000 - 9,000) / 100,000 = 98%.
• GRR (gross revenue retention, the same measure excluding expansion, capped at 100%) = (100,000 - 5,000 - 9,000) / 100,000 = 86%.

Reporting GRR alongside NRR matters after a price increase: NRR can look healthy because the price rise itself adds revenue from customers who stay while GRR shows the damage. Suppose a 10% price rise on the $86,000 of base revenue that remains adds $8,600. NRR becomes (86,000 + 12,000 + 8,600) / 100,000 = 106.6%, which reads as growth, while GRR stays at 86%, because the price rise is not retention.

The same pricing change, as one reporting line per KPI after four weeks (illustrative numbers, 10% list rise from $50 to $55):

Revenue per visitor is 4.0% x $50 = $2.00 before and 3.7% x $53.50 = $1.98 after, so the early signals are mixed: ARPA rose, but conversion fell by enough to leave revenue per visitor slightly lower. The ARPA alert is already breached ($3.50 is 70% of the $5 rise, against an 80% floor), so the first action is to find where discounts or credits are eating the increase; the other leading alerts have not fired. The thresholds are set before launch from the week-to-week noise in each baseline, not from the post-launch numbers.

How to run the reporting

• Weeks 1 to 4: report KPIs 1, 2, 3 and 6 weekly. Agree before launch the level of conversion drop or cancellation requests that triggers a review.
• Months 2 to 12: add KPI 4 as cohorts reach renewal, split by segment and plan. Annual contracts only show churn when they renew, so say which cohorts are not yet observable instead of reporting an artificially low churn.
• Quarterly: report KPI 5 with GRR.
• Format: one line per KPI with baseline, current value, direction and whether it is leading or lagging, as in the table above, so stakeholders do not mistake an early good signal for the final verdict.

Pitfalls

• Reporting conversion and ARPA without the denominator: if conversion falls and ARPA rises, revenue per visitor (conversion x price) is the number that decides.
• Letting NRR dominate. It lags by a renewal cycle and hides churn behind price-driven expansion.
• Comparing to last month instead of a comparison group (similar customers whose price did not change): seasonality and promotions move all of these KPIs.
• Giving every stakeholder every KPI. Sales does not need NRR in week two; the CFO does not need win rate by rep.

Direct answer

Net revenue per trial is conversion rate times ACV (annual contract value, the yearly price of a signed customer): control 0.25 x ACV, treatment 0.21 x 1.12 x ACV. The treatment earns about 5.9% less revenue per trial, because a 19.0% ACV uplift would have been needed to offset a 25% to 21% conversion fall and the test delivered 12%. The conversion drop is statistically clear, but at a realistic sample size the revenue-per-trial difference is not, so the recommendation is not to roll out globally yet: segment the result, check retention, and extend or re-run for revenue per trial rather than conversion.

Step 1: net revenue per trial

Let the control ACV be $1,200 per year (illustrative). Revenue per trial is the average over all trials, including those that never convert, so non-converters count as $0.

$\text{control} = 0.25 \times 1200 = \$300.00$

$\text{treatment} = 0.21 \times (1200 \times 1.12) = 0.21 \times 1344 = \$282.24$

The break-even ACV uplift is the ratio of the conversion rates: 0.25 / 0.21 = 1.190, so +19.0%. The observed +12% is short of that, so revenue per trial falls (282.24 / 300 - 1 = -5.9%).

Step 2: test significance, and why one test is not enough

Two different questions need two tests.

• Conversion (a proportion): a two-proportion z-test with pooled variance. It asks whether 25% and 21% differ by more than random sampling noise, estimating that noise from one shared (pooled) conversion rate of 23%.
• Revenue per trial (a mean of a mix of zeros and positive ACVs): compare the two means with a Welch-type z or t test (a test of two averages that does not assume both arms have the same spread), or bootstrap the trials (re-sample them with replacement thousands of times and see how much the difference wobbles). Test on all randomised trials, not only converters, because analysing only converters compares two self-selected groups.

The sample size and ACV spread are not in the question, so assume 4,000 trials per arm (about 500 trials a week per arm over 8 weeks, a plausible volume for a mid-size product) and a standard deviation of ACV among converts of 60% of the mean (contract values are right-skewed, so a spread of half to two thirds of the mean is a common planning guess). Both are illustrative and should be replaced by the real figures.

Why the variance formula in the code has that shape: each trial is worth either $0 or an ACV draw. Squaring a trial's revenue gives 0 for non-converters and, for converters, on average sd^2 + acv^2, so the average squared revenue is p x (sd^2 + acv^2). The variance is that minus the squared mean, (p x acv)^2. The zeros matter because they add spread: for control, revenue per trial has a mean of $300 but a standard deviation of about $632, because three quarters of trials contribute $0 and the rest contribute around $1,200.

import math
from statistics import NormalDist

n = 4000                       # trials per arm (illustrative)
p_c, p_t = 0.25, 0.21          # trial-to-paid conversion
acv_c = 1200.0                 # control ACV among converts, USD per year (illustrative)
acv_t = acv_c * 1.12           # treatment ACV: +12%
cv = 0.60                      # assumed spread of ACV among converts (sd = 0.6 x mean)

def rev_per_trial(p, acv):
    # Each trial pays 0 or an ACV draw: mean = p*acv, variance = p*(sd^2+acv^2) - (p*acv)^2
    sd = cv * acv
    mean = p * acv
    var = p * (sd**2 + acv**2) - mean**2
    return mean, var

m_c, v_c = rev_per_trial(p_c, acv_c)
m_t, v_t = rev_per_trial(p_t, acv_t)
print(f"revenue per trial: control ${m_c:.2f}, treatment ${m_t:.2f}, change {m_t/m_c-1:+.1%}")
print(f"break-even ACV uplift for -4pp conversion: {p_c/p_t-1:+.1%}")

# 1) conversion alone: two-proportion z-test with pooled variance
pool = (p_c + p_t) / 2
se_p = math.sqrt(pool * (1 - pool) * 2 / n)
z_p = (p_t - p_c) / se_p
print(f"conversion z = {z_p:.2f}, two-sided p = {2*(1-NormalDist().cdf(abs(z_p))):.5f}")

# 2) revenue per trial: Welch z on the difference of means
se_r = math.sqrt(v_c / n + v_t / n)
diff = m_t - m_c
z_r = diff / se_r
lo, hi = diff - 1.96 * se_r, diff + 1.96 * se_r
print(f"revenue/trial diff ${diff:.2f}, se ${se_r:.2f}, z = {z_r:.2f}, p = {2*(1-NormalDist().cdf(abs(z_r))):.3f}")
print(f"95% CI for diff: ${lo:.2f} to ${hi:.2f}")

# 3) trials per arm needed to detect this size of revenue gap (80% power, alpha 0.05 two-sided)
za, zb = NormalDist().inv_cdf(0.975), NormalDist().inv_cdf(0.80)
n_needed = (za + zb) ** 2 * (v_c + v_t) / diff**2
print(f"trials per arm for 80% power on revenue/trial: {math.ceil(n_needed):,}")

Output:

revenue per trial: control $300.00, treatment $282.24, change -5.9%
break-even ACV uplift for -4pp conversion: +19.0%
conversion z = -4.25, two-sided p = 0.00002
revenue/trial diff $-17.76, se $14.46, z = -1.23, p = 0.219
95% CI for diff: $-46.09 to $10.57
trials per arm for 80% power on revenue/trial: 20,799

A z value counts how many standard errors (the typical size of sampling noise) the observed gap sits from zero; beyond about 1.96 in either direction is the usual 5% significance line. The p-value is the probability of seeing a gap at least this large if the price change did nothing. The conversion drop is highly significant (z = -4.25, p = 0.00002, about 2 in 100,000). The revenue per trial gap of -$17.76 has a 95% confidence interval (the range of true gaps consistent with the data) from -$46.09 to +$10.57, which includes zero (z = -1.23, p = 0.219, about 1 in 5). So the test proves price hurts conversion, but cannot tell, at this size, whether it hurts revenue. Detecting a gap of this size with 80% power (the test would catch a true gap of this size four times in five) at the 5% significance level would take about 20,799 trials per arm, assuming the same spread. Check also that the +12% ACV difference is itself significant and not a few large customers.

Step 3: recommendation

Do not roll out globally on this evidence. The point estimate is negative on first-year revenue and the interval is wide, so the plausible outcomes include a loss. The sensible next steps, in order:

1. Cut the result by segment (plan, company size, channel), fixing the segments before looking. If conversion held in larger-ACV trials and fell only in small ones, a targeted increase may pay.
2. Extend the test or re-run with a sample sized for revenue per trial.
3. Read retention for the converts in each arm before deciding, since an 8-week window cannot show churn.

Other considerations that matter

• Profit, not revenue: a price rise adds no cost. If cost to serve is $240 per account per year (illustrative), gross profit per trial is 0.25 x (1200 - 240) = $240.00 for control and 0.21 x (1344 - 240) = $231.84 for treatment, still 3.4% lower.
• Acquisition efficiency: trial cost is unchanged but fewer trials convert, so cost per paying customer rises by 0.25 / 0.21 = 1.19, a 19.0% increase in customer acquisition cost (the spend needed to win one paying customer).
• Retention and lifetime value: higher prices can lower retention. Compare hazard (the monthly chance a customer cancels) or 90-day retention by arm.
• Mix shift: ACV rose 12% on a 10% price rise, so some of it is composition (customers choosing bigger plans, or small ones not converting), which will not repeat when scaled.
• Test validity: check sample ratio mismatch (arm sizes differ from the planned split), novelty effects (early behaviour that fades once the price is no longer new) in an 8-week window, and seasonality.
• Rollout: regional and currency differences, grandfathering existing customers (keeping them on their old price), and how the price is displayed.

Direct answer

Segment customers by anything that predicts willingness to pay (the most a customer would pay, abbreviated WTP) and that you can observe and enforce cheaply. What makes a segment enforceable is a fence: a barrier, such as a verification step or a product limit, that stops customers willing to pay more from taking the cheaper price meant for another group. There are three families: observable traits (country, company size, student status), observed behaviour (how much and how they use the product), and self-selection (the customer picks a version, such as a tier, annual billing or a discount channel, and so reveals their own segment). I would start with self-selected versions built on a usage-based value metric (the unit the price scales with, such as seats or API calls), then add cheap observable fences, and avoid per-person pricing.

The three approaches compared

The data that matters most for all three is price response by segment: how conversion changes when the price changes. If every customer has always seen the same price, history cannot identify it, because there is no price variation to learn from. You then need price tests, a willingness-to-pay survey, or a natural experiment (a past price change or regional launch that happened without you planning a test, so it behaves like one).

Worked example: why the fence is the whole game

Illustrative market: 1,000 students whose WTP is spread evenly from $0 to $20, and 400 professionals whose WTP is spread evenly from $0 to $100. At price p, the share who buy is 1 minus p over their maximum WTP. The reason: if WTP is spread evenly from 0 to a maximum M, the people who will pay at least p are those whose WTP lies between p and M, which is the fraction (M - p)/M = 1 - p/M of the group. At $10, half the students (those with WTP between $10 and $20) buy.

• One price. Revenue is p times buyers. At $50 only professionals buy: 400 x (1 - 50/100) = 200 buyers x $50 = $10,000. This is the best single price in this market (checked over every whole-dollar price from $1 to $100; for example $40 gives 400 x 0.6 = 240 buyers x $40 = $9,600, $60 gives 400 x 0.4 = 160 x $60 = $9,600, and $20 gives 400 x 0.8 = 320 x $20 = $6,400). Lowering it to $10 to catch students gives 1,000 x 0.5 = 500 students x $10 = $5,000, plus 400 x 0.9 = 360 professionals x $10 = $3,600, so $8,600.
• Two prices, perfectly fenced. Students at $10: 500 x $10 = $5,000. Professionals at $50: $10,000. Total $15,000, which is 50% above the best single price.
• Fence fails. If professionals can claim the student price, the market collapses back to the $8,600 case (every buyer pays $10), worse than the single price of $10,000.

So segmentation is only worth the revenue it adds after arbitrage (buying at the cheap price to use or resell at the expensive one) and goodwill costs.

How I would choose

Score each candidate on five questions, in order:

1. Does it predict WTP? Check with data: does conversion or retention at a given price differ by this variable?
2. Can I observe it? At purchase time, cheaply, with low error.
3. Can customers game it? A fence that needs verification (university email, invoice country matching card country) beats an honour system.
4. Is it acceptable? Usage and tier choices are seen as fair; differing prices for the same product by individual profile are treated as unfair and may be restricted by law, so check with legal before using personal attributes.
5. Can I test it? Randomise price within a segment, never across segments you plan to compare.

My pick for a typical software product: tiers on a usage value metric (self-selection plus behaviour), plus a verified student or regional price where the fence is cheap. Estimate each segment's price curve with a staged price test, then set prices to maximise contribution (revenue minus the cost of serving them), not revenue.

Pitfalls

• Segmenting on a proxy that merely correlates (device type) can penalise a group unfairly and invite a trust problem.
• Confounding: if enterprise accounts are also heavier users, "usage predicts WTP" may really be "company size predicts WTP".
• Segments change. Re-estimate after every launch, since competitors react.