The Problem
Santa's workshop delivers cookies to children all over the world using a manual workflow, which leads to long delivery times and the wrong cookies reaching children. Children have no way to request a cookie or see where it is, and elves have no shared view of the work in progress.
Goal: Give children a simple way to request and track cookies, and give the workshop one place to approve, bake, pack and deliver every request.
It's whimsical on the surface (the world needs more joy), but underneath it's a familiar enterprise shape: a request intake, an approval queue, hand-offs between specialized roles, and an audit trail.
Who It's For
| Persona | Description | Primary need |
|---|---|---|
| Child | Young user with limited reading and typing ability, on a family device | Ask for a favorite cookie and see when it will arrive |
| Dispatch elf | Reviews every incoming request against naughty / nice criteria | Approve or reject requests quickly and consistently |
| Baking elf | Manages oven queues | Know what to bake next and mark it done |
| Packaging elf | Boxes approved, baked cookies | Confirm the right cookie went in the box |
| Delivery elf | Handles routes and final drop-off | Know where each box goes and record delivery |
Requirements
The workshop eventually needs a full system with accounts, but the first goal was a trial run alongside the current process, so the requirements specification covers only the most critical features. The workflow connects both sides through a shared request status:
Design Decisions
-
One dashboard, every role
Status counts across the top show where work is piling up. Each elf works from the same request table, so hand-offs never get lost between teams.
-
Decide, then act
Dispatch marks each child Nice or Naughty first, and only then can they approve or reject. Separating the judgment from the action prevents accidental approvals.
-
Built for a child
The request form is one short screen: minimal required fields, cookies chosen from large selectable options instead of typed, and plain-language hints like "Where should the cookies go?"
-
The child sees the same status
Every state change in the workshop updates the child's tracker, so both sides share one source of truth.
Measuring Success
| Metric | Target | How It's Measured |
|---|---|---|
| Request drop-off rate | Minimal | Analytics events per request step |
| Time to approval | Reduced vs. baseline | Request created → approved / denied |
| Time to delivery | Reduced vs. baseline | Approved → delivered |
| Baking mistakes | Reduced vs. baseline | Packaging rejections logged in history |
| Delivery mistakes | Reduced vs. baseline | Failed or misdelivered requests logged in history |
Where the current process already tracks a metric, it becomes the baseline. Where it doesn't, the trial sets the first benchmark.
What's Next
- System Administration: Onboarding the first admin, managing elf accounts, role-based access so each elf only sees what they need, and history retention that meets legal requirements.
- Exception States: Failed delivery and Return to kitchen, so problems get fixed instead of lost.
- Search/Filtering: Applies across the request data model for data lookup.
- Explicit Approval Criteria: Written naughty / nice criteria for more consistent dispatch decisions.
- Accessibility: Full keyboard navigation, visible focus states and screen-reader labels (WCAG 2.1 AA).
- Activity Log: A full user activity log for auditing.