When costs rise, should you hold prices, raise them or run a promotion?

When costs rise, a business has more than one possible response. It can hold prices to protect customer demand, raise prices to strengthen its financial position, or move in the opposite direction with a promotion. Each choice offers something and gives something up.

In this article

• Try the Pricing Decision Lab and Interactive Quiz in the working English app embedded below.

• Explore Olay’s pricing example in Playing to Win, pages 13–15 to question assumptions about price and customer response.

• See how Base44, Snowflake and CoCo fit together, with a Business Play architecture diagram and an inventory application.

• Open Power Ladder’s real business case study for the context of a purchasing decision that considers sales, stock and cash together.

For a CEO, the question is which opportunity is worth the risk. For a CTO, the next question is how to make the comparison traceable, repeatable and clear enough to explain why a proposed option changes.

In my own business, Belly Thailand, I first compare our selling price with close competitors. Before I feel confident about raising it, I want evidence that customers see our product or service as superior or meaningfully different. I use that check to judge whether a higher price has a credible basis.

I want Business Play to put these choices in front of executives together: what each option gains, what it sacrifices, and which conditions would make us reconsider it before taking action.

About this demonstrationThe public app runs on Base44 and calls a Base44 backend function using synthetic data. No login is required. Connecting it to Snowflake and applying the design to Belly Thailand’s Inventory Management project are development steps described separately below.

Figure 1 · Business Play imagery for the starting scenario. Select an image to enlarge it.

PLAYING TO WIN · PAGES 13–15

A higher price can change both profit and what a product means to customers

On page 13 of Playing to Win, A.G. Lafley and Roger L. Martin describe Olay testing prices of $12.99, $15.99 and $18.99. Purchase intent fell at $15.99, then rose at $18.99.

The explanation connects price with customer segments and perceived value. For shoppers accustomed to prestige products, $18.99 could still look like good value. The middle price sat awkwardly between two groups. These were purchase-intent findings from testing, rather than actual sales measured at each price. [Playing to Win, p. 13]

This matters when framing a Business Play. We should test the assumption that raising prices always weakens competitive advantage. The effect depends on whom the business serves, what value it delivers and how customers interpret the price.

That is why I start with comparable competitors and customer evidence. The price comparison needs products and services customers actually see as alternatives. A stronger margin in a spreadsheet does not, by itself, show that customers will accept the new price.

The five connected questions on pages 14–15 help establish the strategic context. Here is how I apply them to this pricing comparison:

These choices reinforce and influence one another. New evidence may require us to revisit our assumptions, our way of competing or the customers we choose to serve. [p. 14] [p. 15]

Read the three alternatives through Business Play

Hold prices: Stone Dinosaur. This makes the benefit of preserving the current price visible alongside the cost of standing still when conditions call for adaptation. Customers may continue to buy at the same price while the profit and cash remaining in the business shrink.

Raise prices: Super Camel. This explores stronger Financial Fuel together with the effect on Competitive Edge. In our starting scenario, we test a modest fall in sales volume against a larger improvement in profit and cash.

Run a promotion: Unicorn Bleed. This highlights the risk of growing sales by sacrificing margin. If the extra volume does not compensate for the reduction in margin, the business can sell more and retain less cash.

The names describe the starting scenario. Holding prices can be the appropriate choice when evidence supports it. A promotion that pays off need not represent Unicorn Bleed. The comparison and its reasoning must explain the choice.

Use one baseline, then compare the consequences

The Pricing Decision Lab uses one fictional product group over one month:

• Baseline volume: 1,000 units at THB 1,000 each.

• Variable cost rises from THB 650 to THB 750 per unit.

• Fixed operating costs: THB 150,000.

• Opening cash: THB 400,000, with 85% of sales collected during the period.

• Minimum closing-cash requirement: THB 250,000.

Initially, an 8% price increase retains 95% of baseline volume. A 5% discount generates 115% of baseline volume. These are editable assumptions, not demand forecasts.

