Who This Helps
This workflow is for a solo developer or small team preparing a paid game, edition, or downloadable-content offer on Steam. It is especially useful when the team has a plausible price in mind but cannot yet explain the offer, the discount plan, or the regional-price review in a way a player can inspect before paying.
The Problem
A price is not only a number on a store page. Players also see the edition comparison, the timing and explanation of a discount, and whether important conditions are easy to find. When those pieces are assembled late, a team can accidentally make an ordinary offer feel arbitrary: a supporter edition has no clear contents, a promotion changes without a record, or the displayed urgency is stronger than the evidence behind it.
Steam's pricing documentation frames price setting as a developer decision that should account for the product, comparable games, regional purchasing power, and Steam's suggested conversion values. Its discount documentation adds product-specific rules that must be checked when a promotion is configured. The FTC's dark-pattern report is a useful boundary: do not use design that hides material information or creates misleading pressure. None of these sources supplies a universal price, a required discount percentage, or a revenue forecast.
Principle: Make the Offer Explainable
Use one reviewable basis for each product and region, then make the player-facing explanation match that basis. This is not personalized pricing and it is not a promise that transparency will improve sales. It is an operational method for keeping product scope, price changes, and promotion messages internally consistent.
A practical baseline has four parts:
- A short price rationale for the base game.
- A comparison table for every edition or add-on.
- A dated log for price and discount changes.
- A final store-page review focused on what a buyer can actually see.
Implementation
1. Write the base-price rationale before entering values
Create a one-page note with the intended product, its core playable scope, replay structure, comparable games, and the regions that need closer review. Treat Steam's regional suggestions as an input to review, not a substitute for product judgment. Keep the note factual: describe what ships at launch, what is optional, and what remains uncertain.
Use a small table so a teammate can challenge the decision without searching through chat history:
| Question | Evidence to record | Decision owner |
|---|---|---|
| What does the base game include? | Modes, content boundaries, and supported features | Product lead |
| Why is this the starting price? | Comparable scope, replay value, and current store positioning | Product and marketing |
| Which regions need a closer look? | Steam suggestions plus relevant local comparisons | Store owner |
| What cannot be promised? | Sales results, reception, or future discount outcomes | Product lead |
Do not turn the note into a hidden score for individual players. A buyer in the same product and regional condition should be able to understand the same listed offer. Taxes, currency presentation, and platform behavior can differ, but those are not a reason to invent opaque user-level prices.
2. Define editions by included content, not by pressure
An edition comparison should let a buyer answer two questions quickly: what is included, and what is optional? Place the answers in a stable table on the store page and in the release checklist.
| Offer | State clearly | Avoid |
|---|---|---|
| Base game | The complete core experience available at purchase | Implying normal play is intentionally impaired without an upgrade |
| Supporter edition | Exact non-essential extras such as a soundtrack or art book | Calling an item limited when no real limit exists |
| Downloadable content | The new, separately purchasable content and its dependencies | Vague labels that conceal what the buyer receives |
If the team cannot state the contents in one short row, the offer is not ready. Simplifying the edition may be safer than adding marketing language to compensate for an unclear bundle.
3. Plan discounts as dated changes
Before configuring a discount, write a promotion card containing the base price, proposed discount, start and end time, affected packages, reason for the campaign, and the Steam documentation page checked on that date. Steam's discount rules can change and may vary by promotion context, so the person submitting the promotion should verify the current requirements directly in Steamworks rather than relying on a past spreadsheet.
The card is also a guard against accidental price theater. Do not raise a price immediately before a sale merely to make the promotion look larger. Do not display a countdown unless its end time is known and displayed accurately. If a promotion changes, update the public explanation and leave a dated internal record of what changed.
4. Review the buyer-facing path
Open the store preview on desktop and mobile. Ask a reviewer who did not write the copy to locate the price, edition differences, discount end time, and any conditions for add-on content. The reviewer should be able to repeat the offer in plain language without interpreting ambiguous labels.
Use this acceptance test:
- The base offer is visible without opening an unrelated page.
- Every paid extra has a named inclusion or exclusion.
- The displayed promotion has an accurate time boundary.
- No message claims scarcity, activity, or a price benefit that the team cannot verify.
- Store copy and the internal promotion card agree.
Tradeoffs
A transparent workflow costs time. Someone must maintain the comparison table, review regional context, and record each change. It may also reduce the number of offer variants a small team can manage. That cost is often preferable to maintaining a complex bundle structure that no one can explain consistently.
The method does not eliminate hard pricing decisions. Comparable games can change, regional context is not uniform, and a new product may have little direct evidence. In those cases, record the uncertainty and choose a revision point rather than treating an assumption as proof.
Failure Modes
Using a price note as a forecast
A rationale explains a decision; it does not predict demand. Avoid language such as "this price will maximize conversion" or "this discount will recover a target number of sales." Track the result as an observation that may be affected by visibility, reviews, release timing, and other changes.
Letting editions hide the real choice
A long feature list can obscure whether the base game is a complete product. Put essential gameplay information in the base-game row and reserve optional extras for clearly labeled offers.
Treating old promotion rules as current
Saved notes are not a replacement for the current Steamworks documentation. Re-check the relevant pricing and discount pages before submitting a change, and record the review date.
Creating urgency without a verifiable basis
The FTC report describes deceptive patterns that can distort consumer choice, including misleading scarcity and hidden information. Use only claims the team can substantiate, and make important conditions visible where the buyer makes the decision.
Testing
Test the workflow at three moments: before launch, before every discount, and after a price or package change.
- Have two people independently read the rationale and edition table. Compare what they believe each offer includes.
- Inspect the Steam preview at common desktop and mobile widths. Confirm that price, included content, and promotion timing remain readable.
- Before a promotion, re-open the official Steam pricing and discount pages and verify that the planned setup still follows the applicable rules.
- After a change, log the date, public copy, store configuration, and contextual events such as a festival or major update.
- Review player questions, refund reasons, and support tickets alongside sales data. Label conclusions as observations unless the project has a method that supports a stronger claim.
Production Considerations
Assign one owner for the store configuration and one reviewer for player-facing copy. Keep the rationale, edition matrix, and promotion cards in a lightweight folder that survives handoffs. A spreadsheet is sufficient if it records the source of each change and avoids mixing internal guesses with confirmed store values.
Use a change log entry whenever the base price, package contents, or promotion window changes. The entry should capture the date, region or package affected, requester, reviewer, public copy location, and the official documentation rechecked. This record makes a later correction easier: the team can identify what changed before assuming that a player complaint is caused by the game itself.
For a small launch, begin with one clearly described base game. Add a supporter edition or downloadable content only when its contents, delivery plan, and support burden are concrete. More offers are not automatically more choice when the comparison is difficult to understand.
Checklist
- [ ] The base-game price has a written scope and comparison rationale.
- [ ] Each edition lists included and excluded content in player-readable language.
- [ ] The team has reviewed current Steam pricing guidance for the intended configuration.
- [ ] The team has reviewed current Steam discount guidance before each promotion.
- [ ] Promotion dates and discount claims match the configured store offer.
- [ ] No copy relies on unsupported scarcity, hidden fees, or unclear conditions.
- [ ] Desktop and mobile previews communicate the same offer.
- [ ] Post-change notes distinguish observations from causal claims.