Self-use worksheets
Store build decision pack
Turn a store requirement into comparable route evidence, explicit ownership and a cost model you can challenge.
Illustrative data, separate blank downloads.
Examples are fictional. They are not client results, live tests, quotations or product claims. Use the blank CSV files for your own records.
How to use this pack
- Start with one actor, trigger and observable result per requirement. Separate mandatory behavior from preferences before requesting proposals.
- Demonstrate the same representative task and its missing-data or failure state on the current theme, an app or a proposed custom route. Unknown is a decision state, not a pass.
- Compare only routes that address the same accepted scope. Keep open licensing, support and access obligations outside any numerical comparison.
- Enter your own quotes in one currency and term. Calculate support, recurring costs and term cost using the displayed recipes. Revisit the decision when a decisive assumption changes.
Import CSV as UTF-8 with comma delimiters. The blank files contain headers and five empty editable rows. Add rows as needed. Preserve stable IDs. Keep secrets, passwords, payment details and personal customer data out of these sheets.
CSV files contain values only and no executable formulas or macros. Calculated example values are static. After changing inputs, recompute the calculated columns using the recipes shown below. Blank means unknown, while zero means a confirmed zero. Formula-like text and negative numbers are prefixed with an apostrophe for safer spreadsheet imports; remove the apostrophe only from verified numeric inputs when you calculate. Your own later edits are outside the generated-file safety checks.
Requirements and acceptance
Define the work before choosing a route.
- Use stable requirement IDs across every sheet. Name the business task, protected behavior and acceptance owner.
- Record evidence that another reviewer can inspect. If evidence is missing, keep the state unknown and assign a next action.
Blank editable CSV: Requirements and acceptance (219 bytes)Illustrative completed CSV: Requirements and acceptance (647 bytes)
Field guide
- Requirement ID
- Stable ID referenced by comparisons and handover.
- Actor
- Shopper or staff role doing the task.
- Trigger and task
- Concrete input and conditions.
- Observable accepted result
- What a reviewer must see.
- Mandatory or optional
- Choose before demonstrations.
- Exception or failure state
- Missing input, unavailable product or alternate route.
- Evidence reference
- Permissioned internal reference, not secrets.
- Acceptance owner
- Role authorized to accept the behavior.
- Decision state
- Unknown, failed, demonstrated or accepted; keep these separate.
Illustrative data
Fictional teaching example only. Replace it with your own verified records in the separate blank sheet.
| Requirement ID | Actor | Trigger and task | Observable accepted result | Mandatory or optional | Exception or failure state | Evidence reference | Acceptance owner | Decision state |
|---|---|---|---|---|---|---|---|---|
| R-CARE-01 | Merchandiser | Edit care text for one product | Only that product displays the new text | Mandatory | Product without care shows no empty label | Fictional demonstration note E-01 | Content owner | Unknown: demonstration planned |
| R-PAIR-01 | Shopper | Choose an approved compatible accessory | Correct variant enters cart | Mandatory | No pairing and sold-out accessory | Fictional proposed case E-02 | Store owner | Unknown: no evidence |
Theme, app and custom route comparison
Keep proposal promises separate from observed fit.
- Add one row per route and requirement ID. Do not count a proposal description as demonstrated behavior.
- Identify the execution surface and data authority. A browser label does not prove an enforced transaction rule.
Blank editable CSV: Theme, app and custom route comparison (187 bytes)Illustrative completed CSV: Theme, app and custom route comparison (631 bytes)
Field guide
- Requirement ID
- Must match requirements sheet.
- Candidate route
- Current theme, theme plus code, app, custom app or headless.
- Data and execution surface
- Where the value lives and where behavior runs.
- Fit state
- Native demonstrated, code proposed, unsupported or unknown.
- Evidence and limits
- Exact observed scope; a design mockup is not a working trial.
- Editor task to prove
- Routine task the intended operator must perform.
- Unresolved gap
- What blocks this route.
- Next decision
- Smallest disproof or acceptance exercise.
Illustrative data
Fictional teaching example only. Replace it with your own verified records in the separate blank sheet.
| Requirement ID | Candidate route | Data and execution surface | Fit state | Evidence and limits | Editor task to prove | Unresolved gap | Next decision |
|---|---|---|---|---|---|---|---|
| R-CARE-01 | Current theme plus product data | Product care value and product template | Candidate; untested | Fictional candidate, no trial | Change one product care value | Empty state unproven | Demonstrate present and missing values |
| R-PAIR-01 | Theme plus bounded code | Merchant pairing map and cart input | Code proposed | Fictional scope only | Change an approved pairing | Mapping owner and unavailable variant | Specify acceptance before pricing |
Ownership and handover
Make ongoing operating responsibilities explicit.
- Enumerate source, configuration, licenses, store control and support separately. Do not store credentials here.
- Require a usable transfer exercise and name who can authorize changes or remove access.
Blank editable CSV: Ownership and handover (218 bytes)Illustrative completed CSV: Ownership and handover (705 bytes)
Field guide
- Asset or responsibility
- One bounded deliverable or ongoing responsibility.
- System or dependency
- Store, theme, app, source or content.
- Handover evidence
- What must be delivered and demonstrated.
- Merchant owner
- Role retaining control.
- Delivery or maintenance owner
- Named role in the actual engagement.
- Rights and license exception
- Record agreement reference, not assumed ownership.
- Acceptance exercise
- How usable handover is checked.
- Open action
- Do not bury a rights blocker in a score.
Illustrative data
Fictional teaching example only. Replace it with your own verified records in the separate blank sheet.
| Asset or responsibility | System or dependency | Handover evidence | Merchant owner | Delivery or maintenance owner | Rights and license exception | Acceptance exercise | Open action |
|---|---|---|---|---|---|---|---|
| Custom pairing section | Theme source and pairing data | Source, data map and change log | Store owner | Developer role | Fictional: terms not agreed | Another authorized maintainer locates and edits mapping | Agree custom-code rights and theme license |
| Support and recovery | Theme and app dependencies | Coverage, exclusions, escalation route | Operations owner | Support role | Fictional: no support contract | Walk one incident through authority and recovery | Confirm vendor-dependent fixes |
Comparable operating costs
Show the inputs behind the operating commitment.
- Use one row per route at the same scope, currency and term. Replace each fictional input with a dated quote.
- Support monthly equals support hours times rate. Recurring monthly includes platform, apps, hosting and support. Term total adds one-time cost to term recurring cost.
- These files are static values. After editing, recompute calculated columns and account for tax, volume fees and other exclusions separately.
Blank editable CSV: Comparable operating costs (322 bytes)Illustrative completed CSV: Comparable operating costs (404 bytes)
Field guide
- Route
- Candidate with accepted scope.
- Currency
- Do not add unlike currencies.
- Quote source and exclusions
- Date, term and excluded cost categories.
- One-time USD
- Build and migration amount, not monthly.
- Platform monthly USD
- Normalized monthly commitment.
- Apps monthly USD
- Non-overlapping recurring app charges.
- Hosting monthly USD
- Incremental hosting only.
- Support hours monthly
- Hours expected to be charged.
- Support hourly USD
- Agreed rate, not a benchmark.
- Support monthly USD
- Calculated hours times rate.
- Recurring monthly USD
- Calculated recurring sum.
- Term months
- Comparable commitment length.
- Term recurring USD
- Calculated monthly times term.
- Term total USD
- Calculated one-time plus term recurring.
Calculation recipes
- Support monthly USD = support hours monthly × support hourly USD.
- Recurring monthly USD = platform + apps + hosting + support monthly USD.
- Term recurring USD = recurring monthly USD × term months.
- Term total USD = one-time USD + term recurring USD.
Illustrative data
Fictional teaching example only. Replace it with your own verified records in the separate blank sheet.
| Route | Currency | Quote source and exclusions | One-time USD | Platform monthly USD | Apps monthly USD | Hosting monthly USD | Support hours monthly | Support hourly USD | Support monthly USD | Recurring monthly USD | Term months | Term recurring USD | Term total USD |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Fictional theme plus code | USD | Assumed inputs; tax and volume fees excluded | 4500 | 90 | 45 | 10 | 4 | 50 | 200 | 345 | 12 | 4140 | 8640 |
Monthly maintenance capacity
Normalize what a delivery bank actually buys.
- Enter whether calls and reporting consume the bank from actual terms. Reserve incident capacity explicitly.
- Planned delivery equals bank hours less call, reporting and incident reserve. A negative result signals over-allocation, not extra capacity.
Blank editable CSV: Monthly maintenance capacity (175 bytes)Illustrative completed CSV: Monthly maintenance capacity (344 bytes)
Field guide
- Offer
- Same work scope for comparison.
- Bank hours
- Total charged delivery bank.
- Call hours charged
- Zero only when outside the bank by agreement.
- Reporting hours charged
- Exclude only when terms say so.
- Incident reserve hours
- Merchant planning assumption.
- Planned delivery hours
- Bank less charged overhead and reserve.
- Overage and expiry terms
- Unknown remains unknown.
Calculation recipes
- Planned delivery hours = bank hours − call hours charged − reporting hours charged − incident reserve hours.
Illustrative data
Fictional teaching example only. Replace it with your own verified records in the separate blank sheet.
| Offer | Bank hours | Call hours charged | Reporting hours charged | Incident reserve hours | Planned delivery hours | Overage and expiry terms |
|---|---|---|---|---|---|---|
| Fictional offer A | 20 | 2 | 2 | 4 | 12 | Unknown; obtain written terms |
| Fictional offer B | 20 | 0 | 0 | 4 | 16 | Assumed outside-bank calls/reporting; other terms unknown |
Assumptions
- Every supplier, cost, hour and evidence label in the examples is fictional and chosen for arithmetic teaching. No quote or market benchmark is represented.
- The cost illustration uses USD, 12 months, constant monthly rates and no tax, payment-volume fees, inflation or discounting. Add excluded costs before making a real comparison.
- Blank cells mean unknown. Enter zero only when a source confirms no cost or no charged hours.
Known limits
- A lower total cannot overrule an unmet mandatory requirement. No platform eligibility or supplier capability is established here.
- CSV files hold values only. Calculated columns do not update automatically after editing. Recompute them with the documented recipes in your spreadsheet.
Source and method notes
- Approved growth program DESIGN: pack 1.
- Draft guides SC01, SC03, SC04, SC09, SC10, SC23 and SC24 inform the task, replacement, capacity and handover workflows.