Pricing from live market demand
Use MarketInsider, sales feedback and controlled price changes instead of static price tables.
Decision first
Change one product at a time and judge the next full day of units sold, complaints and gross profit.
The best price maximizes total contribution under current demand and capacity, not unit margin, pricing satisfaction, or market share in isolation. Treat the live requirement as the gate for what price optimization means.
Calculate unit contribution.
Complete operating playbook
- ARTICLE LENGTH
- 5,258 words
- DEEP-DIVE SECTIONS
- 15
- RESEARCH LEDGER
- 5
What price optimization means
The best price maximizes total contribution under current demand and capacity, not unit margin, pricing satisfaction, or market share in isolation. Treat the live requirement as the gate for what price optimization means.
Developer material confirms district-sensitive tolerance and demand effects, while 1.0 adds a Pricing Manager for multi-store administration.
Procedure: define a baseline; calculate acquisition cost; record units and customers; change one SKU; compare contribution over matched periods
Example: Raising price from twenty to twenty-two increases unit contribution but reduces units. The change is good only if new units times new contribution exceeds the old product contribution.
When revenue rises but profit falls, inspect inventory cost, wages, campaigns, and lost volume. Inspect price, unit cost, units sold, hourly customers, satisfaction, and total contribution before choosing the more expensive branch.
Record SKU-level baseline and test values plus hours, stock status, and rival context in BizMan. Use price, unit cost, units sold, hourly customers, satisfaction, and total contribution only when its controls remain comparable.
No universal price list can represent every neighborhood, employee skill, rival, difficulty, and patch. Confirm the current F1 requirement again after a relevant patch.
Set a stopping rule before the experiment. Redesign the plan when price, unit cost, units sold, hourly customers, satisfaction, and total contribution remains unfavorable after calculate unit contribution and capture baseline volume both pass.
Define the objective before touching price: maximize product contribution, store contribution, or strategic volume. A lower price can be rational for throughput only when the chosen objective and measurement window are recorded.
Action checklist
- Calculate unit contribution.
- Capture baseline volume.
- Change one SKU.
- Run matched periods.
- Compare total contribution.
| Checkpoint | Evidence of a pass | Response to failure |
|---|---|---|
| calculate unit contribution | price, unit cost, units sold, hourly customers, satisfaction, and total contribution supports the intended condition under the recorded controls. | capture baseline volume |
| change one SKU | SKU-level baseline and test values plus hours, stock status, and rival context is complete and the comparison has no unexplained outage. | run matched periods |
| compare total contribution | The downside is affordable and a review trigger is recorded. | Pause and repeat the smallest disputed test in what price optimization means. |
Verified pricing boundaries
Acceptable prices vary by district, employee capability matters, and being the lowest competitor does not prove customers accept the price. This turns verified pricing boundaries into a measurable commitment rather than a guess.
The developer described a district sweet spot and advised incremental testing against pricing satisfaction.
Procedure: read current market reference; inspect employee service skill; start near a safe point; move gradually; wait for a comparable result
Example: A player undercuts the only rival but still receives complaints because both businesses exceed the district's tolerance. Competitor rank and customer acceptance are different measures.
If pricing satisfaction falls, verify skill, neighborhood, and product before assuming the interface is wrong. Inspect pricing satisfaction, competitor prices, employee skill, and units sold before choosing the more expensive branch.
Record district, lowest market price, own price, employee skill, complaint level, and completed sales in BizMan. Use pricing satisfaction, competitor prices, employee skill, and units sold only when its controls remain comparable.
The linked historical cheat sheet in old discussions is explicitly unsuitable as Confirm the current F1 requirement again after a relevant patch.
Cross-check the management screens. BizMan should explain pricing satisfaction, competitor prices, employee skill, and units sold, while Market Insider or EconoView supplies the market or cost context contained in district, lowest market price, own price, employee skill, complaint level, and completed sales.
Check four boundaries around the sticker: district, competitor context, employee skill, and pricing satisfaction. Being cheapest addresses one boundary and does not prove the neighborhood accepts the price.
Action checklist
- Record district context.
- Verify service skill.
- Start conservatively.
- Increase gradually.
- Observe multiple signals.
| Checkpoint | Evidence of a pass | Response to failure |
|---|---|---|
| record district context | pricing satisfaction, competitor prices, employee skill, and units sold supports the intended condition under the recorded controls. | verify service skill |
| start conservatively | district, lowest market price, own price, employee skill, complaint level, and completed sales is complete and the comparison has no unexplained outage. | increase gradually |
| observe multiple signals | The downside is affordable and a review trigger is recorded. | Pause and repeat the smallest disputed test in verified pricing boundaries. |
Demand is local and product-specific
Market Insider demand applies to products within a neighborhood and changes as providers and market events change. The dated observation becomes the baseline for demand, provider count, market-event state, price, and units.
The progression notes document hype, shortage, and backorder events, while developer explanations include competition in customer volume.
Procedure: select the correct neighborhood; list every intended SKU; capture demand and providers; mark market events; repeat before and after the price test
Example: A price increase coincides with a new rival and lower demand. Without the market snapshot, the lost units would be incorrectly assigned entirely to elasticity.
When price tests disagree across weeks, inspect providers, hype, shortage, and source availability. Inspect demand, provider count, market-event state, price, and units before choosing the more expensive branch.
Record dated Market Insider snapshots linked to each test period in BizMan. Use demand, provider count, market-event state, price, and units only when its controls remain comparable.
Build 3672 fixed the initially selected Market Insider neighborhood, but explicit verification remains prudent. Confirm the current F1 requirement again after a relevant patch.
Ask a counterfactual question: if verify the district were not the constraint, what different result should appear in demand, provider count, market-event state, price, and units? A useful intervention produces distinguishable success and failure signals.
Capture Market Insider immediately before each test. Record demand, providers, and hype, shortage, or backorder affecting the SKU; repeat afterward so a rival opening is not misread as price elasticity.
Action checklist
- Verify the district.
- Capture demand.
- Count providers.
- Mark events.
- Pair snapshots with tests.
| Checkpoint | Evidence of a pass | Response to failure |
|---|---|---|
| verify the district | demand, provider count, market-event state, price, and units supports the intended condition under the recorded controls. | capture demand |
| count providers | dated Market Insider snapshots linked to each test period is complete and the comparison has no unexplained outage. | mark events |
| pair snapshots with tests | The downside is affordable and a review trigger is recorded. | Pause and repeat the smallest disputed test in demand is local and product-specific. |
Unit economics
A sale creates value from the difference between selling price and the acquisition cost attributable to the unit.
EconoView and business reporting separate revenue and inventory cost, allowing contribution calculations without inventing demand coefficients.
Procedure: obtain current unit cost; record selling price; calculate contribution and margin; multiply by units; subtract relevant period costs
Example: Product A sells for twelve with a cost of eight, producing four contribution. Product B sells for ten with a cost of five, producing five despite the lower price.
If a high-revenue item disappoints, inspect cost per unit and inventory source. Inspect selling price, acquisition cost, unit contribution, gross margin, and units before choosing the more expensive branch.
Record cost source, quantity, price, revenue, cost of goods, and contribution in BizMan. Use selling price, acquisition cost, unit contribution, gross margin, and units only when its controls remain comparable.
Acquisition cost can change with supplier, importer index, purchasing skill, shortage, or production route. Confirm the current F1 requirement again after a relevant patch.
Price the opportunity cost. Cash or time committed to capture current cost cannot also fund multiply by units.
Calculate unit contribution as selling price minus current acquisition cost. Divide contribution by selling price for gross margin percentage, but multiply contribution by units to compare total economic output.
Action checklist
- Capture current cost.
- Calculate contribution.
- Calculate margin.
- Multiply by units.
- Reconcile with reports.
| Checkpoint | Evidence of a pass | Response to failure |
|---|---|---|
| capture current cost | selling price, acquisition cost, unit contribution, gross margin, and units supports the intended condition under the recorded controls. | calculate contribution |
| calculate margin | cost source, quantity, price, revenue, cost of goods, and contribution is complete and the comparison has no unexplained outage. | multiply by units |
| reconcile with reports | The downside is affordable and a review trigger is recorded. | Pause and repeat the smallest disputed test in unit economics. |
Volume versus margin experiment
Price changes are useful only when measured against their effect on completed sales volume and total contribution.
Customer reaction and demand can lower traffic or conversion as price rises.
Procedure: select one SKU; preserve stock and hours; record baseline units; change price modestly; compare matched days
Example: At fifteen dollars and ten-dollar cost, one hundred units produce five hundred contribution. At eighteen dollars, sixty units produce four hundred eighty, so the higher price loses despite better margin.
If volume changes, rule out stockouts, schedule changes, rival entry, and market events before assigning causation. Inspect units and contribution at each tested price before choosing the more expensive branch.
Record price, cost, units, customers, stock availability, hours, and anomalies in BizMan. Use units and contribution at each tested price only when its controls remain comparable.
A single day contains noise and weekday weighting; use matched periods. Confirm the current F1 requirement again after a relevant patch.
Follow the cheap branch first: establish choose one SKU, read units and contribution at each tested price, and commit to compare contribution curves only when both support the same explanation.
Build a curve from at least two matched observations. Plot tested price against total product contribution; the stronger point produces more contribution under comparable stock, hours, staffing, and market conditions.
Action checklist
- Choose one SKU.
- Freeze operations.
- Run baseline.
- Apply a small change.
- Compare contribution curves.
| Checkpoint | Evidence of a pass | Response to failure |
|---|---|---|
| choose one SKU | units and contribution at each tested price supports the intended condition under the recorded controls. | freeze operations |
| run baseline | price, cost, units, customers, stock availability, hours, and anomalies is complete and the comparison has no unexplained outage. | apply a small change |
| compare contribution curves | The downside is affordable and a review trigger is recorded. | Pause and repeat the smallest disputed test in volume versus margin experiment. |
Capacity changes price strategy
A capacity-constrained business can sometimes raise price without losing completed volume, while a demand-constrained business may need a different tradeoff. The chosen target must remain serviceable through the next replenishment opportunity.
The building and lowest equipment capacity form a hard ceiling, and marketing cannot exceed it.
Procedure: compare peak customers with effective capacity; identify capped hours; run a small price increase; watch both customers and contribution; inspect uncapped hours separately
Example: A store repeatedly serves twenty customers at its twenty-cap bottleneck. A modest price increase leaves peak volume at twenty and raises contribution, although quieter hours still need review.
If customers fall below the former cap, determine whether price resistance or another operating change caused it. Inspect hourly customers versus effective capacity and contribution per hour before choosing the more expensive branch.
Record capacity, peak and off-peak customers, price, units, queues, and contribution in BizMan. Use hourly customers versus effective capacity and contribution per hour only when its controls remain comparable.
Do not infer infinite pricing power from one capped hour. Confirm the current F1 requirement again after a relevant patch.
Exclude contaminated comparisons. An uncovered shift, closure, stockout, supplier arrival, rival move, hype period, shortage, backorder, or game patch can change the result independently of separate peak hours.
Separate peak and off-peak response. An increase can leave capped noon sales unchanged while reducing evening volume; calculate hourly contribution so one saturated block does not conceal losses elsewhere.
Action checklist
- Measure capacity utilization.
- Separate peak hours.
- Raise one price modestly.
- Watch lost volume.
- Retain only positive contribution.
| Checkpoint | Evidence of a pass | Response to failure |
|---|---|---|
| measure capacity utilization | hourly customers versus effective capacity and contribution per hour supports the intended condition under the recorded controls. | separate peak hours |
| raise one price modestly | capacity, peak and off-peak customers, price, units, queues, and contribution is complete and the comparison has no unexplained outage. | watch lost volume |
| retain only positive contribution | The downside is affordable and a review trigger is recorded. | Pause and repeat the smallest disputed test in capacity changes price strategy. |
Customer satisfaction and conversion
Pricing satisfaction is an important signal but not the sole optimization objective.
The developer links satisfaction to realized customers, and the interface reports pricing separately from other complaints.
Procedure: hold stock and service stable; change one price; monitor satisfaction; compare arrivals and purchases; calculate contribution
Example: A price with perfect satisfaction may leave money on the table, while a slightly lower satisfaction score can produce more profit if volume remains stable. Excessive resistance can reverse the gain.
If purchase completion falls, separate price complaints from queue, cleanliness, interior, or missing-stock complaints. Inspect pricing satisfaction, customer count, units per customer, and contribution before choosing the more expensive branch.
Record complaint categories, customer arrivals, completed transactions, basket size, and price in BizMan. Use pricing satisfaction, customer count, units per customer, and contribution only when its controls remain comparable.
No official source publishes a universal target satisfaction percentage for maximum profit. Confirm the current F1 requirement again after a relevant patch.
Turn the observation into a trigger. Continue while pricing satisfaction, customer count, units per customer, and contribution stays inside the chosen range, invoke record conversion at the boundary, and reconsider the larger plan only after calculate contribution fails. Written triggers make repeated decisions consistent across in-game weeks.
Read pricing satisfaction beside completed units and basket composition. A small decline may be acceptable, but falling customer count or substitution away from a high-contribution product can erase the gain.
Action checklist
- Isolate price feedback.
- Hold other satisfaction stable.
- Record conversion.
- Calculate contribution.
- Reverse harmful changes.
| Checkpoint | Evidence of a pass | Response to failure |
|---|---|---|
| isolate price feedback | pricing satisfaction, customer count, units per customer, and contribution supports the intended condition under the recorded controls. | hold other satisfaction stable |
| record conversion | complaint categories, customer arrivals, completed transactions, basket size, and price is complete and the comparison has no unexplained outage. | calculate contribution |
| reverse harmful changes | The downside is affordable and a review trigger is recorded. | Pause and repeat the smallest disputed test in customer satisfaction and conversion. |
Employee skill as a pricing condition
Employee skill influences customer service and historically affects the maximum price customers tolerate.
Developer pricing guidance conditions maximum prices on employee skill, while customer-service scoring is tied to employee capability.
Procedure: record employee skill; preserve the schedule; establish price baseline; train or replace staff; retest the same price
Example: A price accepted under highly skilled service may receive worse reactions after an untrained replacement takes the register. Treating the price as permanent ignores the service condition.
When pricing satisfaction changes without a price change, inspect staff assignment and skill. Inspect employee skill, customer-service score, pricing satisfaction, and units before choosing the more expensive branch.
Record worker by shift, skill, station, price, complaints, and sales in BizMan. Use employee skill, customer-service score, pricing satisfaction, and units only when its controls remain comparable.
Do not copy maximum-price sheets that assume fully trained employees into an untrained starter store. Confirm the current F1 requirement again after a relevant patch.
Compare a survival case with an upside case, keeping worker by shift, skill, station, price, complaints, and sales explicit in both. The first asks whether the operation remains solvent after record shift skill; the second asks whether retest acceptance has room to add value. A plan that works only under upside assumptions is not ready.
Repeat a price point after major staff changes. If the same price receives different reactions under lower-skilled service, employee condition—not a mysterious reset—belongs in the pricing record.
Action checklist
- Record shift skill.
- Stabilize staffing.
- Run a price baseline.
- Change skill alone.
- Retest acceptance.
| Checkpoint | Evidence of a pass | Response to failure |
|---|---|---|
| record shift skill | employee skill, customer-service score, pricing satisfaction, and units supports the intended condition under the recorded controls. | stabilize staffing |
| run a price baseline | worker by shift, skill, station, price, complaints, and sales is complete and the comparison has no unexplained outage. | change skill alone |
| retest acceptance | The downside is affordable and a review trigger is recorded. | Pause and repeat the smallest disputed test in employee skill as a pricing condition. |
Competitor pricing and rivals
Competitor prices influence the market but do not replace the district's own acceptable range. Keeping the sequence intact gives each change one plausible explanation.
Rival systems can manipulate prices and demand, and developer replies warn that lowest price is not a guarantee of customer approval.
Procedure: record rival prices and providers; identify abnormal events; set an independent safe baseline; test response; compare combined market changes
Example: A rival temporarily cuts prices. Matching immediately may destroy margin even when the player's customers remain capacity-limited. The right response depends on actual lost volume.
When a rival changes price, inspect customer and contribution changes before reacting. Inspect own and rival prices, provider count, hourly customers, demand, and contribution before choosing the more expensive branch.
Record date of rival move, affected products, before-after units, and response cost in BizMan. Use own and rival prices, provider count, hourly customers, demand, and contribution only when its controls remain comparable.
Rival attacks and closures make long tests less controlled; annotate or restart the window. Confirm the current F1 requirement again after a relevant patch.
Resolve reversible uncertainty before irreversible cost. capture rival context can be tested for a short period, while a lease, broad fit-out, specialized hire, or large inventory position persists.
During a rival move, freeze the player's response for one clean interval and measure actual lost units. Undercut only when recovered contribution should exceed margin sacrificed on sales that would occur anyway.
Action checklist
- Capture rival context.
- Measure actual impact.
- Protect margin.
- Test a limited response.
- Compare total profit.
| Checkpoint | Evidence of a pass | Response to failure |
|---|---|---|
| capture rival context | own and rival prices, provider count, hourly customers, demand, and contribution supports the intended condition under the recorded controls. | measure actual impact |
| protect margin | date of rival move, affected products, before-after units, and response cost is complete and the comparison has no unexplained outage. | test a limited response |
| compare total profit | The downside is affordable and a review trigger is recorded. | Pause and repeat the smallest disputed test in competitor pricing and rivals. |
Pricing multiple SKUs
A multi-product store needs SKU-level tests because one aggregated pricing score can hide a strong item and a failing item. Reconciliation decides whether the apparent gain survives all recorded costs.
BizMan provides inventory and pricing controls per item, while product demand and costs differ.
Procedure: rank SKUs by contribution; select one high-impact item; freeze others; run the test; move sequentially through the basket
Example: A supermarket's total revenue rises while one low-margin product loses money and a bestseller stocks out. Aggregate results conceal both opportunities.
If store-level profit changes unexpectedly, decompose units, price, and cost by SKU. Inspect SKU contribution, units, stockouts, and share of total profit before choosing the more expensive branch.
Record one row per SKU with cost, price, units, contribution, capacity, and stock status in BizMan. Use SKU contribution, units, stockouts, and share of total profit only when its controls remain comparable.
Changing all prices at once may be convenient through a manager but is weak experimental design. Confirm the current F1 requirement again after a relevant patch.
Audit every denominator. Write the denominator beside SKU contribution, units, stockouts, and share of total profit; otherwise a changing scale can masquerade as improvement.
Rank multi-SKU tests by importance. Start with products contributing the largest profit share or generating repeated complaints; leave low-volume items unchanged so their noise cannot obscure the hero product.
Action checklist
- Rank SKU importance.
- Test one item.
- Freeze other prices.
- Reconcile totals.
- Iterate by impact.
| Checkpoint | Evidence of a pass | Response to failure |
|---|---|---|
| rank SKU importance | SKU contribution, units, stockouts, and share of total profit supports the intended condition under the recorded controls. | test one item |
| freeze other prices | one row per SKU with cost, price, units, contribution, capacity, and stock status is complete and the comparison has no unexplained outage. | reconcile totals |
| iterate by impact | The downside is affordable and a review trigger is recorded. | Pause and repeat the smallest disputed test in pricing multiple skus. |
Pricing Manager in 1.0
The HQ Pricing Manager can update prices across a neighborhood, and higher skill supplies daily suggested prices. The ordered branches make the first failing transaction step visible.
This behavior is part of the official 1.0 feature set and reduces repetitive administration.
Procedure: retain manual baselines; recruit and assign the manager; review skill and suggestions; apply changes deliberately; audit outcomes by store
Example: A chain uses the manager to coordinate prices but still compares units and contribution. Automation executes a decision; it does not prove the suggestion is profit-optimal for every bottleneck.
If chain profit falls after mass repricing, identify affected stores and SKUs rather than undoing unrelated operations. Inspect suggested price, applied price, manager skill, units, and contribution by store before choosing the more expensive branch.
Record date, neighborhood, suggestion, action, affected businesses, and before-after results in BizMan. Use suggested price, applied price, manager skill, units, and contribution by store only when its controls remain comparable.
The official description does not disclose the suggestion algorithm or guarantee maximum profit. Confirm the current F1 requirement again after a relevant patch.
Keep exception notes instead of smoothing them away. A stockout or rival action may invalidate an average yet expose weakness in review suggestions.
Before accepting a Pricing Manager suggestion, copy proposed and existing prices for affected stores. Apply it to a controlled subset when possible, then compare SKU contribution; automation reduces clicks without revealing its algorithm.
Action checklist
- Preserve pre-manager data.
- Review suggestions.
- Apply in controlled groups.
- Audit affected SKUs.
- Override when evidence disagrees.
| Checkpoint | Evidence of a pass | Response to failure |
|---|---|---|
| preserve pre-manager data | suggested price, applied price, manager skill, units, and contribution by store supports the intended condition under the recorded controls. | review suggestions |
| apply in controlled groups | date, neighborhood, suggestion, action, affected businesses, and before-after results is complete and the comparison has no unexplained outage. | audit affected SKUs |
| override when evidence disagrees | The downside is affordable and a review trigger is recorded. | Pause and repeat the smallest disputed test in pricing manager in 1.0. |
Break-even and fixed-cost coverage
A price plan must cover inventory contribution and the period's wages, rent, marketing, and finance costs.
EconoView exposes the required cost categories even though no single-product business formula is built into official notes.
Procedure: calculate weighted contribution per transaction; total fixed period costs; divide costs by contribution; compare required transactions with realistic capacity and demand
Example: Daily fixed costs are one thousand and average contribution per completed customer is ten, so one hundred completed customers are needed before profit. If capacity and hours permit only eighty, the plan is structurally weak.
If break-even volume exceeds feasible throughput, revise price, product mix, costs, hours, or site. Inspect weighted contribution per customer, fixed cost, feasible customers, and break-even customers before choosing the more expensive branch.
Record sales mix, contribution by SKU, transactions, fixed costs, and capacity-hours in BizMan. Use weighted contribution per customer, fixed cost, feasible customers, and break-even customers only when its controls remain comparable.
The average changes with basket mix, so recalculate after material product or price changes. Confirm the current F1 requirement again after a relevant patch.
Test reproducibility from the record alone. If sales mix, contribution by SKU, transactions, fixed costs, and capacity-hours omits the neighborhood, hours, stock state, staffing, price, or costs needed to recreate the observation, add the missing field. More decimal places cannot compensate for missing operating conditions.
Calculate weighted contribution per customer from the actual basket, then divide fixed costs by that value. If break-even customers exceed capacity-hours or observed demand, price alone cannot rescue the model.
Action checklist
- Calculate weighted contribution.
- Total fixed costs.
- Derive break-even volume.
- Compare with feasible throughput.
- Change the binding assumption.
| Checkpoint | Evidence of a pass | Response to failure |
|---|---|---|
| calculate weighted contribution | weighted contribution per customer, fixed cost, feasible customers, and break-even customers supports the intended condition under the recorded controls. | total fixed costs |
| derive break-even volume | sales mix, contribution by SKU, transactions, fixed costs, and capacity-hours is complete and the comparison has no unexplained outage. | compare with feasible throughput |
| change the binding assumption | The downside is affordable and a review trigger is recorded. | Pause and repeat the smallest disputed test in break-even and fixed-cost coverage. |
Price-test decision tree
A disciplined price diagnosis prevents stock, capacity, hours, or competition changes from being mislabeled as elasticity. The remaining uncertainty should appear in the record attached to test validity followed by unit and contribution response.
The verified system is multi-factor, so transaction prerequisites must be cleared before interpreting price response.
Procedure: verify stock; verify staffing; verify capacity; verify comparable demand and rivals; change one price; compare volume and contribution
Example: Units drop after a price increase, but the product also stocked out at noon. The test is invalid because unavailable inventory, not just price, constrained volume.
If any prerequisite changed, mark the run contaminated and repeat. Inspect test validity followed by unit and contribution response before choosing the more expensive branch.
Record all control variables, anomalies, price, cost, volume, and financial result in BizMan. Use test validity followed by unit and contribution response only when its controls remain comparable.
Perfect control is impossible in a dynamic game; transparent annotations are better than false precision. Confirm the current F1 requirement again after a relevant patch.
Apply validate prerequisites, observe test validity followed by unit and contribution response, and reverse the change when its predicted mechanism does not appear. Scaling a weak signal multiplies uncertainty and cost together.
A valid test requires stock through the interval, identical hours, comparable staff, stable campaigns, and no material rival event. Mark the run unusable when any prerequisite fails instead of averaging contaminated days.
Action checklist
- Validate prerequisites.
- Exclude contaminated periods.
- Change one variable.
- Repeat the comparison.
- Document uncertainty.
| Checkpoint | Evidence of a pass | Response to failure |
|---|---|---|
| validate prerequisites | test validity followed by unit and contribution response supports the intended condition under the recorded controls. | exclude contaminated periods |
| change one variable | all control variables, anomalies, price, cost, volume, and financial result is complete and the comparison has no unexplained outage. | repeat the comparison |
| document uncertainty | The downside is affordable and a review trigger is recorded. | Pause and repeat the smallest disputed test in price-test decision tree. |
Version-sensitive claims to reject
Static maximum-price tables and universal markup rules are especially vulnerable to patches, district differences, staff skill, and rivals.
The developer's own historical answer ties acceptable price to district and skill, while 1.0 adds a dynamic pricing role.
Procedure: identify claim date; identify assumed build; inspect conditions; compare with live feedback; reproduce before adoption
Example: A guide says add a fixed dollar amount in an upper-class district. The current store has different unit cost, rivals, employee skill, and demand, so the instruction lacks transferability.
When a claimed price causes resistance, do not blame the save; reject the unsupported universality. Inspect claim provenance, version, conditions, and reproducibility before choosing the more expensive branch.
Record source date, build, district, difficulty, staffing, price, and observed current result in BizMan. Use claim provenance, version, conditions, and reproducibility only when its controls remain comparable.
Even a Confirm the current F1 requirement again after a relevant patch.
End with a pre-mortem. Assume the choice failed, then rank compare conditions, test live feedback, and retain only reproducible methods by how quickly each would explain the loss.
Reject a table that omits build and assumptions even when its numbers look precise. Transfer the method—small changes and measured response—but derive Build 3674 prices from the current district and staff.
Action checklist
- Date every claim.
- Compare conditions.
- Test live feedback.
- Retain only reproducible methods.
- Flag unresolved gaps.
| Checkpoint | Evidence of a pass | Response to failure |
|---|---|---|
| date every claim | claim provenance, version, conditions, and reproducibility supports the intended condition under the recorded controls. | compare conditions |
| test live feedback | source date, build, district, difficulty, staffing, price, and observed current result is complete and the comparison has no unexplained outage. | retain only reproducible methods |
| flag unresolved gaps | The downside is affordable and a review trigger is recorded. | Pause and repeat the smallest disputed test in version-sensitive claims to reject. |
Final pricing audit
A defensible price is documented, profitable under current conditions, and supported by a clean comparison. That distinction determines which screen can verify final pricing audit.
This audit combines official boundaries, developer advice, and transparent arithmetic without claiming access to hidden demand coefficients.
Procedure: verify costs; verify market snapshot; verify operational controls; compare price points; select and schedule review
Example: The chosen price is not necessarily the highest accepted or the one with most customers. It is the tested point producing the best contribution for the current operating objective.
Any unexplained stockout, schedule change, rival event, or capacity shift prevents final attribution. Inspect reproducible total contribution with disclosed conditions before choosing the more expensive branch.
Record selected price, alternatives, cost, units, satisfaction, market state, capacity utilization, and next review trigger in BizMan. Use reproducible total contribution with disclosed conditions only when its controls remain comparable.
Optimization is periodic because the market state is dynamic. Confirm the current F1 requirement again after a relevant patch.
Try to disprove the working assumption before funding it. For Final pricing audit, hold reproducible total contribution with disclosed conditions steady while testing reconcile unit costs. If the predicted signal does not move, return to verify clean tests and record the contradiction instead of adding another purchase to save the theory.
The final sheet shows cost, tested prices, units, product contribution, satisfaction, capacity utilization, market context, and the next review trigger. Supplier-cost changes or rival entry reopen the decision automatically.
Action checklist
- Reconcile unit costs.
- Verify clean tests.
- Select by contribution.
- Document conditions.
- Set review triggers.
| Checkpoint | Evidence of a pass | Response to failure |
|---|---|---|
| reconcile unit costs | reproducible total contribution with disclosed conditions supports the intended condition under the recorded controls. | verify clean tests |
| select by contribution | selected price, alternatives, cost, units, satisfaction, market state, capacity utilization, and next review trigger is complete and the comparison has no unexplained outage. | document conditions |
| set review triggers | The downside is affordable and a review trigger is recorded. | Pause and repeat the smallest disputed test in final pricing audit. |
Research ledger
These links establish mechanics or provide a reproducible lead. Any balance-sensitive number still has to be checked in the current save.
Questions answered
What exact markup should I use in Build 3674?
No universal exact markup is verified. Begin near the live market reference, change one SKU gradually, and compare units, satisfaction, and total contribution across comparable operating periods.
Is 100 percent pricing satisfaction always optimal?
No official source says so. It is a useful acceptance signal, but the economic decision should compare completed volume multiplied by unit contribution, while accounting for capacity and broader satisfaction effects.
Should I always undercut the lowest rival?
No. Rival price is context, not the district's acceptance rule. Measure whether the rival actually reduces your units or contribution before sacrificing margin.
How does capacity affect pricing?
When completed customers repeatedly hit a verified structural ceiling, a modest price increase may add contribution without reducing served volume. Test off-peak periods too, and stop when completed volume or total contribution declines.
Does the 1.0 Pricing Manager guarantee optimal prices?
The official description says higher skill provides daily suggestions and the role can update prices across a neighborhood. It does not publish the algorithm or guarantee maximum profit, so audit suggestions against actual results.