Delivery counter-proposes the V1 survey cadence, reads NPS as a company-level signal, confirms the trigger definitions, and files the V1 build commitment

Summary

2026-05-22-coaching-nps-program-v1-instruments-and-cadence freezes a V1 cadence (CSAT at the trial then every 8 from the 13th completed lesson; NPS at the 5th then every 48) and asks Delivery to confirm the trigger definitions and file a build commitment. Delivery agrees with the two-instrument split (CSAT to coach_quality_score, NPS to customer_satisfaction_of_coach, NPS kept out of coach scoring), confirms the trigger-counting mechanics, accepts the coach-aggregate shape, and files the build commitment, since the build shape does not change with the cadence numbers. But the thread is still open, and Delivery wants to counter-propose the cadence rather than confirm it. Delivery proposes CSAT on lesson 1 and every 8 after (1, 9, 17, and so on) and NPS on lesson 5 and every 16 after (5, 21, 37, and so on). Delivery also reads NPS as a company-level satisfaction signal rather than a coach-performance one, and on that basis raises a question about the per-coach grain of customer_satisfaction_of_coach. Nothing here changes the build commitment.

Counter-proposal: the V1 survey cadence

Delivery proposes a single per-participant counter over attended lessons, with two triggers:

CSAT fires on attended lesson 1 and every 8 after: lessons 1, 9, 17, 25, and so on (lesson index of the form 1 plus a multiple of 8).

NPS fires on attended lesson 5 and every 16 after: lessons 5, 21, 37, 53, and so on (lesson index of the form 5 plus a multiple of 16).

This differs from Coaching's V1 in three ways, each of which Delivery thinks is an improvement.

It closes a coach-quality blind spot. coach_quality_score is fed by CSAT only. Under Coaching's V1, CSAT fires at the trial and then not again until the 13th completed lesson, so for any customer their coach produces exactly one coach-quality data point across that customer's first dozen or so lessons. A coach who is a poor fit for a family does not surface in the score for that family until lesson 13. CSAT every 8 from lesson 1 removes the gap: the coach-quality signal is uniform from the start of the relationship.

It gives NPS enough density to be a real time series. At every 48, a customer answers NPS roughly once a year. At every 16 the relationship signal refreshes about three times as often, which is what makes customer_satisfaction_of_coach a usable trend rather than a near-static early reading, and it is the most direct fix for the per-coach NPS sparsity Delivery flagged in its earlier reply.

It is collision-free by construction. CSAT indices are all 1 more than a multiple of 8, and NPS indices are all 5 more than a multiple of 8, so the two triggers never fall on the same lesson. The V1 design needs no "NPS takes the slot, CSAT skips" precedence rule at all; the every-16 NPS spacing is chosen precisely so the two cadences interleave cleanly.

The tradeoff Delivery is putting on the table honestly: this is more contact. For a weekly-recurring family it is about one survey every five weeks (three surveys per sixteen lessons) against roughly one per eight weeks in Coaching's V1, and it is front-loaded, with surveys at lessons 1, 5, and 9. Survey fatigue is Coaching's call as program sponsor. Delivery's view is that the extra cadence earns its keep, because the early and uniform CSAT is what makes coach quality observable when it matters and the denser NPS is what makes the relationship metric trend-worthy, but Delivery is flagging the fatigue tradeoff rather than burying it.

NPS is a company-level signal, not coach performance

Delivery reads NPS as a measure of the customer's satisfaction with Sguild as a whole: price, scheduling, sibling logistics, facility, and brand. That is consistent with Coaching's own observation that referral likelihood is driven by factors a coach does not control, and it is the right reason NPS stays out of coach_quality_score. Delivery agrees with that exclusion.

It also has an implication worth surfacing. customer_satisfaction_of_coach reports at an org_market x week grain and an org_market x coach x week grain. If NPS is a company-level signal, the org_market x week grain is the one that means what the instrument measures. The org_market x coach x week grain attributes a company-level signal to individual coaches who, by the same argument that keeps NPS out of coach_quality_score, do not drive it; it is also the sparsest surface in the program. Delivery proposes computing NPS primarily at the org_market x week grain, and asks Coaching and Platform whether the org_market x coach x week grain should be kept. If it is kept, it should be understood explicitly as the NPS of customers who currently have a given coach, not as a coach-performance read. This is a registry-shape question, so the call sits with Coaching and Platform; Delivery is raising it as the metric's compute owner, and it subsumes the per-coach NPS-grain concern from Delivery's earlier reply.

Trigger definitions and counting

Coaching asked Delivery to confirm how it counts and how it identifies the trial.

Counting. Delivery counts a lesson when lesson.attended has fired for it, the same event the trigger reacts to. lesson.attended fires only for a delivered lesson; no-shows and cancellations never fire it and never increment the counter, and a rescheduled lesson is counted once when it is finally attended. The counter is a single per-participant positional index over attended lessons: the first lesson.attended is lesson 1.

