The problem
Requests for prices, promotions, services, and memberships arrived through email, chat, and hallway conversations. Many lacked scope, dates, or exact items. Some asked for things the platform could not do. Work stalled in back-and-forth while deadlines were set before the work was understood.
The operating model
01CaptureCreate one intake record, regardless of the original channel.
02CompleteTurn every assumption or missing detail into a question.
03CheckValidate constraints, lead times, and blackout windows.
04PhaseSequence new items, real values, activation, and promotions.
05Draft & QACheck the submission against the Definition of Done.
06ApproveObtain leader sign-off before vendor submission.
07Submit & auditConfirm timing and verify the finished change.
What the intake must establish
- The request type and exact action: create, update, or deactivate.
- The specific items and location scope—not a broad service category.
- Go-live and end dates, including scheduling conflicts and blackout windows.
- Every price or dollar value, paired with a source that can be validated.
Designing for platform constraints
A useful intake process does more than reject impossible requests. It explains the constraint and offers credible choices.
Example requestMake a 60-minute service $79 at every location in three weeks. Because prices vary by location, one discount code cannot produce the same final price everywhere.
Option ALocations create their own $79 code with exact instructions and verification. Meets the requested date.
Option BCreate one central $20-off code. Simpler to build, but final prices vary by location.
Option CMatch the price centrally for every location. Exact outcome, but requires 6–8 weeks.
Result
The team consistently delivered changes on committed dates. Timing conversations shifted toward planning promotions around known lead times months ahead.