All monetary values are THB. All inputs and results are illustrative. Scroll the table horizontally on smaller screens.

The promotion produces the highest revenue, but lower operating profit and closing cash than holding prices. Raising prices produces a stronger financial result despite the assumed reduction in volume.

The raise-price calculation is easy to inspect:

Closing cash equals opening cash plus sales collected, less variable costs and fixed operating costs assumed paid within the same period. This simplified model excludes inventory-purchasing timing, opening receivables and payables, taxes, interest and other cash movements. A business cash forecast would need those details.

The learning rule selects the highest-profit option among those with non-negative operating profit and cash above or equal to the minimum as a candidate for review. The app withholds a candidate when inputs are incomplete, the leading options tie, or no option satisfies the conditions.

Find out when the proposed choice changes

Choose Demand falls further. Retained volume after the price increase falls from 95% to 75%. Operating profit for that option becomes THB 97,500, below the THB 100,000 produced by holding prices. Under these assumptions, holding the price becomes the candidate.

Next, select Slower collections. The share of sales collected in the period falls from 85% to 65%. Operating profit for the raise-price option stays the same, but closing cash falls to THB 204,400. Every option now falls below the THB 250,000 cash floor, so the app withholds a candidate.

Finally, try Promotion pays off. With a 2% discount and volume at 145% of baseline, the promotion produces operating profit of THB 183,500 and closing cash of THB 370,350. It becomes the candidate for review.

My competitor-price and customer-perception checks sit outside this demo. The app does not collect or validate that evidence. They are inputs to the business judgement that should inform the assumptions we test.

These demand values are assumptions you control. In a real implementation, the team could use market experiments, reviewed ranges or a validated model, depending on the available evidence. The point is to know which assumptions we are accepting and which changes should trigger another decision.

ACTUAL BASE44 APP CAPTURES · SELECT TO ENLARGE

DEMO D1 · ACTUAL BASE44 CAPTURE · Compare all three alternatives · The starting scenario shows profit, cash and volume for each option. · Synthetic data · Snowflake not connected

DEMO D2 · ACTUAL BASE44 CAPTURE · Trace the result to its request · Data & evidence shows the DEMO run ID, versions and execution trace. No Snowflake query was executed. · Synthetic data · Snowflake not connected

DEMO D3 · ACTUAL BASE44 CAPTURE · When holding prices becomes the candidate · Retained volume after a price increase falls to 75% of baseline. · Synthetic data · Snowflake not connected

DEMO D4 · ACTUAL BASE44 CAPTURE · When every option fails the cash floor · Collecting only 65% of sales leaves every option below the minimum cash requirement. · Synthetic data · Snowflake not connected

DEMO D5 · ACTUAL BASE44 CAPTURE · When the promotion pays off · A 2% discount with volume at 145% of baseline changes the candidate. · Synthetic data · Snowflake not connected

DEMO D6 · ACTUAL BASE44 CAPTURE · Choose an option and inspect the reasoning · The same Interactive Quiz explains the implications of the selected alternative. · Synthetic data · Snowflake not connected

BASE44 + SNOWFLAKE + COCO

Separate the interface from the calculation service

A web app can reproduce the demo’s cards, sliders, charts and Quiz. The backend accepts assumptions, performs the comparison and returns results. This lets a team change the calculation provider while preserving the way executives explore their alternatives.

Base44 supports custom interface code. Teams wanting to run the web app within Snowflake can also consider Snowflake App Runtime for Node.js/Next.js; its standard access route uses Snowflake authentication. A public, no-login reading experience and an internal business application therefore need distinct access designs. [Base44 developer tools] [Snowflake App Runtime]

The interface and interactions can be implemented to match the design. Exact behaviour still needs device testing and allowance for network latency when calculations call a remote backend.

In this working demo, changing an assumption calls the Base44 function compare-pricing. It validates the input types and ranges, selects the specified synthetic snapshot, evaluates all three alternatives and returns JSON with status, reasons, versions and an execution trace. The numerical results come from calculation rules.

