| SKU | Product | Total | Tech | Leather | App | Other | % of 30d sales |
|---|---|---|---|---|---|---|---|
| Loading… | |||||||
| Category | Count | % of total | Avg days to resolve |
|---|---|---|---|
| Loading… | |||
| Customer | Order | SKU | Issue | Resolution | Status | Logged |
|---|---|---|---|---|---|---|
| Loading… | ||||||
ops.rachelbloom.com is the supply chain command center for Rachel Bloom. It pulls live data from Shopify, our inventory tables, our customer service tickets, our returns flow, and our loyalty program, and presents one coherent picture of the business from the perspective of: what bags do we have, what's selling, what's breaking, and what should we make next.
It runs on Netlify (site ID inquisitive-brigadeiros-774b75), reads from the Rachel Bloom Supabase project, and refreshes every 5 minutes. It is gated by Supabase Auth, so only saul@ and rachel@ can see it. It works on phone and desktop.
Before this dashboard, supply chain data lived in three places: Shopify admin (variants and orders), a spreadsheet (production runs), and the CS team's heads (defects and complaints). Cross-referencing meant tab-switching, and forecasting meant guessing. The launch is May 15. We needed one place to look.
The headline view. KPIs at the top: On-Hand Bags (excludes accessories), Stock Value at COGS, On-Hand Accessories. Below: Top movers in last 30 days, Critical reorders flagged, Recent stock movements (every sale, adjustment, refund). This is the page Rachel opens first thing in the morning.
The catalog. Every active SKU listed with its sku_code, shopify_sku_string, product handle, category (bag / accessory / consumable), cost, and active flag. Has Bulk Tools at the top: Download CSV exports the full catalog. Upload CSV bulk-edits multiple SKUs at once with a diff preview before commit. The map button per row links our internal SKU to the Shopify variant ID for webhook decrement.
On-hand counts per SKU, color-coded by urgency. Each row is editable: click Edit to manually adjust on_hand, low_stock_threshold, or restock_threshold. Manual edits write a row to inventory_movements with movement_type='adjustment' so the audit trail is intact.
Run rates. For every active SKU we show units sold in last 7 / 14 / 30 / 90 days, velocity per day, velocity per week, and trend percentage (this 30d vs last 30d). Recomputed nightly via the inventory-velocity-recompute edge function plus on demand via dashboard refresh. Powered by the inventory_movements table back to November 2024.
The decision tab. SKUs sorted by reorder_urgency: critical (out of stock with active velocity), soon (less than 60 days runway), ok (more than 60 days runway), overstocked (excess stock vs velocity). The number to action on is days_of_stock_left. With our 60-day production lead time and 14-day safety buffer, anything under 74 days should already be on order.
Inbound shipments visualized as a calendar. Each production_order row appears on its expected_delivery date with the unit count. Currently shows: PO RB-2026-05-24 landing May 24 with 1,100 units (715 Crossbody, 77 each of the other 5 bags). Click any PO for line-item detail.
Customer service signal at the SKU level. Most-loved SKUs (positive sentiment count). Most-flagged SKUs (negative sentiment count). Issues are tagged by Harper (the AI CS lead) on every ticket, then aggregated here. Lets supply chain see if a particular variant has a quality issue before it shows up as returns.
Returns volume by SKU, by reason, by month. Tells us defect rate (returns as a percent of units sold) per variant. Useful for weeding out underperforming variants, spotting QC issues in a production run, and forecasting refund impact on cash flow.
New for v1.0. The defect signal feed. Every replacement request logged by the CS team flows here read-only: top SKUs by defect signal in last 30 days, breakdown by issue category (tech / leather / app / damaged delivery / changed mind / sizing / other), and the live open queue. The full lifecycle is managed from cs.rachelbloom.com (logging) and returns.rachelbloom.com (handling). A weekly summary email goes to saul@ and rachel@ every Monday at 9am ET with the previous week's stats.
Bloom Circle members are our highest-LTV signal. This tab shows which SKUs the Inner Circle and Circle members buy most, plus repeat-buyer rates per SKU. Currently sparse because the program just launched, but as the membership grows this becomes a forward indicator: SKUs that retain customers should be reordered preferentially. Currently 6 paying tier members.
The dashboard isn't decoration. It moves real data through real systems. Here's the plumbing.
| Source | What flows in | Refresh |
|---|---|---|
| Shopify webhook → inventory-shopify-webhook | Every order decrements stock. Refunds add back. | Real time |
| Shopify webhook → shopify-orders | Triple Pixel + creator commissions + Bloom Circle tier promotion | Real time |
| nightly cron: inventory-velocity-recompute | Recalculates run rates, days of stock left, urgency tiers | 6am UTC |
| nightly cron: inventory-reorder-alert | Emails Saul if any active SKU drops below safety threshold | 7am UTC |
| pg_cron: replacements-weekly-summary | Mondays 9am ET digest to saul@ and rachel@ | Weekly |
| Supabase Auth | Only saul@ and rachel@ can sign in | Per session |
| Table | What it holds |
|---|---|
| inventory_products | 12 product families (6 bags, 5 accessories, 1 consumable) |
| inventory_skus | 100 SKU rows. 30 active, 70 inactive future variants |
| inventory_stock | On-hand, incoming, low_stock_threshold per SKU |
| inventory_movements | Every stock change, audit log, going back to Nov 2024 |
| sku_velocity | Computed run rates and urgency tiers |
| production_orders + production_order_lines | Inbound POs with expected delivery and per-SKU allocation |
| sku_cs_signals | Customer service tickets tagged by SKU and sentiment |
| sku_returns | Returns tagged by SKU and reason |
| sku_loyalty_signals | Bloom Circle member purchases by SKU |
| replacements | New. Replacement requests with category, resolution, status |
inventory-shopify-webhook (sales decrement and refund add-back), inventory-velocity-recompute (run rate calc), inventory-reorder-alert (low stock email), inventory-update (manual stock edits from dashboard), inventory-bulk-upsert (CSV bulk edit), shopify-orders (Triple Pixel and commissions), replacements-weekly-summary (Monday digest).
The Rachel Bloom AI team has 8 members, each with a distinct role. Some interact with ops.rachelbloom.com data directly, some only indirectly through Ray's daily synthesis. This section lists them in order of how often they touch supply chain data.
Harper is the heaviest user of the ops data layer because she writes to it. When a customer emails about a defect, Harper runs the diagnostic gate, collects information, then escalates to Rachel with a structured replacement draft. That draft becomes a row in the replacements table, which surfaces in cs.rachelbloom.com (where Rachel reviews), returns.rachelbloom.com (where the returns team handles), and ops.rachelbloom.com (where it shows up as defect signal aggregated by SKU). Harper does not read the ops dashboard directly. She produces the data the dashboard reads.
Ray is the only AI team member who reads across every dashboard. He pulls inventory status, sales velocity, defect signals, returns volume, and Bloom Circle activity into the morning briefing emailed to the team daily at 11pm UTC. When Maya proposes a campaign or Josh runs his daily rundown, Ray's morning brief is the upstream context. If Crossbody is flagged critical, Ray flags it in the brief and downstream team members adjust their plans accordingly.
Maya needs stock signal before scheduling paid spend. Pushing $100/day on a Meta ad for a SKU that's about to stock out wastes budget and creates customer disappointment. Maya reads the Reorder Pacing tab via Ray's brief, pulls available units, and weights her campaign builder output toward variants that have at least 60 days of runway. When the May 24 inbound lands, Maya gets the signal first via Ray and shifts spend toward Crossbody.
Josh emails Saul a daily KPI rundown every morning. He reads ops.rachelbloom.com KPIs (On-Hand Bags, defect rate, critical SKU count) along with marketing and CS metrics, formats them into a one-page summary, and sends it. The dashboard's hard data feeds Josh's narrative.
Zara coordinates with creators on what to pitch. Her risk: getting an influencer excited about a product that's about to go out of stock. She reads stock levels and incoming production from Ray's brief before approving a creator brief. Once May 24 lands and Crossbody is back in stock, Zara prioritizes Crossbody in influencer pitches because that's where supply meets demand.
Celeste owns brand voice and quality positioning. Her relationship to ops data is through the Replacements tab. If tech defects on a particular SKU spike, that's a brand risk: customers experiencing a bag that doesn't lock as advertised will damage brand trust regardless of how Rachel resolves the individual case. Celeste reads weekly defect summaries and flags brand-level concerns to Rachel before they become PR issues.
Isabelle runs the Bloom Circle program. She reads the Loyalty x SKUs tab on ops.rachelbloom.com to understand which products retain members. Inner Circle preferences shape what Isabelle suggests as the next limited colorway, what gets exclusive early access, and what the retention nudge campaigns highlight. As the program grows past 6 paying members, this tab becomes one of the most valuable strategic inputs in the platform.
Jess organizes and prioritizes creative assets in the asset library. She reads Top Movers (30d) on the Overview tab to know which SKU images, lifestyle shots, and product videos to surface first in the library. Bestselling SKUs deserve the deepest creative coverage. Jess does not write to ops data, only reads.
This is the most common ops-relevant customer situation. Here's the full lifecycle, end to end, across systems.
Customer sends "my bag is broken" to help@rachelbloom.com. The Microsoft 365 mailbox forwards to GoDaddy, then to the rachelbloomcshelp@gmail.com Gmail account, which is polled every 5 minutes by a Make.com scenario. Make.com calls the receive-cs-email edge function with the sender, subject, and body, which writes a row to cs_tickets with status='open'.
Within seconds of the row landing, Harper picks up the ticket via the AI handle flow on cs.rachelbloom.com. She reads the message and runs the diagnostic gate: does this email contain enough detail to characterize the issue (specific symptom, when it started, order number, which bag, photos)? "My bag is broken" by itself does NOT pass the gate.
Harper drafts a warm, brief reply asking the customer for the missing details. She does NOT escalate. The ticket stays in status='ai_handled'. The customer receives a personalized email asking what specifically is happening, when it started, their order number, which bag, and offering them to attach photos by replying.
"Thanks for reaching out. The fingerprint reader stopped responding after 3 weeks of use. Order #1167. The Smart Crossbody in Black with GPS." That reply lands in the same ticket thread. Harper reads it.
Now Harper has enough info. She generates a holding email to the customer ("Rachel will be in touch within 24 hours"), updates the ticket to status='needs_review', notifies saul@ + rachel@, AND outputs an internal-only structured replacement draft. The dashboard parses that draft and creates a new row in the replacements table with: ticket_id linked to this ticket, customer email and name carried over, order number, SKU (the-smart-crossbody-black-gps-yes), issue_category='tech', issue_description='Fingerprint reader stopped responding after 3 weeks of use', resolution_type='replacement', status='pending'. Internal notes flag it as auto-drafted by Harper.
Rachel sees the ticket in the Urgent tab on cs.rachelbloom.com (it's needs_review, that's the badge). She also sees the auto-drafted replacement in the Replacements tab on cs.rachelbloom.com, marked pending. She clicks it, confirms the category and resolution, optionally adjusts internal notes, and saves. The ticket and the replacement record are linked via ticket_id.
The returns team (working from returns.rachelbloom.com) sees a new pending replacement in the Replacements panel. They open it, change status to in_progress, ship a replacement bag, enter the tracking number, change status to shipped. The customer receives a separate email from the returns flow with the tracking link.
Meanwhile, ops.rachelbloom.com Replacements tab now shows: tech defects up by one for the-smart-crossbody-black-gps-yes in last 30 days. If 3 customers report the same issue on the same SKU in the same week, the Top SKUs by Defect Signal table flags it visibly. Saul sees the pattern, talks to Sanket about the fingerprint module, talks to the supplier about the production run.
Customer receives the replacement, marks the ticket resolved (or Rachel marks it resolved on their behalf). The replacement status moves to completed. The completed_at timestamp records resolution time. Average days to resolve appears in the By Issue Category table, which becomes the SLA metric for tech defects. If avg days creeps up, that's a returns team capacity issue.
Monday at 9am ET, the replacements-weekly-summary edge function fires. The customer's case appears in the digest emailed to saul@ + rachel@: 1 new tech replacement on Crossbody, average resolution time, top SKU by defect signal, plus week-over-week trend. The Blooms see the picture without opening a dashboard.
Login is required. Only saul@rachelbloom.com and rachel@rachelbloom.com can sign in. Sessions persist across browser refreshes via Supabase Auth tokens. Sign out clears the session. Activity is logged to the activity_log table for every sign-in.
RLS is enabled on the replacements table. Read and write require an authenticated session with one of the admin emails. Service role bypasses RLS for cron jobs and edge functions.
All inventory tables are read-only via the anon key (used by the dashboard for SELECTs), and write operations route through edge functions that check authentication.
The current dashboard handles the core supply chain workflow end to end. Things on the roadmap once we're past launch: