Steam Pre-Release Review Buffer Worksheet Before You Announce Launch - 2026

If you searched steam review buffer worksheet after Valve’s November backlog note, you do not need another argument about whether Friday is realistic. You need a form. Fill it before anyone announces a consumer day.

The Steamworks update says build review is running behind at up to 12 business days, with re-reviews as a major cause. Standing Review Process language still describes a typical 3–5 day aim and a longer planning buffer. Separately, Coming Soon requires a public Coming Soon page for at least two weeks before a new product releases, and asks you to submit that page for review at least 7 business days before you want it live. Release dates and release options lock changes once you are inside 14 days of the date customers are about to see. Those clocks stack. A tweet does not.

This worksheet is the fill-in. The what-changed map explains the policy. The 3–5 day Stop refuses folklore. The twelve checks decide whether Mark as ready is honest. This URL decides whether the date you say out loud survives those rules. It is not a Winter Sale discount lock.

Why this matters now

Studios missed Early Access and full launches while review sat in a multi-week queue. The Verge reported that pattern, and Valve answered with a backlog number plus a first-pass checklist. The painful part for marketing is not the checklist. It is announcing a day that the Coming Soon lock and the build queue cannot both honor.

Direct answer: Pick the release day last, or pick it only after this sheet shows every earlier gate landing on a real weekday. Plan build review at 12 business days that end before release day. Put Coming Soon up at least 14 calendar days before release, and earlier if you want wishlists. Submit the store page at least 7 business days before that Coming Soon post. Do not announce a hard day inside the 14-day lock. Attach a green review-check scorecard before you treat the build clock as started.

Who fills the sheet

Time: 45–90 minutes the first time, including the worked count. Updates after a slip take 15 minutes if you only move one date.
Honest limit: Steamworks docs win if this sheet drifts. “Up to 12 business days” is Valve’s current backlog line, not a forever statute. Holidays and adult-content review can run longer. A second review after a fail is a studio contingency on this sheet, not a second number Valve published. First-time Steam Direct fees add a 21-day wait on your first few titles (onboarding). Skip that row when it does not apply.

Non-repetition

Clocks you are allowed to use

Write these on the sheet. Do not replace them with a single “Steam takes a week” cell.

Business days here mean Monday–Friday. Valve holidays are extra. If a counted day is a holiday you already know Valve observes, skip it and write HOLIDAY in the note column. Do not invent a holiday to make the math prettier.

The release day is not one of the 12 review days. The 12th business day should fall on the weekday before you intend to press release, and you still need the build to show approved before that press. If approval lands on release morning, you already missed a calm launch.

How to count without a spreadsheet

1. Write RELEASE_DATE on a weekday you are willing to be awake.
2. Step backward one weekday at a time. Do not count Saturday or Sunday.
3. Stop at 12. That date is BUILD_REVIEW_END.
4. The weekday before BUILD_REVIEW_END is the last sane BUILD_MARK_READY. Earlier is better.
5. Subtract 14 calendar days from RELEASE_DATE. That date is COMING_SOON_MINIMUM. The page must already be public on or before it.
6. From the day you actually want Coming Soon public, step back 7 weekdays. That date is the last sane STORE_SUBMIT. Earlier is better. The November backlog can make store review slower than the 7-day line. Treat 7 as the doc floor, not a promise.
7. If this is one of your first titles, write FEE_DATE. FEE_DATE + 21 calendar days must be on or before RELEASE_DATE.
8. Write DATE_LOCK as RELEASE_DATE minus 14 calendar days. Do not announce a hard day if you still need the right to move it after DATE_LOCK.

Public display format is a separate field. Release dates lets you show an exact day, a month, a quarter, a year, or no date. The backend still stores an exact intended day. Customers and the lock care about what you set. Pick the display before you tweet.

Worked example — release Friday 26 February 2027

This is a teaching calendar, not a prediction that your review will finish on these days. The weekdays below match the 2027 civil calendar.

Count check for the build clock, starting the day after Tuesday 9 February:

Friday 26 February is release, not a 13th review day. If you instead Mark ready on Monday 22 February because “docs say 3–5 days,” you have three business days before release (23, 24, 25). That is the folklore the Stop refuses. The sheet fails closed: ANNOUNCE_OK stays blank.