A DEMO-… run ID traces a request through this demo service. Data & evidence explicitly identifies BASE44_FUNCTION_SIMULATION and shows that no Snowflake query ID exists.

Base44 offers a Snowflake connector using OAuth to query Snowflake data. For a dedicated comparison service, the backend can use the Snowflake SQL API to call a versioned stored procedure and map its response into the interface’s JSON contract. [Base44 Snowflake connector] [SQL API and stored procedures]

Public readers need not log in to a synthetic demo, but a backend calling Snowflake still needs an authorised identity and role. Tokens and secrets stay on the server; the browser receives only permitted results. A real Belly Inventory application needs its own user access, data scope and usage limits. [Base44 Functions SDK]

Figure 2 · Solid connections show the working demo. Dashed connections show development still required. Select to enlarge.

Use AI where it helps the decision

A Semantic View defines business meaning, metrics and relationships. Cortex Analyst can use that context to generate SQL from natural-language questions. The team still needs to validate definitions and results against trusted reports: does net price include discounts and returns, and do joins duplicate sales? [Semantic Views] [Cortex Analyst]

Business Play comparison logic belongs in a tool the team can test and version. A conversational Cortex Agent can call custom tools backed by stored procedures or UDFs and explain the returned results. [Cortex Agents and custom tools]

CoCo, or Cortex Code, can help teams develop and review code. Snowflake also provides a Coding Agent that exposes CoCo capabilities to external applications through the Cortex Agents REST API, with a Snowflake-managed sandbox. This creates an optional route for exploration and tasks requiring several tools, subject to the intended permissions and use case. [Snowflake Coding Agent]

For a repeatable pricing comparison, I would use a versioned Business Play calculation tool as the source of the numbers. An Agent could then help users ask follow-up questions, explore data or understand the result. CoCo remains a development path here, rather than an enabled capability of this demo.

Each request should identify the product scope, decision period, baseline dataset, assumption version and rule version. All alternatives must use the same reproducible baseline. Naming something snapshot_id does not make the referenced data immutable.

The response should include every alternative, its assumptions, passed and failed conditions, and why a candidate was selected or withheld. Reviewers can then distinguish a data change from an assumption change or a rule change.

In production, results sent from Snowflake to Base44 and the browser leave Snowflake as part of the design. Teams must decide which results may be shown and how access, logging and usage are controlled.

BELLY THAILAND · INVENTORY MANAGEMENT

Apply the structure to an inventory decision

Belly Thailand supplies tents to hotel and resort operators. Its purchasing decisions connect sales opportunities, available stock and the cash required to fulfil them. This business context appears in Power Ladder’s case study.

An inventory implementation could compare replenishing to plan, replenishing only priority SKUs or delaying replenishment. Each option should expose its sales opportunity, cash commitment and accepted risk, using alternatives defined with the team and supported by the actual system.

The Inventory Management project needs its own reconciled stock baseline, metric definitions and cash-flow model. The public pricing app demonstrates a method using synthetic data; it does not establish that the new Inventory system is connected or running on Snowflake.

For me, Business Play is valuable when executives can see the reasoning behind their options, understand what they are trading away and revisit a decision when conditions change. Snowflake can bring the data, definitions and calculation tools together. Experts and executives own the criteria and the decision.

If one important assumption changed, would you know whether the action your business is about to take still makes sense?

References and book pages

A.G. Lafley and Roger L. Martin (2013). Playing to Win: How Strategy Really Works. Harvard Business Review Press, chapter 1, pages 13–15 in the supplied edition. The reference photographs below were provided by the author. Select to enlarge.

Page 13 · Olay and price testing

Page 14 · Strategy and choices

Page 15 · Capabilities and management systems

Technical references are linked alongside the relevant claims. They were checked for the source article on 30 October 2026. The article’s use of explanatory screenshots was inspired by phData’s SAP, Snowflake Cortex and Semantic Views article; the decision scenario, writing and demonstration here belong to Power Ladder.