# Phase 0 Pre-Flight Readiness Checklist **Spec:** 050 — Everee Payroll Foundations **Document type:** CS-OWNED OPERATIONAL CHECKLIST **Version:** 1.0 (scaffold — items pending human action) **Created:** 2026-05-29 **Last updated:** 2026-05-29 --- > **IMPORTANT — Who owns this document:** > This is a **Customer Success-owned** operational checklist. Engineering's only blocking > responsibility is the "Engineering Review" section at the bottom. Every other item is > owned by a named CS or operations person and requires **human action** outside the > codebase. Engineering cannot tick CS-owned boxes on behalf of CS. > > **Hard gate:** Phase 1a does not start until each checklist item below is either > ticked as DONE or explicitly waived with a documented reason. Waiving a Must-Have item > requires Tech Lead + CS Lead sign-off. --- ## Status Legend | Symbol | Meaning | |--------|---------| | `[ ]` | PENDING HUMAN ACTION | | `[x]` | DONE | | `[~]` | WAIVED — reason documented in item notes | --- ## Item 1 — Pilot-Store Rate-Data Audit **Status:** PENDING HUMAN ACTION **OWNER:** `` **Ref:** PRD F13 AC 1; SDD Deliverable 3; Analysis §14 item 1 ### Checklist - [ ] **1.1** Rate-data spreadsheet / CSV created in a CS-accessible location (Google Drive, Notion, etc.) **Link placeholder:** `[INSERT LINK TO RATE AUDIT SPREADSHEET HERE]` - [ ] **1.2** Store 1 — per-employee, per-position current pay rates captured **Store typeNum:** `` **Rate-source story:** `>` **Completed by:** `` on `` - [ ] **1.3** Store 2 — per-employee, per-position current pay rates captured **Store typeNum:** `` **Rate-source story:** `>` **Completed by:** `` on `` - [ ] **1.4** Store 3 — per-employee, per-position current pay rates captured **Store typeNum:** `` **Rate-source story:** `>` **Completed by:** `` on `` - [ ] **1.5** Store 4 — per-employee, per-position current pay rates captured **Store typeNum:** `` **Rate-source story:** `>` **Completed by:** `` on `` - [ ] **1.6** Store 5 — per-employee, per-position current pay rates captured **Store typeNum:** `` **Rate-source story:** `>` **Completed by:** `` on `` ### Notes For any store that cannot supply rate data before Phase 1a kickoff, document an explicit waiver here: | Store typeNum | Waiver reason | Waiver approved by | Date | |--------------|---------------|-------------------|------| | | | | | **Item 1 status note:** This item cannot be marked DONE by engineering. CS must collect CSVs or document waivers, then update this file (or the linked spreadsheet) and confirm completion to the engineering Tech Lead before the Phase 1a kick-off meeting. --- ## Item 2 — Partner-Manager Kickoff Email **Status:** PENDING HUMAN ACTION **OWNER:** `` **Ref:** PRD F13 AC 2; SDD Deliverable 3; Analysis §13 (full question stack); Analysis §15 action item 1 ### Checklist - [ ] **2.1** Kickoff email sent to Everee partner manager **Sent date:** `` **Sent by:** `` **Email thread / shared inbox link:** `[INSERT LINK TO EMAIL THREAD HERE]` - [ ] **2.2** Shared thread is accessible to at least CS Lead + Tech Lead - [ ] **2.3** Weekly status update on thread (until at minimum sandbox credentials + HMAC algorithm confirmed) **Current status of blocking items:** - Sandbox credentials: `` - HMAC algorithm confirmed: `` - [ ] **2.4** All 20 partner questions acknowledged (non-blocking confirmations can trail) ### Status History (update weekly) | Date | Update | Updated by | |------|--------|-----------| | | | | ### Notes The draft email to send is in **Appendix A** below. CS only needs to personalize the greeting, add the account executive name, and hit Send. All questions come directly from the analysis document (§13). --- ## Item 3 — Finalized Pilot Candidate List **Status:** PENDING HUMAN ACTION **OWNER:** `` **Ref:** PRD F13 AC 3; SDD Deliverable 3; Analysis §11 (pilot criteria) ### Pilot Selection Criteria (from Analysis §11) - Existing happy customer (NPS ≥ 8 or equivalent positive signal) - Single-state preferred (multi-state is supported architecturally but adds compliance complexity for pilot) - Engaged owner who can give weekly feedback - Currently running payroll with an existing vendor (migration story required) ### Pilot Candidate Table | # | Store typeNum | Contact name | State(s) | Rate-data ready? | Notes | |---|--------------|-------------|---------|-----------------|-------| | 1 | `` | `` | `` | Y / N / Waived | | | 2 | `` | `` | `` | Y / N / Waived | | | 3 | `` | `` | `` | Y / N / Waived | | | 4 | `` | `` | `` | Y / N / Waived | | | 5 | `` | `` | `` | Y / N / Waived | | ### Alternates (in case a pilot drops) | # | Store typeNum | Contact name | State(s) | Notes | |---|--------------|-------------|---------|-------| | A1 | `` | | | | | A2 | `` | | | | ### Finalization Sign-off - [ ] **3.1** List reviewed and approved by CS Lead **CS Lead:** ``, **Date:** `` - [ ] **3.2** Each pilot candidate notified and confirmed willing to participate - [ ] **3.3** List filed alongside rate audit at: `[INSERT LINK TO PILOT CANDIDATE LIST LOCATION]` ### Notes The pilot candidate list is stored at the link above (same location as the rate audit spreadsheet from Item 1) so CS and engineering can track both in one place. --- ## Item 4 — Named Owners per Item (Summary) **Status:** PENDING HUMAN ACTION **OWNER:** `` **Ref:** PRD F13 AC 4; SDD Deliverable 3 Per PRD F13 AC 4, generic "engineering" or "CS" attributions are not sufficient — every item must have a real person's name assigned as responsible owner. ### Owners Summary Table | Checklist item | Named owner | Role | Contact | Assigned date | |---------------|------------|------|---------|--------------| | Item 1 — Rate-data audit | `` | `` | `` | `` | | Item 2 — Kickoff email | `` | `` | `` | `` | | Item 3 — Pilot candidate list | `` | `` | `` | `` | | Item 4 — Owners table | `` | `` | `` | `` | | Engineering review (gate) | `` | Engineer | `` | `` | ### Notes This table must be completed before the Phase 1a kick-off meeting. "TBD" entries in the owners table are treated the same as unticked checkboxes for gate purposes. --- ## Engineering Review (Gate: T5.4.1) **Gate criterion:** "no Phase 1a Must-Have requires an unticked pre-flight item" *(Clarification: this criterion means every Phase 1a Must-Have feature can begin implementation without waiting on any item that is still unticked in this checklist.)* **Instructions for reviewing engineer:** 1. Read Items 1–4 above. 2. Cross-check against Phase 1a Must-Have features (PRD §Must Have Features, Features 1–13). 3. Confirm that any unticked item does NOT block a Phase 1a Must-Have from starting. 4. If any Phase 1a Must-Have IS blocked, document it in the "Blockers" sub-section below before ticking the review checkbox. 5. Sign below. ### Engineering Review Checklist - [ ] **ER-1** Items 1–4 reviewed against Phase 1a Must-Have feature list - [ ] **ER-2** No Phase 1a Must-Have is blocked by an unticked pre-flight item *(If ER-2 cannot be ticked, document blockers below and do NOT tick — Phase 1a cannot start.)* - [ ] **ER-3** Any waived items reviewed; waivers are adequate and documented ### Blockers (fill in if ER-2 cannot be ticked) | Phase 1a feature | Blocked by | Item # | Resolution required | |-----------------|-----------|--------|-------------------| | | | | | ### Sign-off ``` Signed-off-by: _______________________________ (engineer name) _______________________________ (date: YYYY-MM-DD) _______________________________ (PR or link to evidence) ``` > **Note:** This sign-off line must be filled in by an engineer, not the checklist > author. The sign-off constitutes the T5.4.1 gate capture referenced in the > implementation plan. --- ## Appendix A — Ready-to-Send Partner Kickoff Email Draft > **CS instructions:** Personalize the greeting (replace `[PARTNER MANAGER NAME]`), > confirm the BuyerKiosk sender name and title, and send. All questions below are > taken directly from the analysis document (§13). Do not remove any question from > the list — unanswered items will be followed up on in weekly check-ins. --- **To:** `[Everee partner manager email — confirm with Everee account team]` **CC:** `[CS Lead]`, `[Tech Lead]` **Subject:** BuyerKiosk × Everee Integration — Partner Kick-off + Open Questions --- Hi `[PARTNER MANAGER NAME]`, My name is `[YOUR NAME]` and I'm the `[YOUR TITLE]` at BuyerKiosk. We're beginning implementation of our Everee-powered payroll module and I wanted to kick off a working conversation with your team. We have a set of open technical and commercial questions that are blocking or near-blocking for our Phase 1a build start. I've grouped them below — some are immediate blockers, others are near-term but not day-one blockers. We'd love answers on the first two groups as quickly as possible. ### Group A — Immediate Blockers (needed before Phase 1a build start) 1. **Sandbox tenant availability** — Is a sandbox / staging environment available for integration testing? If so, how does it differ from production (e.g., is there real-money risk in sandbox)? How do we request credentials? 2. **HMAC algorithm for webhook signing** — Which algorithm do you use for signing webhook payloads (e.g., HMAC-SHA256)? What is the exact signature header name and format? What is the secret rotation mechanism when we need to rotate webhook secrets? ### Group B — Near-Term (needed within first 2 weeks of Phase 1a) 3. **Idempotency-key support** — Do your POST endpoints support an idempotency key header? If so, what is the header name and what is the scope of idempotency (same key = same response within N minutes/hours)? 4. **Full webhook event enumeration** — The public documentation shows only a subset of webhook events. Can you provide a complete event catalog with sample payloads for all events we should handle? 5. **Self-serve provisioning API** — Is there an API endpoint to programmatically create a new Company Instance (tenant), or does provisioning require a manual step on your portal? If API-based, what are the required fields? 6. **Pay-run preview endpoint** — Is there an endpoint to preview gross/net pay for a pay run before submitting? If so, what is its shape? 7. **Off-cycle / correction-run flow** — What is the API flow for an off-cycle or correction run? Same endpoint as a regular run with a flag, or a separate endpoint? ### Group C — Important but Not Day-One Blocking 8. **Pricing tier** — What is your pricing structure for a payroll-embedded reseller integration (per-active-employee + per-payment rates, minimum commit)? 9. **Bulk W-2/1099 retrieval API** — Is there an API endpoint for bulk retrieval of W-2/1099 forms at year-end? Our employee-facing mobile app will need to surface W-2s. 10. **Co-branded / white-labeled support** — Do you offer co-branded support where your reps answer as BuyerKiosk? If so, what tier is required? 11. **Co-marketing** — Do you have a co-marketing program for white-label integration launches? 12. **ACH funding timing** — What is your ACH funding lead time (T-1? T-2?) and what are the merchant funding account requirements? 13. **Pay-frequency mix per EIN** — Can a single Company Instance (EIN) have employees on different pay frequencies (e.g., hourly weekly + salaried biweekly)? 14. **Multi-EIN parent account management** — Is there a parent-level account that can manage multiple EINs, or is each Company Instance truly standalone? 15. **Multi-store employee handling** — If one employee works at two stores sharing the same EIN, do we create one Worker record or two? If one, how are per-store rates/positions differentiated? 16. **E-Verify inclusion** — Is E-Verify built into your ONBOARDING embed component, or is that a separate integration requirement? 17. **SLA on tax filing accuracy** — What is your SLA for tax filing accuracy? What is the remediation responsibility split if a filing error occurs? 18. **Data portability / export** — If we ever need to migrate a customer off Everee, what is the data export story (API export, manual export, etc.)? 19. **Pay card fee structure** — What is the Everee Pay Card fee structure (per-card per-month)? Is the fee absorbed by BuyerKiosk, passed to the merchant, or optional for the employee? 20. **PTO / leave handling** — Does Everee track PTO balances at all, or do we own the PTO engine completely and simply pass PTO hours as a pay code at run time? --- We're targeting a pilot with 5 stores and want to begin Phase 1a development as soon as we have sandbox credentials and the HMAC algorithm confirmed (items A-1 and A-2 above). All other items can be addressed in follow-up conversations. Happy to set up a call to walk through any of these. What does your calendar look like this week or next? Thanks, `[YOUR NAME]` `[YOUR TITLE]`, BuyerKiosk `[YOUR EMAIL]` --- *End of Appendix A* --- ## Document History | Date | Change | Author | |------|--------|--------| | 2026-05-29 | Initial scaffold created (all items PENDING HUMAN ACTION) | Engineering (T5) | | | | |