Automation Opportunity Map
Business: Research Relay LLC -- RUO peptide / research chemical e-commerce
Stack: MedusaJS v2 + BTCPay Server + Mercury + Zoho Books Free + Zoho Mail + Cloudflare
Prepared: February 2026
This document maps every automation opportunity across Research Relay's operations. Each entry identifies the manual task being eliminated, the tools needed, and a prioritized implementation plan.
Priority definitions:
- High -- eliminates daily manual work (saves 15+ minutes/day)
- Medium -- eliminates weekly manual work (saves 30+ minutes/week)
- Low -- nice-to-have, reduces occasional friction
Complexity definitions:
- Simple -- single webhook, API call, or event subscriber
- Medium -- custom MedusaJS module or multi-step workflow
- Complex -- multi-system integration requiring API orchestration across 2+ external services
Effort sizing:
- S -- less than 1 day
- M -- 1-3 days
- L -- 3-5 days
- XL -- 1-2 weeks
1. Order Lifecycle
1.1 Order Confirmation Email
| Attribute |
Detail |
| What it automates |
Manually checking for new orders and sending confirmation emails |
| Current process |
Check Medusa Admin twice daily, no automated email on order placement |
| Tools/integrations |
MedusaJS subscriber on order.placed event, Notification Module (SendGrid provider), email template |
| MedusaJS approach |
src/subscribers/order-placed.ts listens to order.placed, executes a workflow that calls sendNotificationsStep with order details, customer email, and RUO disclaimer footer |
| Priority |
High |
| Complexity |
Simple |
| Effort |
S |
| Dependencies |
SendGrid account, notification module provider configured in medusa-config.ts |
1.2 Fulfillment Created Notification
| Attribute |
Detail |
| What it automates |
Manually emailing customers when their order is packed and ready to ship |
| Current process |
Operator creates fulfillment in Medusa Admin, then manually emails customer |
| Tools/integrations |
MedusaJS subscriber on order.fulfillment_created event, Notification Module |
| MedusaJS approach |
src/subscribers/fulfillment-created.ts triggers a workflow that fetches fulfillment details and sends notification with shipping method and expected timeline |
| Priority |
High |
| Complexity |
Simple |
| Effort |
S |
| Dependencies |
SendGrid configured, email template with RUO disclaimer |
1.3 Shipping Tracking Update Email
| Attribute |
Detail |
| What it automates |
Manually entering tracking numbers and notifying customers of shipment |
| Current process |
Generate label in ShipStation, copy tracking number to Medusa Admin, manually email customer |
| Tools/integrations |
ShipStation webhook for label creation, MedusaJS custom API route to receive webhook, subscriber to send tracking email |
| MedusaJS approach |
Custom API route POST /hooks/shipstation receives ShipStation webhook with tracking info, updates fulfillment via createOrderShipmentWorkflow, which emits an event triggering tracking email |
| Priority |
High |
| Complexity |
Medium |
| Effort |
M |
| Dependencies |
ShipStation integration, SendGrid configured |
1.4 Delivery Confirmation Email
| Attribute |
Detail |
| What it automates |
Monitoring carrier tracking to confirm delivery and notify customer |
| Current process |
Manually check tracking 24hrs post-ship, no delivery confirmation sent |
| Tools/integrations |
Scheduled job polling carrier APIs (via ShipStation tracking API), MedusaJS markOrderFulfillmentAsDeliveredWorkflow, Notification Module |
| MedusaJS approach |
src/jobs/check-deliveries.ts runs every 4 hours, queries ShipStation for delivered shipments, marks fulfillments as delivered in Medusa, triggers delivery confirmation email including COA download link |
| Priority |
Medium |
| Complexity |
Medium |
| Effort |
M |
| Dependencies |
ShipStation tracking API access, carrier tracking integration |
1.5 Post-Delivery Review / Feedback Request
| Attribute |
Detail |
| What it automates |
No current process for soliciting customer feedback |
| Current process |
None -- no feedback collection |
| Tools/integrations |
MedusaJS scheduled job, Notification Module, custom review_request_sent metadata on order |
| MedusaJS approach |
src/jobs/send-review-requests.ts runs daily, finds orders delivered 7+ days ago that have not had a review request sent (check order metadata), sends a feedback email, marks order metadata review_request_sent: true |
| Priority |
Low |
| Complexity |
Medium |
| Effort |
M |
| Dependencies |
Delivery confirmation automation (1.4) must be implemented first |
1.6 BTC Payment Status Automation
| Attribute |
Detail |
| What it automates |
Manually checking BTCPay Server dashboard for payment confirmations and updating Medusa |
| Current process |
Check BTCPay dashboard, manually verify payment status against Medusa orders |
| Tools/integrations |
BTCPay Server Greenfield API webhooks (InvoiceSettled, InvoiceProcessing, InvoiceExpired), MedusaJS payment provider webhook handler |
| MedusaJS approach |
BTCPay payment provider's getWebhookActionAndData() method processes incoming webhooks at /hooks/payment/btcpay_btcpay, automatically updating payment status to authorized/captured/failed in Medusa |
| Priority |
High |
| Complexity |
Simple (built into payment provider) |
| Effort |
S (part of BTCPay provider implementation) |
| Dependencies |
BTCPay payment module provider, webhook secret configured |
2. Inventory Management
2.1 Low Stock Alerts
| Attribute |
Detail |
| What it automates |
Manually checking inventory levels across all SKUs daily |
| Current process |
Part of daily morning routine -- manually scan Medusa Admin inventory page for low items |
| Tools/integrations |
MedusaJS scheduled job, Inventory Module service, Notification Module |
| MedusaJS approach |
src/jobs/low-stock-alert.ts runs daily at 7 AM, queries inventoryModuleService.listInventoryLevels() for items where stocked_quantity - reserved_quantity < reorder_threshold (threshold stored in product metadata), sends email summary via Notification Module |
| Priority |
High |
| Complexity |
Simple |
| Effort |
S |
| Dependencies |
Reorder threshold metadata on products |
2.2 Reorder Point Trigger Notifications
| Attribute |
Detail |
| What it automates |
Mentally tracking which products need reordering and when to contact suppliers |
| Current process |
Note low-stock items during end-of-day reconciliation, manually contact suppliers |
| Tools/integrations |
Extension of low stock alert (2.1), pre-formatted supplier email draft via Notification Module |
| MedusaJS approach |
When stock drops below reorder point, the low-stock workflow generates a supplier-specific reorder email draft with product name, SKU, suggested quantity (based on 30-day sales velocity), and supplier contact info (stored in product metadata) |
| Priority |
Medium |
| Complexity |
Medium |
| Effort |
M |
| Dependencies |
Low stock alert (2.1), supplier contact info in product metadata, sales velocity calculation |
2.3 Lot / Batch Tracking
| Attribute |
Detail |
| What it automates |
Manual tracking of which lot numbers are shipped with which orders (currently paper-based or ad hoc) |
| Current process |
Operator manually records lot numbers during pick-and-pack |
| Tools/integrations |
Custom Lot module in MedusaJS (data model + service), Module Link to Inventory Item, custom admin widget |
| MedusaJS approach |
src/modules/lot/ defines a Lot model with lot_number, manufacture_date, expiry_date, purity_percentage, coa_url. Linked to Inventory Items via Module Link. Admin widget on order fulfillment page allows selecting lot number during fulfillment creation. Lot number stored on fulfillment metadata. |
| Priority |
High |
| Complexity |
Medium |
| Effort |
L |
| Dependencies |
Custom module implementation, database migration |
2.4 Expiration Date Tracking and Alerts
| Attribute |
Detail |
| What it automates |
Manually checking product expiration dates to avoid shipping expired stock |
| Current process |
Part of pick-and-pack visual inspection; no systematic tracking |
| Tools/integrations |
MedusaJS scheduled job querying Lot module, Notification Module |
| MedusaJS approach |
src/jobs/expiry-alert.ts runs daily, queries Lot module for lots where expiry_date is within 30/60/90 days, sends graduated alerts: 90 days (info), 30 days (warning -- stop selling), expired (critical -- pull from inventory). Automatically sets stocked_quantity to 0 for expired lots if auto-quarantine is enabled. |
| Priority |
High |
| Complexity |
Medium |
| Effort |
M |
| Dependencies |
Lot module (2.3) must be implemented first |
2.5 Inventory Reconciliation Report
| Attribute |
Detail |
| What it automates |
End-of-day manual comparison of Medusa inventory counts vs physical stock |
| Current process |
Part of end-of-day reconciliation (10-15 min daily) |
| Tools/integrations |
MedusaJS scheduled job, custom admin page |
| MedusaJS approach |
src/jobs/inventory-reconciliation.ts runs nightly, generates a report of all inventory changes for the day (fulfilled, returned, adjusted), discrepancies between expected and actual counts (if physical count is entered via admin), and emails summary |
| Priority |
Low |
| Complexity |
Medium |
| Effort |
M |
| Dependencies |
Custom admin page for physical count entry |
3. Financial Automation
3.1 Mercury Bank Transaction Sync to Zoho Books
| Attribute |
Detail |
| What it automates |
Manually downloading Mercury CSV statements and importing into Zoho Books, or manually categorizing transactions |
| Current process |
Weekly manual CSV export from Mercury, import to Zoho Books, manually categorize each transaction |
| Tools/integrations |
Mercury API (read-only token, /transactions endpoint), Mercury webhooks (transaction events), Zoho Books API (POST /banktransactions), custom integration script |
| MedusaJS approach |
External scheduled script (not inside Medusa -- this is bank-to-accounting, not e-commerce). Cron job or Node.js script runs daily: fetches new Mercury transactions via API, maps to Zoho Books categories using rules (e.g., "Stripe" = revenue, "USPS" = shipping expense), creates bank transactions in Zoho Books via API. Alternative: Mercury webhook pushes transaction events to a small webhook handler that writes to Zoho Books in real-time. |
| Priority |
High |
| Complexity |
Complex |
| Effort |
L |
| Dependencies |
Mercury API key (read-only), Zoho Books API OAuth2 tokens, category mapping rules |
3.2 Invoice Generation (Medusa Orders to Zoho Books)
| Attribute |
Detail |
| What it automates |
Manually creating invoices in Zoho Books for each Medusa order |
| Current process |
No automated invoice creation; orders exist only in Medusa |
| Tools/integrations |
MedusaJS subscriber on order.placed, Zoho Books API (POST /invoices), custom workflow |
| MedusaJS approach |
src/subscribers/order-to-invoice.ts listens to order.placed, executes a workflow that: (1) fetches full order details via Query, (2) maps order line items to Zoho Books invoice line items, (3) creates invoice in Zoho Books via REST API, (4) stores Zoho Books invoice ID in order metadata for cross-reference |
| Priority |
High |
| Complexity |
Complex |
| Effort |
L |
| Dependencies |
Zoho Books API OAuth2 setup, customer mapping between Medusa and Zoho Books |
3.3 Tax Estimation Tracking
| Attribute |
Detail |
| What it automates |
Manually calculating estimated quarterly tax payments based on revenue |
| Current process |
Monthly mental math or spreadsheet calculation |
| Tools/integrations |
MedusaJS scheduled job, Order Module queries, Notification Module |
| MedusaJS approach |
src/jobs/tax-estimate.ts runs on the 1st of each month. Queries all orders for the period, sums tax collected, calculates estimated liability (CA franchise tax, federal self-employment tax, CA income tax), compares against quarterly payment thresholds, sends summary email with amounts due and deadlines |
| Priority |
Medium |
| Complexity |
Medium |
| Effort |
M |
| Dependencies |
Tax rate configuration, order data with tax line items |
3.4 BTC Revenue Fair Market Value Tracking
| Attribute |
Detail |
| What it automates |
Manually looking up BTC price at time of each payment for accounting and tax purposes |
| Current process |
Monthly export BTCPay CSV, manually look up FMV for each transaction |
| Tools/integrations |
MedusaJS subscriber on BTC payment capture, external price API (CoinGecko/BTCPay rate), custom metadata |
| MedusaJS approach |
When BTCPay webhook fires InvoiceSettled, the payment provider stores btc_amount, usd_fmv, exchange_rate, and settlement_timestamp in the payment session data. A monthly scheduled job src/jobs/btc-revenue-report.ts aggregates all BTC payments, calculates total FMV revenue, and exports to CSV for Koinly import and Zoho Books posting. |
| Priority |
High |
| Complexity |
Medium |
| Effort |
M |
| Dependencies |
BTCPay payment provider implementation, price API access |
3.5 Stripe Payout Reconciliation
| Attribute |
Detail |
| What it automates |
Manually matching Stripe payouts to Mercury bank deposits |
| Current process |
Check Stripe Dashboard for payouts, match to Mercury deposits by amount and date |
| Tools/integrations |
Stripe API (/payouts, /balance_transactions), Mercury API (/transactions), reconciliation script |
| MedusaJS approach |
External scheduled script (weekly). Fetches Stripe payouts via API, fetches Mercury deposits, auto-matches by amount and date range (+/- 2 days), flags unmatched transactions, emails reconciliation report. |
| Priority |
Medium |
| Complexity |
Complex |
| Effort |
L |
| Dependencies |
Stripe API key, Mercury API key, tolerance rules for matching |
4. Customer Communications
4.1 Welcome Email on Account Creation
| Attribute |
Detail |
| What it automates |
No current welcome email for new customer accounts |
| Current process |
None |
| Tools/integrations |
MedusaJS subscriber on customer.created event, Notification Module |
| MedusaJS approach |
src/subscribers/customer-welcome.ts listens to customer.created, sends welcome email with: store introduction, RUO product disclaimer, link to COA page, link to support |
| Priority |
Medium |
| Complexity |
Simple |
| Effort |
S |
| Dependencies |
SendGrid configured, email template |
4.2 Abandoned Cart Recovery
| Attribute |
Detail |
| What it automates |
No current abandoned cart recovery process |
| Current process |
None -- carts expire silently |
| Tools/integrations |
MedusaJS scheduled job, Cart Module queries, Notification Module |
| MedusaJS approach |
src/jobs/abandoned-cart-recovery.ts runs every 6 hours. Queries carts that: (a) have items, (b) have a customer email, (c) were last updated 2-24 hours ago, (d) have not been completed. Sends a reminder email with cart contents and link to resume checkout. Stores recovery_email_sent in cart metadata to avoid duplicates. Only sends one reminder per cart. |
| Priority |
Medium |
| Complexity |
Medium |
| Effort |
M |
| Dependencies |
Cart must capture email before abandonment (guest checkout email step), SendGrid |
4.3 RUO Compliance Reminder on Repeat Orders
| Attribute |
Detail |
| What it automates |
Ensuring repeat customers re-acknowledge RUO terms periodically |
| Current process |
Checkout acknowledgment checkbox only on initial purchase |
| Tools/integrations |
MedusaJS workflow hook on completeCartWorkflow, customer metadata tracking |
| MedusaJS approach |
Workflow hook checks if customer's last RUO acknowledgment is older than 90 days. If so, the checkout flow requires a fresh acknowledgment before completion. Stored as ruo_acknowledged_at timestamp in customer metadata. |
| Priority |
Low |
| Complexity |
Medium |
| Effort |
M |
| Dependencies |
Custom checkout acknowledgment step, customer metadata |
4.4 COA Delivery Automation
| Attribute |
Detail |
| What it automates |
Manually attaching or linking COA documents in packing slip prep and customer emails |
| Current process |
Print COA during pack step, or manually include COA URL in shipping notification |
| Tools/integrations |
Lot module COA URL field, order fulfillment workflow hook, Notification Module |
| MedusaJS approach |
When fulfillment is created, a workflow hook looks up the lot(s) assigned to the fulfilled items, retrieves COA URLs from the Lot module, and includes them in the shipping notification email. Also generates a "Your COAs" section on the customer's order detail page in the storefront. |
| Priority |
Medium |
| Complexity |
Medium |
| Effort |
M |
| Dependencies |
Lot module (2.3) with COA URLs populated |
5. Compliance Monitoring
5.1 Website Content Scanning for Prohibited Claims
| Attribute |
Detail |
| What it automates |
Periodic manual review of website content for language that could imply therapeutic, diagnostic, or medical claims |
| Current process |
Ad hoc review during content updates |
| Tools/integrations |
Scheduled script scanning product descriptions, MedusaJS Product Module queries, keyword matching |
| MedusaJS approach |
src/jobs/compliance-scan.ts runs weekly. Fetches all product titles, descriptions, and metadata via Product Module service. Scans for prohibited keywords and phrases: "cure", "treat", "heal", "therapy", "therapeutic", "diagnosis", "prevent", "weight loss", "anti-aging", "FDA approved", dosage terms ("mg/kg", "inject", "administer"), and health claims. Generates a compliance report email listing flagged content with product links for review. |
| Priority |
High |
| Complexity |
Medium |
| Effort |
M |
| Dependencies |
Prohibited keyword dictionary (maintained as config), Product Module access |
5.2 Product Listing Compliance Check
| Attribute |
Detail |
| What it automates |
Verifying that every product page has required RUO elements: disclaimer, COA link, proper labeling |
| Current process |
Manual spot-check during product creation/update |
| Tools/integrations |
MedusaJS subscriber on product.created and product.updated, validation workflow |
| MedusaJS approach |
src/subscribers/product-compliance-check.ts triggers on product create/update events. A workflow checks: (a) RUO disclaimer is present in description, (b) COA link exists in metadata, (c) product category is valid, (d) no prohibited keywords in title/description (reuse scan from 5.1). If any check fails, sends an alert email and optionally sets product status to draft to prevent publishing until corrected. |
| Priority |
High |
| Complexity |
Medium |
| Effort |
M |
| Dependencies |
Product metadata standards defined, keyword dictionary from 5.1 |
5.3 Customer RUO Acknowledgment Audit
| Attribute |
Detail |
| What it automates |
Verifying that all completed orders have valid RUO acknowledgments on file |
| Current process |
Assumed during checkout, no systematic verification |
| Tools/integrations |
MedusaJS scheduled job, Order Module queries, customer metadata |
| MedusaJS approach |
src/jobs/ruo-acknowledgment-audit.ts runs weekly. Checks all orders from the past 7 days against customer RUO acknowledgment records. Flags any orders where acknowledgment is missing or expired. Generates an audit trail report. |
| Priority |
Low |
| Complexity |
Simple |
| Effort |
S |
| Dependencies |
RUO acknowledgment tracking in customer/order metadata |
6. Reporting
6.1 Daily Sales Summary
| Attribute |
Detail |
| What it automates |
Manually tallying daily sales by checking Medusa Admin orders |
| Current process |
Part of end-of-day reconciliation (manually counting orders, revenue) |
| Tools/integrations |
MedusaJS scheduled job, Order Module queries, Notification Module |
| MedusaJS approach |
src/jobs/daily-sales-summary.ts runs at 11 PM daily. Queries all orders placed/completed in the past 24 hours. Calculates: total revenue (by payment method: BTC vs Stripe), order count, average order value, top selling products, new vs returning customers. Sends formatted email summary. |
| Priority |
High |
| Complexity |
Medium |
| Effort |
M |
| Dependencies |
Order Module access, SendGrid |
6.2 Weekly Financial Snapshot
| Attribute |
Detail |
| What it automates |
Manually compiling weekly financial overview from multiple sources |
| Current process |
Check Mercury balance, check Stripe balance, check BTCPay balance, calculate revenue |
| Tools/integrations |
MedusaJS scheduled job, Mercury API (/accounts), Stripe API (/balance), BTCPay Greenfield API (wallet balance), Notification Module |
| MedusaJS approach |
src/jobs/weekly-financial-snapshot.ts runs Sunday at 8 PM. Fetches: Mercury account balance, Stripe available balance, BTCPay on-chain + Lightning balances. Queries Medusa for weekly revenue, refunds, and tax collected. Compiles into a single email: cash positions, revenue trend (vs prior week), outstanding orders, refund rate. |
| Priority |
High |
| Complexity |
Complex |
| Effort |
L |
| Dependencies |
Mercury API key, Stripe API key, BTCPay Greenfield API key, all integrations active |
6.3 Monthly P&L Report
| Attribute |
Detail |
| What it automates |
Manually generating monthly profit and loss from Zoho Books and Medusa data |
| Current process |
Monthly Zoho Books P&L report generation (manual) |
| Tools/integrations |
Zoho Books API (/reports), MedusaJS scheduled job or external script |
| MedusaJS approach |
External script or Medusa scheduled job runs on the 1st of each month. If Zoho Books integration (3.2) is active, fetches P&L from Zoho Books API. Otherwise, generates a P&L-style report from Medusa order data: revenue by product category, COGS (from product metadata), gross margin, shipping costs, refunds, payment processing fees. Sends formatted email. |
| Priority |
Medium |
| Complexity |
Complex |
| Effort |
L |
| Dependencies |
Either Zoho Books API integration or product cost metadata in Medusa |
6.4 Tax Liability Tracking Dashboard
| Attribute |
Detail |
| What it automates |
Manually tracking sales tax collected, estimated income tax, and quarterly payment deadlines |
| Current process |
Spreadsheet or mental tracking |
| Tools/integrations |
MedusaJS custom admin UI route, Order Module queries with tax line aggregation |
| MedusaJS approach |
src/admin/routes/ops/tax-dashboard/page.tsx custom admin page. Displays: total sales tax collected YTD by jurisdiction, estimated quarterly income tax based on profit, next quarterly payment deadline with amount due, running total vs prior year. |
| Priority |
Medium |
| Complexity |
Medium |
| Effort |
L |
| Dependencies |
Order tax data, tax rate configuration |
7. Infrastructure
7.1 Uptime Monitoring
| Attribute |
Detail |
| What it automates |
Manually checking that Medusa, BTCPay, and storefront are online |
| Current process |
No systematic monitoring; discover issues when something breaks |
| Tools/integrations |
Uptime Kuma (self-hosted) or external monitoring service, webhook notifications |
| MedusaJS approach |
Not MedusaJS-native. Deploy Uptime Kuma on the same NixOS server or a separate VPS. Monitor: (a) MedusaJS Store API health endpoint, (b) MedusaJS Admin panel, (c) BTCPay Server, (d) Storefront, (e) Lightning node (CLN REST). Alert via email and/or Slack webhook on downtime. |
| Priority |
High |
| Complexity |
Simple |
| Effort |
S |
| Dependencies |
Uptime Kuma or equivalent, health check endpoints |
7.2 SSL Certificate Renewal
| Attribute |
Detail |
| What it automates |
Manually renewing SSL certificates before expiration |
| Current process |
Let's Encrypt with auto-renewal via Caddy or nginx ACME, but no alerting on failure |
| Tools/integrations |
NixOS security.acme module (auto-renewal), Uptime Kuma SSL expiry monitoring |
| MedusaJS approach |
Not MedusaJS-native. Configure Uptime Kuma to monitor SSL certificate expiry for all domains (research-relay.com, btcpay.research-relay.com). Alert 14 days before expiry. Let's Encrypt ACME handles actual renewal automatically. |
| Priority |
Medium |
| Complexity |
Simple |
| Effort |
S |
| Dependencies |
Uptime Kuma, ACME configured on server |
7.3 Database Backup Verification
| Attribute |
Detail |
| What it automates |
Trusting that database backups are running without verification |
| Current process |
pg_dump cron job exists but no verification that backups are valid |
| Tools/integrations |
NixOS systemd timer, backup validation script, Notification Module or external alerting |
| MedusaJS approach |
Not MedusaJS-native. NixOS systemd service runs after nightly backup: (a) verifies backup file exists and has non-zero size, (b) optionally restores to a temp database and runs a basic query to verify integrity, (c) checks backup age is less than 25 hours, (d) sends alert email if any check fails. |
| Priority |
High |
| Complexity |
Simple |
| Effort |
S |
| Dependencies |
Existing backup cron job, email alerting |
7.4 Lightning Channel Health Monitoring
| Attribute |
Detail |
| What it automates |
Manually checking RTL dashboard for channel status, inbound liquidity, and node connectivity |
| Current process |
Quick daily scan of BTCPay/RTL dashboard as part of morning routine |
| Tools/integrations |
CLN REST API (or lightning-cli), scheduled monitoring script, email/webhook alerts |
| MedusaJS approach |
Not MedusaJS-native. NixOS systemd timer runs every 4 hours: queries CLN for (a) number of active channels, (b) total inbound liquidity (alert if below 500K sats), (c) node uptime, (d) any pending force-closes. Sends alert if any threshold is breached. Can also be a MedusaJS scheduled job if CLN API is reachable from Medusa server. |
| Priority |
Medium |
| Complexity |
Medium |
| Effort |
M |
| Dependencies |
CLN REST API access, monitoring thresholds defined |
7.5 Automated Server Health Checks
| Attribute |
Detail |
| What it automates |
Discovering server resource issues (disk full, memory pressure, CPU saturation) after they cause problems |
| Current process |
No proactive monitoring |
| Tools/integrations |
NixOS systemd timer, basic resource checks, email alerts |
| MedusaJS approach |
Not MedusaJS-native. System-level monitoring script checks: disk usage (alert >80%), memory usage (alert >85%), PostgreSQL connection count, Redis memory, Bitcoin sync status. Runs hourly. |
| Priority |
Medium |
| Complexity |
Simple |
| Effort |
S |
| Dependencies |
NixOS systemd, email sending capability from server |
8. Supplier Management
8.1 COA Collection Automation
| Attribute |
Detail |
| What it automates |
Manually requesting, downloading, and filing COAs from suppliers for each batch |
| Current process |
Email supplier for COA, download PDF, manually upload to file storage and link to product/lot |
| Tools/integrations |
Zoho Mail integration (or email parsing), File Module, Lot module |
| MedusaJS approach |
Partial automation. Scheduled job src/jobs/coa-collection-reminder.ts runs weekly. Checks Lot module for lots missing COA URLs. Generates a pre-filled email draft to the supplier requesting COA for specific lot numbers. Operator sends the email. When COA is received, operator uploads via admin widget and links to lot. Full automation (email parsing + auto-upload) is possible but complex. |
| Priority |
Medium |
| Complexity |
Simple (reminder) / Complex (full parsing) |
| Effort |
S (reminder) / XL (full parsing) |
| Dependencies |
Lot module (2.3), supplier contact info in metadata |
8.2 Reorder Point Calculations
| Attribute |
Detail |
| What it automates |
Manually calculating when to reorder based on gut feel or rough estimates |
| Current process |
"Note any items approaching reorder threshold" during daily reconciliation |
| Tools/integrations |
MedusaJS scheduled job, Order Module queries (sales velocity), Inventory Module |
| MedusaJS approach |
src/jobs/reorder-calculations.ts runs weekly. For each SKU: (a) calculates 30-day rolling average daily sales from order line items, (b) retrieves supplier lead time from product metadata, (c) calculates reorder point = (daily sales * lead time) + safety stock, (d) compares against current stocked_quantity, (e) generates a reorder recommendation report with suggested quantities and estimated cost. |
| Priority |
Medium |
| Complexity |
Medium |
| Effort |
M |
| Dependencies |
Supplier lead time in product metadata, sufficient order history for velocity calculation |
8.3 Supplier Price Tracking
| Attribute |
Detail |
| What it automates |
Manually comparing supplier pricing over time, or not tracking at all |
| Current process |
No systematic price tracking |
| Tools/integrations |
Custom module for supplier pricing history, admin UI |
| MedusaJS approach |
Custom SupplierPrice module with fields: supplier_name, product_sku, unit_price, effective_date, currency, notes. Linked to Product via Module Link. Admin widget on product page shows price history chart. Scheduled job alerts when a new price exceeds the prior price by more than 10%. |
| Priority |
Low |
| Complexity |
Medium |
| Effort |
L |
| Dependencies |
Custom module implementation, manual price entry (or supplier API if available) |
Priority Summary
High Priority (Daily Time Savings)
| ID |
Automation |
Effort |
Complexity |
| 1.1 |
Order confirmation email |
S |
Simple |
| 1.2 |
Fulfillment notification |
S |
Simple |
| 1.3 |
Shipping tracking update |
M |
Medium |
| 1.6 |
BTC payment status automation |
S |
Simple |
| 2.1 |
Low stock alerts |
S |
Simple |
| 2.3 |
Lot / batch tracking |
L |
Medium |
| 2.4 |
Expiration date alerts |
M |
Medium |
| 3.1 |
Mercury to Zoho Books sync |
L |
Complex |
| 3.2 |
Medusa orders to Zoho invoices |
L |
Complex |
| 3.4 |
BTC revenue FMV tracking |
M |
Medium |
| 5.1 |
Website compliance scanning |
M |
Medium |
| 5.2 |
Product listing compliance check |
M |
Medium |
| 6.1 |
Daily sales summary |
M |
Medium |
| 6.2 |
Weekly financial snapshot |
L |
Complex |
| 7.1 |
Uptime monitoring |
S |
Simple |
| 7.3 |
Backup verification |
S |
Simple |
Medium Priority (Weekly Time Savings)
| ID |
Automation |
Effort |
Complexity |
| 1.4 |
Delivery confirmation email |
M |
Medium |
| 2.2 |
Reorder point notifications |
M |
Medium |
| 3.3 |
Tax estimation tracking |
M |
Medium |
| 3.5 |
Stripe payout reconciliation |
L |
Complex |
| 4.1 |
Welcome email |
S |
Simple |
| 4.2 |
Abandoned cart recovery |
M |
Medium |
| 4.4 |
COA delivery automation |
M |
Medium |
| 6.3 |
Monthly P&L report |
L |
Complex |
| 6.4 |
Tax liability dashboard |
L |
Medium |
| 7.2 |
SSL cert monitoring |
S |
Simple |
| 7.4 |
Lightning channel health |
M |
Medium |
| 7.5 |
Server health checks |
S |
Simple |
| 8.1 |
COA collection reminders |
S |
Simple |
| 8.2 |
Reorder point calculations |
M |
Medium |
Low Priority (Nice-to-Have)
| ID |
Automation |
Effort |
Complexity |
| 1.5 |
Post-delivery review request |
M |
Medium |
| 2.5 |
Inventory reconciliation report |
M |
Medium |
| 4.3 |
RUO compliance reminder (repeat) |
M |
Medium |
| 5.3 |
RUO acknowledgment audit |
S |
Simple |
| 8.3 |
Supplier price tracking |
L |
Medium |
Implementation Sequence Recommendation
Wave 1: Quick Wins (Week 1-2)
Focus on Simple/S-effort items that eliminate daily friction:
- 1.1 Order confirmation email (subscriber + SendGrid)
- 1.2 Fulfillment notification (subscriber + SendGrid)
- 1.6 BTC payment webhook handling (part of payment provider)
- 2.1 Low stock alerts (scheduled job)
- 7.1 Uptime monitoring (Uptime Kuma deployment)
- 7.3 Backup verification (systemd script)
Estimated effort: 3-5 days total
Wave 2: Core Operations (Week 3-5)
Build the custom modules and medium-complexity automations:
- 2.3 Lot / batch tracking module
- 2.4 Expiration date tracking (depends on 2.3)
- 1.3 Shipping tracking update (ShipStation webhook)
- 5.1 Website compliance scanning
- 5.2 Product listing compliance check
- 6.1 Daily sales summary
- 3.4 BTC revenue FMV tracking
Estimated effort: 2-3 weeks total
Wave 3: Financial Integration (Week 6-8)
Multi-system integrations that require API orchestration:
- 3.2 Medusa to Zoho Books invoice sync
- 3.1 Mercury to Zoho Books transaction sync
- 6.2 Weekly financial snapshot
- 4.2 Abandoned cart recovery
- 4.1 Welcome email
Estimated effort: 2-3 weeks total
Wave 4: Polish and Scale (Week 9+)
Refinements and lower-priority items:
- 1.4 Delivery confirmation email
- 4.4 COA delivery automation
- 8.2 Reorder point calculations
- 3.3 Tax estimation tracking
- 6.4 Tax liability dashboard
- Remaining low-priority items as needed
Estimated effort: Ongoing, 1-2 items per week