Store count, seven weekdays before Friday 15 January, not counting the 15th: Thu 14, Wed 13, Tue 12, Mon 11, Fri 8, Thu 7, Wed 6. The last sane store submit is Wednesday 6 January. Submitting on Thursday 14 January for a Friday 15 January post is one business day, not seven.

Coming Soon on Friday 12 February meets the two-week minimum and lands on the date lock. You would go public and lose a self-serve date change in the same breath. The example therefore posts Coming Soon on Friday 15 January, while the build still waits until 9 February. Wishlist time and review time are different clocks. Do not spend the wishlist clock as if it were review slack.

Blank worksheet

Copy this block into the launch ticket. One app, one release, one owner. Replace the blanks. Leave a field blank rather than writing “TBD Friday.”

A — Identity

Early Access still needs the Coming Soon two weeks before the product is playable (release options). Do not skip section C because the button says Early Access.

B — The day you hope to release

If the public display is “Q1 2027” or “Coming Soon,” you may still owe Valve an exact backend day. Write both. The tweet follows the display, not an internal Friday you hoped to keep secret and then leaked.

C — Coming Soon and store lead

ANNOUNCE_OK requires store state LIVE for a hard date, or an explicit window sentence that does not name a day. A draft capsule is not a launch announcement.

D — Build review buffer

If the scorecard is BLOCKED, the build clock has not started. Do not write a BUILD_MARK_READY in the past for a build you have not submitted. Link the checks listicle in the ticket so the attachment is the pass/fail card, not a second copy of those twelve rows.

E — Contingency and lock

If “need to change the day” is YES, move RELEASE_DATE earlier in the process, while you still can, or switch the public display to a month or quarter. Do not plan on Valve making an exception. The docs say you contact them. That is not the same as a self-serve edit.

F — Announce receipt

ANNOUNCE_OK only when every gate is PASS. Otherwise the status is WINDOW_HOLD or SILENT.

Sentences you can paste

Use one. Do not mix them.

The DAY_NAMED row is the only one allowed to contain a consumer weekday. It is allowed only after section F is all PASS. Influencer embargoes can key off approval mail. They cannot key off “we usually clear in 3–5 days.”

Where people cheat the sheet

A re-review is not a moral failure. It is a second 12-business-day planning block on this sheet because Valve said re-reviews are why the queue is long. If you want a day you can say even if the first build fails, RELEASE_DATE has to sit after both blocks. That is section E. Teams who only schedule the happy path will spend the lock window writing apology posts. The Verge already collected that genre.

Monday session (ninety minutes)

Block a calendar hold. Bring the landing page, not a trailer.

1. Write section A. If you do not know the app ID, stop. You are not ready to announce.
2. Propose a RELEASE_DATE on a weekday. Say it out loud once.
3. Count 12 business days with another person watching. Disagreeing by one day means you recount. Write BUILD_REVIEW_END and BUILD_MARK_READY.
4. Subtract 14 calendar days. Write COMING_SOON_MINIMUM and DATE_LOCK.
5. Pick a Coming Soon post that is before the minimum and before the lock by weeks, not hours. Count 7 business days back for STORE_SUBMIT.
6. Open Coming Soon and Release dates beside the sheet. If a row feels clever, the doc wins.
7. Attach the review scorecard. If it is missing, section D stays BLOCKED and section F cannot pass. Build the scorecard from the checks listicle. Engine packaging questions belong in guides, not in this date math.
8. Choose a sentence from the table. Paste it where the team announces — a real Discord listed in the 25 Discords resource, a press mail, or nowhere.
9. Initial section F. If any gate fails, the status is WINDOW_HOLD. Do not “soft launch” the day in a screenshot of a calendar invite.

If step 3 cannot find 12 weekdays before a date marketing already printed on a key, the key is wrong. Move the date or pull the key. The sheet does not have a row for “the trailer house already exported.”

Company diligence

Put the filled sheet in the launch zip next to the scorecard.

• Clocks separated: store 7, Coming Soon 14 calendar days, build 12 business days, lock 14 calendar days, fee 21 only when it applies.
• BUILD_ID and branch, or an explicit BLOCKED.
• The public sentence and the display format on the same page.
• A named owner. A channel name is not an owner.
• No slide that says only “Steam review: 3–5 days.”

