From deal intake to promotion QA, check by check

A promotion can carry the wrong price, date, or product detail from a deal sheet into a menu build. I built this portfolio example to show how I would check those inputs, explain the decision, and make the next action clear. Every record here is fictional.

The workflow runs from intake and normalization through validation, review, approval, build, final QA, publishing handoff, and weekly reporting. I call it my Deals Operating System. Normalization makes offers comparable; review assigns decisions; the later gates check readiness. The workbook implements the checks. The workflow board is a blueprint, and a production version would separate pre-build approval from final channel checks.

The submitting team enters the product, offer, stores, dates, prices, funding, and readiness information here. Eleven fields are mandatory, including the SKU, both prices, and the customer limit. Submitted values stay visible separately from the reference tables. The submitter owns the initial information; QA returns the status and issue detail. This preserves the comparison, although a production process would also need a submission history.

C1 checks completeness so the builder does not guess. C2 confirms the SKU exists. C3 compares the product, brand, and category with the master. Missing required information, an unknown SKU, or mismatched descriptors stops the deal.

C4, Reg Price Match, checks the starting price for the offer against the reference. C5, Promo Price Math, recalculates the ending price from the offer type and discount. The current workbook handles offer quantity through Units in Offer. A mismatch beyond the displayed tolerance fails.

C6 compares the discount with the sample category cap; near the cap warns, beyond its tolerance fails. C7 checks the margin floor in the same way, with a warning band above the floor. C8 confirms that the vendor agreement exists, matches the brand, and covers the dates. C9 checks the vendor discount ceiling. These checks keep the proposed offer consistent with its stated commercial terms.

C10 rejects missing, reversed, or overlong date windows and warns on short lead time. C11 looks for an earlier submission with the same SKU, overlapping dates, and matching store scope. It has limits with partly overlapping store lists. C12 checks each entered store code against the master. These checks clarify when and where the offer applies.

C13 compares sample inventory with projected demand: insufficient coverage fails or warns. C14 reads the entered channel-status flags; it does not inspect live menus. C15 reads copy approval and image readiness. C16 checks sample wording, purchase-limit, and stacking rules. These are prototype policies, not a legal compliance certification. A failure blocks the row; warnings without failures require review. Not-applicable results remain separate from passes.

D-1009 requests thirty-five percent off. Its submitted regular price is thirty-nine ninety-nine, but the reference price is thirty-four ninety-nine. The expected promo price is twenty-two seventy-four; the submission says twenty-five ninety-nine. C4 and C5 fail, and Marketing Ops plus Pricing own the correction. Publishing unchanged would advertise inconsistent price and discount information. In this recording copy, I correct both prices and rerun the checks. The two failures clear, but the deal now needs review because it reaches the category-cap warning band. Correct math does not replace the remaining decision.

D-1001 is the clean comparison. Its thirty-four ninety-nine regular price and twenty-five percent offer produce twenty-six twenty-four. Every check passes. The result reads Approved, and the next-action field names Marketing Ops. Those are sample readiness confirmations already entered in the workbook. The operational next step would be to confirm the approved details against the build and complete the publishing handoff.

D-1014 has no hard errors, but inventory is below the sample demand estimate and a channel update is incomplete. Marketing Ops must coordinate the stock decision and the menu update. I would document the reviewer, decision, date, and remaining action in the proposed approval record. That record is part of the workflow design; the workbook itself does not store an approval history or turn a warning green just because someone reviewed it.

The reporting tab brings together the sample status totals, issues by check, and submitting-team breakdowns. A manager can identify repeated issues and use the deal ID to reach the owner in the validation engine. These are current sample results. The monetary exposure figures are modeled examples, not savings I delivered, and this workbook does not establish a historical improvement in first-pass accuracy.

Building this demonstrates how I organize product information, validate pricing, communicate exceptions, and make ownership clear.