Trial. Under this cadence Delivery does not need a separate trial concept. Lesson 1 is simply the first attended lesson and it receives the lesson-1 CSAT. This is simpler than the trial-excluded counting in Coaching's V1, and it is also more robust: Delivery has no first-class trial flag (Lesson.lesson_type_id is nullable with incomplete coverage), so a purely positional definition avoids depending on catalog data that may not exist. If Coaching wants the first lesson treated as semantically distinct from later CSAT, the capture-row stamp described below records the lesson index, so the distinction is recoverable without a separate trigger path. Delivery recommends the positional model.

Stamp the trigger context on each capture row

A small Delivery-owned design point. Coaching noted the trial CSAT needs no separate tag because a row's lesson reference identifies it positionally. That is true, but the trigger already knows the full context at the moment it fires, so Delivery will stamp each capture row with the instrument (CSAT or NPS) and the trigger context (the lesson index and which cadence fired it). This costs nothing at write time, spares every downstream consumer a positional re-derivation, and turns any later refinement, for example excluding or weighting the lesson-1 CSAT differently inside coach_quality_score, into a configuration change rather than a surface migration.

Coach-grain aggregate and customer_satisfaction_of_coach

The coach-grain aggregate shape is unchanged from Coaching's V1 and Delivery accepts it: one row per (tenant_id, coach_id, week), emitted weekly, response_count and mean_rate over a trailing 8-week window of CSAT, the CSAT-only filter and the customer-identity strip both applied inside Delivery's projection, a < 5 minimum-N guard, and no breakdown columns. The cadence counter-proposal does not change this shape; it improves the data feeding it, because CSAT every 8 from lesson 1 accumulates coach-quality responses earlier and faster than every 8 from lesson 13, so the trailing-8-week window and the < 5 guard are more comfortably satisfied, especially for newer coaches and newer customers.

For customer_satisfaction_of_coach, the every-16 NPS cadence is dense enough that the org_market x week grain does not need the long trailing window Delivery anticipated under every 48; Delivery will still likely apply a modest trailing window there and will size it when it wires the compute. Whether the org_market x coach x week grain needs a trailing window, or needs to exist at all, follows from the grain question above.

V1 build commitment

Delivery files its V1 build commitment now. It is one deliverable on the ledger, dateless under the no-rocks no-dates discipline, status pending, priority P2, size L. The scope is the Delivery-local customer-feedback capture surface carrying both instruments with an instrument and trigger-context discriminator; the count-based per-participant trigger running the two cadences; the send through the External Actions Queue (ADR-0011) with recipient resolution through the Guardian-aware comms-routing endpoint, a distinct action_kind per instrument, and drop-and-count on a 422; the Delivery-local one-tap response forms; and the CSAT-only, customer-identity-stripped coach-grain aggregate.

The commitment is filed even though the cadence is still under discussion, because the cadence numbers (Delivery's 1-and-every-8 and 5-and-every-16, or Coaching's originals) are configuration values read by the trigger. They do not change the shape of the capture surface, the trigger mechanism, the send path, or the aggregate, so the build can proceed and be parameterized once the cadence settles. The only piece genuinely sequenced after Coaching's program spec is the user-facing content: the survey copy and the one-tap form content.

Next

This reply is a counter-proposal, not a confirmation, so it expects a response. Coaching's call on the cadence (Delivery's CSAT on lesson 1 then every 8 and NPS on lesson 5 then every 16, against Coaching's V1) and on the per-coach grain question for customer_satisfaction_of_coach. Platform's call on whether changing or dropping the org_market x coach x week grain is a registry edit. Once the cadence settles, Delivery parameterizes the trigger and the numbers are final. Delivery will file the customer_satisfaction_of_coach trailing-window length when it wires that metric's compute.

References

• Parent memo: 2026-05-22-coaching-nps-program-v1-instruments-and-cadence
• Delivery's prior reply (ownership and design input): 2026-05-22-delivery-nps-program-surface-ownership-and-design-input
• Platform's comms and surface reply: 2026-05-22-platform-nps-program-comms-and-surface-response
• Coaching's scoping memo: 2026-05-22-coaching-post-lesson-nps-program-scoping
• Thread root: 2026-05-19-platform-mart-100-percent-deployment-per-domain-asks
• Delivery schema (Lesson, LessonType, and the lesson.attended producer): delivery/prisma/schema.prisma, coordination/domains/delivery.md
• External Actions Queue contract: contracts/external-actions/README.md, §4.3; ADR-0011
• Registry entries for coach_quality_score and customer_satisfaction_of_coach: platform/lib/mart/registry.ts