Operations
Service model, scheduling discipline, metrics, and go-to-market
Last updated: Feb 27, 2026
On This Page
Operations Reality
Core Principle
Humans execute; software enforces discipline.
Key Constraints
| Constraint | Value | Rationale |
|---|---|---|
| Lead Time | 48 hours | Enables batching, reliability, cost control |
| Advance Booking | Weeks/months | Seasonal items, holidays, planned rotations |
| Service Days | Building-specific | Batch efficiency |
What Software Does
- Captures item and service data
- Enforces scheduling rules (lead time)
- Produces operational metrics
- Maintains audit trails
What Software Does NOT Do
- Real-time location tracking
- Route optimization (future)
- Ops micromanagement dashboards (pre-scale)
Scheduling Discipline
48-Hour Lead Time
The 48-hour lead time is a deliberate policy that:
- Promotes planned usage β Customers think ahead (seasonal rotations, events)
- Improves reliability β Reduces last-minute failures
- Enables batching β Multiple stops per trip
- Reduces cost volatility β Predictable operations
Advance Scheduling
Customers can book returns weeks or months in advance:
- Holiday decorations scheduled in October for December delivery
- Seasonal clothes rotations planned quarterly
- Event-based items (party supplies) scheduled around dates
Why NOT On-Demand
| On-Demand Risk | SV Approach |
|---|---|
| Cost volatility | Predictable scheduling |
| Operational chaos | Batched service days |
| Customer anxiety | Planned, reliable delivery |
| Low density | Building-specific routes |
Service Availability Hours
Published on the live website and enforced via Calendly scheduling. All times Eastern.
| Day | Hours (ET) |
|---|---|
| Monday β Friday | 8:00 AM β 8:00 PM |
| Saturday | 9:00 AM β 9:00 PM |
| Sunday | 10:00 AM β 4:00 PM |
Calendly Scheduling Configuration
Settings applied to both event types (Building Partnership Discussion and Pickup & Delivery Service).
| Setting | Value |
|---|---|
| Minimum Notice | 2 days (48 hours) |
| Scheduling Window | 365 days into the future |
| Shared Schedule | Storage Valet Operations (default) |
Operational Workflows
Pickup Flow
1. Customer schedules pickup (Calendly) β 48hr+ notice (optionally with items pre-selected on Dashboard) 2. Webhook creates action (pending_items) 3. Items attached β auto-attached if pre-selected, or customer selects manually in portal 4. Action status β pending_confirmation 5. Ops confirms booking 6. Ops executes pickup 7. Items scanned/verified at facility 8. Item status β stored 9. Action status β completed
Delivery Flow
1. Customer schedules delivery (Calendly) β 48hr+ notice (optionally with items pre-selected on Dashboard) 2. Webhook creates action (pending_items) 3. Items attached β auto-attached if pre-selected, or customer selects stored items manually 4. Action status β pending_confirmation 5. Ops confirms booking 6. Ops retrieves items from storage 7. Ops delivers to customer 8. Customer confirms receipt 9. Item status β home 10. Action status β completed
Cancellation Flow
Customers can cancel bookings in pending or confirmed status directly from the portal.
1. Customer cancels in portal (pending or confirmed) 2. Action status β canceled 3. Item status reverts (based on booking type): - Pickup items (in pickup_item_ids) β home - Delivery items (in delivery_item_ids) β stored 4. No penalty (within policy)
Item Removal
Customers can also remove individual items from pending bookings without canceling the entire booking. Removed items revert based on booking type (pickup → home, delivery → stored).
Service Types
| Service | Code | Description |
|---|---|---|
| Pickup | pickup | Collect items from customer, transport to storage |
| Redelivery | redelivery | Return stored items to customer |
| Container Delivery | container_delivery | Deliver empty containers (future) |
Storage Operations
Facility Model
- Micro-hub footprint β Scales via adjacent units / nearby sites
- Climate-controlled β Protects customer items
- Mapped locations β Every container has documented position
Container Management
- Standard containers β Predictable capacity
- QR codes β Every item labeled:
SV-YYYY-NNNNNN - Scanning workflow β Chain-of-custody documentation
Scaling Pattern
Phase 1: Single unit (e.g., 280 sqft) Phase 2: Adjacent units (840 sqft, same location) Phase 3: Nearby micro-hub (new location, same market) Phase 4: New market micro-hub
Metrics
Survival Metrics (Rolling 6 Months)
| Metric | Target | Notes |
|---|---|---|
| Active Subscribers | Track growth | Core revenue driver |
| Contribution Margin | $200β$250/customer/mo | Unit economics health |
| Pickup/Return Cost | Minimize | Density dependent |
| Founder Support | $15kβ$20k/mo | Sustainability draw |
| Exception Rate | Minimize | Service quality |
Defensibility Metrics (12β18 Months)
| Metric | Definition |
|---|---|
| CUM | Containers Under Management |
| IUM | Items Under Management |
| DVUM | Declared Value Under Management |
| Retrieval Frequency | p50/p90 pickups/returns per customer/month |
| Storage Utilization | % of leased capacity in use |
| Customer Retention | Monthly/annual churn rate |
Go-to-Market Operations
Primary Wedge: Luxury Rentals
- Amenity framing β Storage Valet as building amenity
- Leasing office alignment β Partnership with property management
- Move-in kits β Onboarding new residents
- Seasonal campaigns β Holiday, back-to-school promotions
- Building service days β Batch efficiency per building
- Referral loops β Word-of-mouth in dense communities
Secondary: Homeowners
- Condo/HOA partnerships β Building-level deals
- Parent networks β School and activity group outreach
- Neighborhood associations β Community positioning
- Seasonal rotation positioning β Strollers, skis, holiday dΓ©cor, baby gear
Partnership Model
Zero-Footprint Amenity
Lightweight in-building activations, always-on asset placement (flyers, digital signage). Storage lockers are utilities; SV reclaims space while improving resident experience.
Operational Risks & Mitigations
| Risk | Mitigation |
|---|---|
| Flat plan overuse | Policy guardrails + batching + additional subscription for high-volume |
| Loss/damage trust | Documentation, chain-of-custody, clear protection policy, proper coverage |
| Operational scaling | Building density first, SOPs, inventory system, scheduling discipline |
| Last-minute changes | 48-hour policy, clear cancellation rules |
| Route inefficiency | Building-specific service days, batching |
Current Ops Tooling
What Exists:
- Customer Portal β Item and booking management
- Ops Dashboard β Staff-only view of all actions with customer details (gated by
sv.is_staff(), usesget_ops_actionsRPC) - Orphan Guardrail β
fn_revert_orphaned_scheduledruns on every dashboard load, automatically reverting items stuck in scheduled state with no active booking - Calendly β Appointment scheduling
- Stripe β Payment processing
- Supabase β Database and auth
What Does NOT Exist (Pre-Scale):
- Ops item manifests
- Automated reconciliation
- Route optimization