If a contract requires a day inside one week of submit, the contract fights the backlog FAQ. Renegotiate the day or add a slip clause. Do not hide the fight inside a green ANNOUNCE_OK. Publishers can read Release Process in the same sitting. Store approval and build approval are both required before release. This sheet times them. It does not merge them.

What ANNOUNCE_OK is not

When the build is approved and Coming Soon has been up for two weeks, you still press release yourself. Steam does not owe you the button on RELEASE_DATE morning if you missed a clock. The sheet’s job is to keep that morning from being the first time you do the arithmetic.

Key takeaways

• A steam review buffer worksheet is a filled stack of clocks, not a vibe that review “usually” takes a few days.
• Plan the build at 12 business days that finish before release day (Steamworks announcement).
• Coming Soon must be public at least two weeks before release. Submit that page at least 7 business days before you want it live.
• Inside 14 days of the set date, you do not get a free edit. Set the day only when you mean it.
• First titles add 21 days after the Steam Direct fee. Everyone else writes N/A.
• The twelve checks start the build clock. A red card means the clock has not started.
• The 3–5 day Stop is the refusal. This page is the form that replaces the refused calendar.
• Public display format and the backend day are both fields. Tweets follow the display.
• A second 12-day block is your contingency if the first build fails. Valve did not publish a shorter retry SLA.
• ANNOUNCE_OK needs every gate in section F. Anything else is WINDOW_HOLD or SILENT.
• Holidays stretch the count. Add them in the note column instead of hoping Friday absorbs them.
• Seasonal sales use a different sheet. Do not borrow a discount deadline as a release day.

FAQ

What is a Steam review buffer worksheet?

It is a one-app form that places your release day after the clocks Steam actually publishes: up to 12 business days for the current build-review backlog, at least two weeks of Coming Soon, at least 7 business days of store-page lead, and a 14-day lock on date changes. You fill dates, a build ID, and a sentence. You do not fill a single “review takes X” cell.

How many business days should we put between Mark as ready and release?

Use 12 weekdays that end the weekday before release, until Valve changes the backlog line. The older 3–5 day aim is still in Review Process as a typical target. It is the wrong number for a promise while the FAQ says the queue is behind.

Does the two-week Coming Soon rule use business days?

No. Coming Soon says the page must be up for at least two weeks before release. Count 14 calendar days. The 7 business days figure is how early you should submit the page for review before you want it to go live, not a substitute for the two weeks.

When does Steam stop letting us change the release date?

Release dates says you can change the date up to two weeks prior. Once you are inside that window, upcoming-release visibility starts and you can no longer adjust it yourself. Release options says the same once Coming Soon is live and the date is within 14 days: contact Valve, do not assume a self-serve move.

Can we announce “next Friday” if Coming Soon is already live?

Only if section F passes for that Friday, including a build submitted early enough for 12 business days and a date you are allowed to show. A live page is one gate. It is not the build buffer and it is not the lock.

What if this is our first game on Steam?

Add the fee row. Onboarding requires 21 days between paying the app fee and release on your first few titles, plus the Coming Soon two weeks. If either clock misses RELEASE_DATE, move the day.

The build failed review. Do we keep the same announce day?

Only if section E’s second 12-business-day block still finishes before RELEASE_DATE and you are not inside DATE_LOCK. Otherwise change the display while you still can, or go back to WINDOW_HOLD. Do not tweet “still Friday” on a failed build.

Where do the twelve technical checks go?

On the checks listicle, attached as MARK_READY_OK or BLOCKED. This worksheet does not retest achievements, Cloud, or screenshots. It only refuses to start the calendar without that card.

Conclusion

Announce the day after the sheet is boring. Boring means every clock has a weekday, the Coming Soon post is early enough to matter, the build ID exists, the scorecard is green, and the sentence matches the display format you set in Steamworks.

If the sheet is exciting — a Friday three days after upload, a lock date that is also your Coming Soon date, a blank build ID — you are about to publish the kind of miss Valve and the press already described. Fill section F. If it is not ANNOUNCE_OK, say the window sentence or say nothing.

Keep Coming Soon, Release dates, and the November backlog note open while you write the numbers. The form is only as honest as those pages.