# Product Requirements Document ## Validation Checklist - [x] All required sections are complete - [x] No [NEEDS CLARIFICATION] markers remain - [x] Problem statement is specific and measurable - [x] Problem is validated by evidence (not assumptions) - [x] Context → Problem → Solution flow makes sense - [x] Every persona has at least one user journey - [x] All MoSCoW categories addressed (Must/Should/Could/Won't) - [x] Every feature has testable acceptance criteria - [x] Every metric has corresponding tracking events - [x] No feature redundancy (check for duplicates) - [x] No contradictions between sections - [x] No technical implementation details included - [x] A new team member could understand this PRD --- ## Product Overview ### Vision Transform floor replenishment from a reactive, intuition-based process into a data-driven system that tells store staff exactly what categories need restocking, which backstock bins to pull, and tracks completion—maximizing floor inventory turnover while minimizing stockouts. ### Problem Statement Resale store managers currently have no visibility into which floor areas need replenishment until they visually notice empty racks. This creates two painful problems: 1. **Reactive restocking**: Staff only replenish when racks look visibly depleted, often too late to maximize sales 2. **Disconnected inventory systems**: Backstock bins contain categorized inventory, but there's no automated way to connect "Category X is selling fast on the floor" with "Bin Y in backstock contains Category X" The consequence is lost sales (customers can't buy what isn't on the floor), wasted labor (staff walking to check inventory that doesn't need replenishment), and poor inventory turnover (backstock ages while floor sells out). ### Value Proposition The Replenishment Reporting System provides: - **Proactive alerts** showing which categories are depleting faster than they're being replenished by buy activity - **Intelligent bin recommendations** matching depleted floor categories to the oldest onsite backstock bin - **Offsite coordination** when onsite bins aren't available, generating printable pull lists for offsite storage trips - **Task integration** creating trackable work items when bins are assigned for replenishment This is uniquely valuable for resale stores because: - Unlike traditional retail, resale stores constantly receive new inventory through customer "buys" which replenishes the floor naturally - The system accounts for buy activity to avoid false "needs replenishment" signals - Variable rack capacity per category (jeans take more space than scarves) requires floor-space-aware calculations ## User Personas ### Primary Persona: Store Manager - **Demographics:** 25-45 years old, manages 3-15 employees, moderate technical proficiency, responsible for daily operations and KPIs - **Goals:** Maximize sales by keeping floor stocked with in-demand categories; minimize labor waste; ensure smooth operations - **Pain Points:** Currently walks the floor visually checking rack fullness; has no data on which categories are depleting; doesn't know which backstock bins match which floor needs; loses time coordinating offsite storage pulls ### Secondary Persona: Assistant Manager / Shift Lead - **Demographics:** 20-35 years old, responsible for floor operations during shift, executes on manager's direction - **Goals:** Complete assigned replenishment tasks efficiently; keep floor looking full during their shift - **Pain Points:** Gets vague direction like "check backstock for women's tops"; doesn't know which specific bins to pull; no way to mark replenishment as complete ### Tertiary Persona: Backstock Specialist - **Demographics:** 18-30 years old, primarily works in backstock area organizing and pulling bins - **Goals:** Know exactly which bins to pull and where they go; minimize trips between floor and backstock - **Pain Points:** No prioritized pull list; doesn't know which bins are most urgent; offsite pulls require manual coordination ## User Journey Maps ### Primary User Journey: Daily Replenishment Check 1. **Awareness:** Manager opens Replenishment Report at start of shift to see which floor areas need attention 2. **Consideration:** Reviews heatmap to identify highest-priority zones; examines table view for specific category details 3. **Decision:** Sees that "Women's Tops" has depleted 40% since last replenishment with only 5 items bought in that category—decides to replenish 4. **Action:** System recommends Bin #47 (onsite, oldest bin with Women's Tops); manager creates replenishment task assigned to staff member 5. **Completion:** Staff pulls bin, restocks floor, marks task complete; system resets replenishment tracking for that category ### Secondary User Journey: Offsite Pull Coordination 1. **Trigger:** Manager notices replenishment report shows "Men's Denim" needs restocking but only offsite bins available 2. **Review:** Examines Offsite Pull Report showing 3 bins containing Men's Denim at the offsite location 3. **Print:** Generates printable pull list with bin names, categories, and locations 4. **Execution:** During next offsite trip, uses printed list to pull bins and transport to store 5. **Update:** Upon return, bins are now onsite and available for floor replenishment ### Tertiary User Journey: Bin Setup with POS Categories 1. **Discovery:** User creates new bin or scans existing bin 2. **Category Selection:** Selects primary category from POS subcategory list (e.g., "5020 - Womens Bottoms Denim") 3. **Tag Addition:** Optionally adds custom tags for additional categorization (e.g., "Summer", "Plus Size") 4. **Additional POS Categories:** Can also add additional POS subcategories if bin contains mixed inventory 5. **Confirmation:** Bin is saved with POS-trackable categories that link to floor plan assignments ## Feature Requirements ### Must Have Features #### Feature 1: Backstock Category System Redesign - **User Story:** As a store manager, I want bins to be categorized using POS subcategories so that the system can automatically match sold items to available backstock - **Acceptance Criteria:** - [ ] Main category field only accepts values from `drsSubCategories` table (POS subcategory codes) - [ ] User can search/filter POS subcategories by description when selecting main category - [ ] User can add unlimited "tags" (custom categories from `bsCategories` + additional POS subcategories) - [ ] Existing bins with non-POS main categories are migrated: current mainCategory → tags, mainCategory set to NULL - [ ] New bins MUST have a POS subcategory as main category (required field) - [ ] Category lookup for replenishment searches both main category AND tags for POS subcategory matches #### Feature 2: Rack Capacity Configuration - **User Story:** As a store manager, I want to specify how much floor space each rack and category occupies so that replenishment urgency accounts for actual floor capacity - **Acceptance Criteria:** - [ ] Each rack TYPE has a default "rack units" field (e.g., H-rack default = 2 units) - [ ] Each INDIVIDUAL rack can override the rack type default (e.g., Double H-rack = 4 units, modified H-rack = 1.5 units) - [ ] Rack units field visible when editing individual racks on floor plan, pre-populated with rack type default - [ ] When assigning categories to a rack socket, user can adjust the rack unit allocation per category - [ ] Default allocation is auto-split evenly (3 categories on 2-unit rack = 0.67 units each) - [ ] User can manually override via slider or input to uneven distribution (e.g., 0.5 + 0.5 + 1.0) - [ ] System calculates total rack units per category across all floor plan assignments using individual rack values - [ ] Validation prevents allocating more units than the individual rack provides #### Feature 3: Replenishment Scoring Algorithm - **User Story:** As a store manager, I want the system to calculate replenishment priority based on sales, buys, and floor capacity so that I know which areas need attention most - **Acceptance Criteria:** - [ ] Formula: `Replenishment Score = (items_sold - items_bought) / total_rack_units` - [ ] Score is calculated per POS subcategory using sales from `kiosk_sales.sales` table - [ ] Buy activity is retrieved from the store's `buyQueue` table - [ ] Higher score = more urgent replenishment need - [ ] Score resets when category is marked as "replenished" (starts fresh 7-day window) - [ ] Default time window: 7-day rolling, OR time since last replenishment if category has replenishment history - [ ] Categories with no replenishment history default to 7-day rolling window #### Feature 4: Replenishment Heatmap Report - **User Story:** As a store manager, I want to see a visual heatmap of my floor plan showing which zones need replenishment so that I can quickly identify problem areas - **Acceptance Criteria:** - [ ] Report accessed via replacing "Audit" button on heatmap reports page - [ ] Heatmap overlays on existing floor plan canvas (same color scheme as sales heatmap) - [ ] Color intensity indicates replenishment urgency using 5-tier scale: - Score 0-5 (Adequate): Green (#28a745) - Score 5-10 (Monitor): Yellow (#ffc107) - Score 10-15 (High): Orange (#fd7e14) - Score 15-20 (Urgent): Red (#dc3545) - Score 20+ (Critical): Deep Red (#721c24) - [ ] Clicking a zone opens modal popup with category breakdown, stats, recommended bin, and 'Create Task' button - [ ] Toggle between "Sales Heatmap" and "Replenishment Heatmap" views - [ ] Legend shows score-to-color mapping with configurable thresholds (Adequate/Monitor/Urgent) - [ ] Unassigned categories (sales but no floor assignment) shown in summary - [ ] Responsive breakpoints: Desktop (≥1200px), Tablet (768-1199px), Mobile (≤767px) - [ ] Mobile view shows simplified heatmap with tap-to-expand category details - [ ] If no floor plan exists, show setup wizard: 1) Create floor plan, 2) Assign categories, 3) Configure rack units #### Feature 5: Replenishment Table Report - **User Story:** As a store manager, I want a ranked list of categories needing replenishment with specific numbers so that I can prioritize and assign tasks - **Acceptance Criteria:** - [ ] Table columns: Checkbox, Category, Items Sold, Items Bought, Net Depletion, Rack Units, Score, Recommended Bin, Bin Location - [ ] Sorted by replenishment score (highest first) - [ ] Default view shows only categories needing attention (score > 0); toggle to show all floor categories - [ ] Filter by: category, minimum score threshold, onsite bins only - [ ] Recommended bin shows onsite bins first, then oldest by ageDate (FIFO) - [ ] Categories with no available bins show "No backstock available" indicator - [ ] Location indicator shows onsite vs offsite - [ ] Checkbox selection enables batch task creation via "Create Tasks" button - [ ] Individual "Create Task" action also available per row #### Feature 6: Offsite Pull Report - **User Story:** As a backstock specialist, I want a printable list of offsite bins to pull so that I can efficiently retrieve inventory during storage trips - **Acceptance Criteria:** - [ ] Report includes only categories where no onsite bin is available - [ ] Grouped by storage location (e.g., "Offsite Unit A", "Offsite Unit B") - [ ] Shows under each location: Bin Name, Category, Age, with checkbox for marking pulled - [ ] Printable checklist format (clean, no navigation elements) - [ ] Sortable by category or location within each group - [ ] Can manually select which bins to include in print - [ ] Shows total number of bins and estimated trip count (assumes 10 bins per trip max; configurable in store settings) #### Feature 7: Replenishment Task Creation - **User Story:** As a shift lead, I want to create trackable tasks when bins are assigned for replenishment so that staff knows what to do and completion is tracked - **Acceptance Criteria:** - [ ] Task includes: bin to pull, category, destination zone - [ ] Employee assignment is optional (can leave unassigned for anyone to claim) - [ ] Task appears in Workbook task list - [ ] Completing task marks the category as "replenished" (resets score timer) - [ ] On task completion, remove the MAIN category from bin by default (POS tags remain) - [ ] After main category removal, handle bin state: - If no POS categories remain → Bin becomes empty - If only custom tags remain → Prompt: "Add new main POS category or bin will be emptied" - If POS tags remain → Prompt user to select new main category from existing POS tags - [ ] Replenishment history is logged for reporting - [ ] Trust user completion for now (barcode scan verification planned for future) #### Feature 8: Manual Replenishment Reset - **User Story:** As a store manager, I want to reset replenishment tracking for all categories at once so that the system reflects reality when staff handled restocking outside the tracked workflow - **Acceptance Criteria:** - [ ] "Reset All Replenishment" button available in BOTH locations: - Replenishment Report page (top-right) - Workbook settings section - [ ] Confirmation dialog before reset: "This will mark all categories as fully replenished. Continue?" - [ ] Reset sets replenishment tracking start time to now for ALL categories - [ ] Individual category reset available (click category → "Mark Replenished") - [ ] Reset actions are logged for audit trail - [ ] Score recalculation reflects the new baseline immediately ### Should Have Features #### Feature 9: Auto-Suggested Replenishment Alerts - **User Story:** As a store manager, I want the system to proactively alert me when categories exceed replenishment thresholds so that I don't have to manually check - **Acceptance Criteria:** - [ ] Configurable threshold per category (e.g., "Alert when score > 10") - [ ] Dashboard widget shows number of categories needing replenishment - [ ] Notifications are in-app only (dashboard widget badge, not push/email) #### Feature 10: Replenishment History & Trends - **User Story:** As a store manager, I want to see historical replenishment patterns so that I can optimize staffing and backstock organization - **Acceptance Criteria:** - [ ] Track: category, replenishment date, bin used, time to complete - [ ] Weekly/monthly summary views - [ ] Identify "frequent flyers" - categories that need constant replenishment ### Could Have Features #### Feature 11: Bin Reservation - **User Story:** As a shift lead, I want to reserve a bin for replenishment so that another staff member doesn't grab it first - **Acceptance Criteria:** - [ ] "Reserve" action marks bin as assigned to a pending task - [ ] Reserved bins show differently in the UI - [ ] Reservation expires after configurable time #### Feature 12: Batch Replenishment Mode - **User Story:** As a backstock specialist, I want to see all bins I need to pull in one optimized list so that I make one trip instead of many - **Acceptance Criteria:** - [ ] Select multiple categories for replenishment - [ ] System generates pull list grouped by location (onsite bins grouped together, then each offsite location) - [ ] Within each location group, bins sorted alphabetically by bin name for easy finding - [ ] Print all selected bins on one list ### Won't Have (This Phase) - **Real-time push notifications** - Alerts will be in-app only, no mobile push or email - **Automatic task creation** - System recommends but user must confirm task creation - **Predictive replenishment** - No ML/forecasting; purely reactive based on current sales/buys - **Multi-store replenishment** - Each store operates independently - **Bin scanning workflow** - Replenishment tasks will be marked complete manually, not via barcode scan - **Real-time inventory counts** - No IoT sensors or live floor stock tracking; scoring based on sales/buy data - **Physical stockout verification** - Stockouts inferred from scoring data, not physical confirmation ## Detailed Feature Specifications ### Feature: Backstock Category System Redesign **Description:** Transform the backstock bin categorization system from free-form custom categories to a POS-linked system where the primary category must be a POS subcategory code. This enables automatic matching between sales data and backstock inventory. **User Flow:** 1. User creates new bin or edits existing bin 2. System displays "Primary Category" field as searchable dropdown of POS subcategories 3. User types to search (e.g., "denim" → shows "5020 Womens Bottoms Denim", "2020 Mens Bottoms Denim") 4. User selects one POS subcategory as primary category (REQUIRED) 5. System displays "Tags" section with two options: - "Add POS Category" - opens same searchable dropdown - "Add Custom Tag" - opens dropdown of store's custom `bsCategories` 6. User can add unlimited tags of either type 7. System saves bin with POS subcategory code in main category field **Business Rules:** - Rule 1: Primary category field MUST contain a valid `drsSubCategories.subCatCode` value - Rule 2: A bin with NULL primary category is considered "uncategorized" and excluded from replenishment matching - Rule 3: When matching bins for replenishment, system checks both `mainCategory` AND all entries in `bsBin_Cat` junction table - Rule 4: Custom tags (from `bsCategories`) are for organizational purposes only; they don't participate in sales matching - Rule 5: POS category tags (additional entries in `bsBin_Cat` referencing POS codes) DO participate in sales matching - Rule 6: Migration of existing data: all current `mainCategory` values that don't match a `drsSubCategories.subCatCode` get moved to tags; `mainCategory` set to NULL **Edge Cases:** - Scenario 1: User searches for category not in POS system → Expected: Show "No matching POS categories" message; suggest using Tags for custom categorization - Scenario 2: User edits migrated bin with NULL main category → Expected: Prompt to select POS category; allow saving as NULL but warn it won't appear in replenishment reports - Scenario 3: Store has no `drsSubCategories` data (non-Plato's Closet) → Expected: POS subcategories will be added for all concepts; feature requires category data to function. Show "POS categories not configured" message if table is empty. ### Feature: Replenishment Scoring Algorithm **Description:** Calculate a replenishment priority score for each floor zone based on the formula: `(items_sold - items_bought) / total_rack_units_for_category`. This accounts for both sales velocity and floor space capacity. **User Flow:** 1. System runs calculation on-demand when user opens Replenishment Report 2. For each POS subcategory assigned to floor plan: - Count items sold since last replenishment (or configurable window) - Count items bought in same period (these will be placed on floor) - Sum total rack units allocated to this category across all sockets - Calculate: `score = (sold - bought) / rack_units` 3. Display scores ranked from highest (most urgent) to lowest **Business Rules:** - Rule 1: If `rack_units = 0` for a category (not assigned to floor), score is undefined (show as "Not on floor") - Rule 2: Negative scores (bought more than sold) display as "Overstocked" with score of 0 - Rule 3: Score of 0 to 5 = "Adequate", 5 to 15 = "Monitor", 15+ = "Urgent" (thresholds configurable) - Rule 4: "Since last replenishment" timer resets when a replenishment task for that category is marked complete - Rule 5: Buy data comes from `kiosk_sales.buys` filtered by `typeNum` and `subCatID` (provides accurate per-category counts) - Rule 6: Sales data comes from `kiosk_sales.sales` filtered by `typeNum` and `subCatID` **Edge Cases:** - Scenario 1: No sales data for period → Expected: Score = 0, show "No recent sales" - Scenario 2: No buy data table in store → Expected: Treat bought count as 0 - Scenario 3: Category on floor plan but no socket assignments → Expected: Exclude from scoring - Scenario 4: Multiple sockets share same category → Expected: Sum all rack units for that category - Scenario 5: Partial replenishment (only part of bin moved to floor) → Expected: Task completion still resets category score; partial handling is a user workflow choice not tracked by system - Scenario 6: Multiple concurrent tasks for same category → Expected: Allow multiple tasks; first completed task resets the score, subsequent tasks show "Already replenished" warning but can still be completed - Scenario 7: Bin moved onsite/offsite after task creation → Expected: Task retains original bin reference; location shown may differ from current; UI shows "(Location changed)" indicator if mismatch - Scenario 8: Category removed from floor plan while task pending → Expected: Task can still be completed; category shows "No longer on floor" in task details ## Success Metrics ### Key Performance Indicators - **Adoption:** 80% of stores use Replenishment Report at least weekly within 3 months of launch - **Engagement:** Average 5+ replenishment tasks created per store per week - **Quality:** 95% of replenishment tasks completed same-day - **Business Impact:** 10% reduction in "stockout events" within 6 months of launch ### Stockout Definition A **stockout event** occurs when: - A category's replenishment score exceeds the "Urgent" threshold (default: 15+) - AND the score remains above Urgent for 24 consecutive hours without a replenishment task being created or completed **Measurement:** - System logs a `stockout_event` when conditions are first met - Event includes: `typeNum`, `categoryCode`, `score`, `timestamp` - Baseline measurement: First 30 days post-launch (before users establish habits) - Target measurement: Rolling 30-day windows, compared to baseline - Store eligibility: Only stores with active floor plan + category assignments are counted ### Tracking Requirements | Event | Properties | Purpose | |-------|------------|---------| | `replenishment_report_viewed` | `typeNum`, `reportType` (heatmap/table), `userId` | Measure feature adoption | | `replenishment_score_calculated` | `typeNum`, `categoryCount`, `urgentCount`, `calculationMs` | Monitor performance and urgency levels | | `bin_category_assigned` | `typeNum`, `binId`, `categoryType` (pos/custom), `categoryCode` | Track POS category adoption | | `replenishment_task_created` | `typeNum`, `binId`, `categoryCode`, `isOnsite` | Measure actionable report usage | | `replenishment_task_completed` | `typeNum`, `taskId`, `timeToCompleteMinutes` | Track completion efficiency | | `offsite_report_printed` | `typeNum`, `binCount` | Measure offsite coordination usage | | `replenishment_reset` | `typeNum`, `resetType` (all/category), `categoryCode` (if single) | Track manual reset usage | | `stockout_event` | `typeNum`, `categoryCode`, `score`, `hoursAboveThreshold` | Track when categories enter stockout state (score > Urgent for 24h) | | `stockout_resolved` | `typeNum`, `categoryCode`, `resolutionType` (task_completed/manual_reset) | Track how stockouts are resolved | --- ## Dependencies ### Data Dependencies | Dependency | Required | Status | Fallback | |------------|----------|--------|----------| | `drsSubCategories` table | For scoring | Populated for PC stores | Warning message for non-PC stores | | `kiosk_sales.sales` table | For scoring | Available | Score shows "No sales data" | | `buyQueue` table | For scoring | Available | Treat buys as 0 | | Floor plan with sockets | For scoring | User must create | Setup wizard guides creation | | Socket-to-category assignments | For scoring | User must configure | Prompt to assign categories | ### System Dependencies - **Analytics pipeline:** New tracking events require event logging infrastructure (already in place via existing analytics) - **Print functionality:** Browser print API for offsite pull reports (no external dependencies) - **Mobile responsive:** Bootstrap 5 responsive utilities (already in design system) ### Migration Dependencies - **Backstock category migration:** Must run before feature launch; migrates non-POS mainCategory values to tags - **Rollback plan:** Migration is non-destructive; original categories preserved in tags --- ## Constraints and Assumptions ### Constraints - **Existing data migration required:** Current backstock users have bins with custom categories that need graceful migration - **POS category availability:** Only Plato's Closet stores (storeType=1) currently have the `drsSubCategories` table populated. Non-PC stores will receive POS categories in a future update. - **Store eligibility behavior:** Stores without `drsSubCategories` data can access the feature but will see a prominent warning: "POS categories not configured. Replenishment scoring requires POS subcategories to match sales data. Contact support to enable POS categories for your store." - **Floor plan prerequisite:** Replenishment scoring requires floor plan with category-to-socket assignments - **Real-time not required:** Report calculations can be on-demand, not streaming - **Mobile responsive:** All features must work on mobile/tablet devices (breakpoints: Desktop ≥1200px, Tablet 768-1199px, Mobile ≤767px) - **Permission model:** Uses existing floor plan access permissions (no new permission layer) ### Assumptions - Users will adopt POS categories when they understand the replenishment benefits - Stores have relatively consistent rack configurations that make capacity tracking valuable - Managers check reports at least daily to benefit from the system - Buy activity accurately reflects inventory going to the floor (not to backstock) ## Risks and Mitigations | Risk | Impact | Likelihood | Mitigation | |------|--------|------------|------------| | Users resist POS category adoption | High | Medium | Provide clear migration path; allow NULL temporarily; show benefits in-app | | Inaccurate rack capacity data | Medium | Medium | Default to equal distribution; allow manual override; surface "check configuration" prompts | | Buy activity doesn't go to floor | High | Low | Add clarification that bought items are assumed floor-bound; future: track destination | | Score calculation performance | Medium | Low | Cache results; calculate on-demand not real-time | | Non-PC stores lack POS categories | High | Low | POS subcategories will be added for all concepts; feature waits for this data | ## Open Questions *All questions resolved - see Decisions below* ### Resolved Decisions **Data & Algorithm:** - **Non-Plato's Closet stores:** POS subcategories will be added for all concepts soon. Stores without POS data can access the feature with a warning message; development will use Plato's Closet data for testing. - **Time window (Hybrid approach):** Default is 7-day rolling window. When a category is replenished (task completed or manual reset), the window resets to start from that replenishment date. Categories with no replenishment history use the 7-day rolling window. This means: - New/never-replenished categories: Score based on last 7 days of sales/buys - Recently replenished categories: Score based on activity since replenishment - Manual reset: Resets all categories to start fresh 7-day windows - **Bin recommendation priority:** Onsite bins first, then oldest by ageDate (FIFO within onsite, then offsite) - **Rack unit defaults (per rack type, can be overridden per individual rack):** - H-rack = 2.0 (two sides, baseline unit) - Double H-rack (stacked) = 4.0 (two rows of poles) - Rounder = 1.0 (single circular rack) - Four-Way = 4.0 (four arms) - Gondola = 4.0 (similar capacity to 2 H-racks) - Wall fixtures = varies by type (configurable) - Note: Individual racks can override their type's default (e.g., a modified H-rack could be set to 1.5 units) - **Score thresholds:** Configurable per-store (Adequate/Monitor/Urgent levels) **UI/UX:** - **Report location:** Replaces current "Audit" button on the heatmap reports page - **Heatmap colors:** Same color scheme as sales heatmap (consistent visual language) - **Zone click action:** Modal popup with category breakdown, stats, and 'Create Task' button - **Rack allocation UI:** Auto-split evenly with manual slider/override capability - **No bins available:** Show category in report with "No backstock available" indicator - **Table default view:** Filterable - defaults to "needs attention" (score > 0), toggle to show all - **Batch task creation:** Checkboxes in table view; "Create Tasks" button for bulk creation - **Reset button location:** Available in both Replenishment Report page AND Workbook settings - **Task assignment:** Optional - can assign to specific employee OR leave unassigned - **Offsite print format:** Location-grouped with checklist format for marking off pulled bins - **Notification method:** In-app only for initial release (dashboard widget and badge count). No push or email notifications. - **Mobile support:** Full responsive design for all devices - **Permissions:** Anyone with floor plan access can configure rack units and thresholds **Task Completion & Bin Management:** - **Task completion verification:** Trust user for now; plan for barcode scan verification in future phase - **Category removal on task completion:** Always remove the MAIN category by default; POS tags stay unless manually removed - **Post-removal bin handling:** Based on remaining contents: - If bin has only ONE POS main category and NO subcategories → Bin becomes empty - If bin has ONE POS main category and custom tags only → Prompt user: "Add a new main POS category or bin will be emptied (all custom tags removed)" - If bin has POS subcategories as tags → Prompt user to select new main category from existing POS tags **Scoring & Thresholds:** - **Default score thresholds:** 0-5 = Adequate, 5-15 = Monitor, 15+ = Urgent (configurable per-store) - **Buy activity matching:** Exact POS subcategory code match (buy's subCatID must match floor socket's assigned subcategory) **History & Tracking:** - **Bin tracking:** Yes - link specific bin to each replenishment task for history/reporting (enables "bin X pulled Y times" analytics) **Onboarding:** - **Empty state (no floor plan):** Helpful setup wizard guiding users through: 1) Create floor plan, 2) Assign categories to sockets, 3) Configure rack units --- ## Supporting Research ### Competitive Analysis No direct competitors in the resale POS space offer integrated floor plan + backstock replenishment. This is a differentiating feature that combines our existing floor plan module with backstock management. Traditional retail inventory systems (Oracle Retail, SAP) have replenishment modules but are designed for warehouses → shelf, not resale's unique buy → floor flow. ### User Research Based on existing user feedback: - Managers frequently mention walking the floor to "check stock levels" - Backstock bins are often organized by category but there's no system to query "what bins have X" - Offsite storage pulls are coordinated via text messages or handwritten lists ### Market Data Plato's Closet franchise has 450+ locations; efficient floor replenishment directly impacts same-store sales. Even a 5% improvement in inventory turnover represents significant value.