Original Combined Lesson

AmazonOps Onboarding Lesson for Franz

Audience: Franz, also known as angrycat.ron. Purpose: help you read the AmazonOps dashboard calmly, accurately, and safely while supporting Brent and Fergus overnight.

Important safety disclaimer: do not be scared. The work you are learning here is local dashboard reading, data interpretation, and escalation. It is not live-store modification. Do not change prices, SKUs, listings, shipments, payments, inventory, Seller Central data, or anything else in Amazon. Route any sensitive Amazon action through Fergus or Brent approval first. When in doubt, ask before acting.

1. The mental model

AmazonOps is a read-only operations dashboard for The Natural Life. It pulls official Amazon SP-API data, local generated datasets, Keepa-derived history, doTERRA reference data, and warehouse/order artifacts into one place so the team can make better decisions.

Think of it as three layers:

1. Data layer: JSON files and generated reports in `/Users/fergus/Projects/amazonops/data`, plus official API reads and local history.
2. Tile layer: each tile is a focused window into one business question, such as MAP violations, restock urgency, warehouse stock, or prep workflow.
3. Row and surface layer: rows group tiles by workflow, and surfaces decide who needs to see them: Seller Tools, Brand Tools, Warehouse Tools, MAP Tools, and WIP Tools.

The repository’s own README and spec repeat the key rule: AmazonOps is read-only against Amazon. Reads and fee estimates are allowed. Listing edits, price changes, inventory updates, buyer messages, shipment creation, and account modification are forbidden.

2. How rows work

Rows are not decoration. Rows are workflow lanes.

A row answers, “Why would someone open these tiles together?” Examples:

• New Tiles: staging row. New or recently expanded tiles land here first so Brent and Fergus can inspect them before promoting them.
• Seller Tools: day-to-day seller operations, buy box, catalog health, sales, pricing, and account performance.
• Brand Tools: brand-side visibility, MAP monitoring, authorized seller coverage, and revenue intelligence.
• MAP Violations: focused row for all-seller MAP breaks and pricing intelligence.
• Warehouse: physical stock, SKU mapping, order form, restock dashboard, and prep workflow.
• Inventory Management: FBA and aging inventory views.
• Under Construction: active prototypes and risky or incomplete tiles. Use with caution.

New concept: a tile or row can appear in multiple surfaces when it helps different workflows. For example, MAP-related tiles can be useful to Seller Tools, Brand Tools, and MAP Tools. Warehouse tiles can appear in both Seller and Warehouse contexts. This does not mean there are multiple copies of the data; it means the same operational truth is being surfaced in multiple useful places.

The active code supports row assignments for five surfaces: seller, brand, warehouse, map, and wip. Built-in defaults currently put New Tiles, Seller Tools, Warehouse, MAP Violations, and Inventory Management on the seller surface; Brand Tools and MAP Violations on brand-facing surfaces; Warehouse on the warehouse surface; MAP Violations on the map surface; and Under Construction on WIP.

3. Top 10 active-build tiles to learn first

I am prioritizing these ten because they are either in the New Tiles row, the Warehouse workflow row, or tied to the most recent active build work around row assignments, MAP intelligence, alerting, and warehouse/restock workflow. The exact “top 10” ranking is inferred from repo inspection, not from a fresh verbal ranking by Brent.

1. Restock Dashboard

Purpose: the Restock Dashboard answers, “What should we order, why, and what evidence supports it?”

Current working status: active and usable, with caveats. The local `restock-dashboard.json` was generated on 2026-05-05 and shows 298 SKUs, 75 needing restock, 3,240 total suggested units, and about $89,538.75 estimated order cost. It also tracks previous-order reserve evidence, including matched FNSKUs, pending reserve units, and rows needing reserve review.

Dependencies and data sources: FBA inventory, sales velocity, mapping data, previous order reserve checks, shipment-detail evidence, and generated restock artifacts in `data/restock-dashboard.json`.

How it relates: it sits upstream of the Restock Order Form. If the dashboard says “this needs restock,” the order form turns that recommendation into an order draft. It also depends on SKU Mapping and Warehouse Inventory so it can avoid over-ordering items already physically available.

Franz guidance: if a restock quantity looks wrong, ask, “Is this using the newest restock snapshot, and did the previous order reserve get applied?”

2. Restock Order Form

Purpose: the Restock Order Form converts restock recommendations into a suggested purchase/order list.

Current working status: active artifact. The current `order-form.json` was generated/finalized around 2026-04-20 and shows 46 products, 2,065 units, about $59,460 cost, and 54,935 PV.

Dependencies and data sources: restock dashboard recommendations, doTERRA product IDs, SKU mapping, warehouse overlay quantities, order-form history, and previous order evidence.

How it relates: it is downstream of Restock Dashboard and upstream of Prep & Pack Workspace. It must interpret warehouse inventory carefully, especially EXPIRING, ON SHELF, and GOLDEN stock.

Franz guidance: if an order form number seems strange, ask, “Is warehouse inventory being applied automatically here, and is GOLDEN inventory opted in or excluded for this item?”

3. Prep & Pack Workspace

Purpose: the Prep & Pack Workspace turns an order into grouped prep lanes and shipment workflow notes.

Current working status: actively built and recently refreshed. The current `prep-document.json` was generated on 2026-05-06 and shows 72 items, 3,125 singles, 13 dangerous-goods items, and 59 standard items. Prep requirements were also regenerated on 2026-05-06.

Dependencies and data sources: `prep-document.json`, `prep-requirements.json`, order-form artifacts, Amazon prep requirement reads, local overrides, and shipment grouping logic.

How it relates: it is downstream of the Restock Order Form. It tells the team how to physically prepare units, where to look for prep exceptions, and which items need special attention.

Franz guidance: if prep looks off, ask, “Is Amazon prep guidance current, and is this row using a manual pack/prep override?”

4. Warehouse Inventory

Purpose: Warehouse Inventory tracks physical stock, sections, counts, and events. It bridges warehouse products to doTERRA Product IDs.

Current working status: usable but still in an active build path. The current `warehouse-inventory.json` shows 60 active products and 1,559 total units across shelf, golden, replacement, return, and related counts. The build spec says the future direction is movement tracking: received, pulled, adjusted, shipped, returned, and notes.

Dependencies and data sources: local warehouse inventory JSON, warehouse mapping overrides, reconciliation notes, physical section definitions, and eventually R2-backed movement records.

How it relates: Warehouse Inventory protects the Restock Dashboard and Order Form from ordering what is already in the building. It also feeds human judgment for expiring or special stock.

Franz guidance: if physical stock and dashboard stock disagree, ask, “Which section is this from: EXPIRING, ON SHELF, or GOLDEN? Is the count a starting balance, movement-adjusted balance, or manual note?”

5. SKU Mapping Validation

Purpose: SKU Mapping Validation links Amazon FNSKUs and products to doTERRA Product IDs so restock, warehouse, order form, and prep data can speak the same language.

Current working status: usable and important. The current `sku-mapping.json` shows 247 FNSKUs, 245 matched, 2 unmatched, 50 multipacks, and 288 reference products. Because only a few unmapped items can create downstream confusion, this tile deserves close attention.

Dependencies and data sources: SKU mapping JSON, reference product data, warehouse mapping overrides, kit contents, purchase option preferences, and candidate matching logic.

How it relates: it is the bridge tile. If mapping is wrong, Restock Dashboard, Order Form, Warehouse Inventory, and Prep & Pack can all look wrong.

Franz guidance: if two rows appear to be the same product or one ASIN has multiple FNSKUs, ask, “Is this a duplicate-ASIN case, a multipack, a kit, or a missing doTERRA Product ID?”

6. Price Intelligence, also called Lane B Pricing

Purpose: Price Intelligence monitors B2B pricing, bulk-tier signals, featured business offers, consumer comparison, and MAP-relevant pricing behavior.

Current working status: very active. The current `lane-b-pricing-current.json` was generated on 2026-05-07 at 23:48 UTC. It tracks 330 ASINs, 310 with business offers, 244 with our B2B offer, 244 own-store ASINs tracked, 94 own-store buy box wins, 38.52 percent own-store buy box win rate, and 13 current active bulk-tier MAP break rows derived from `bulk-tier-map-breaks.json`.

Dependencies and data sources: SP-API itemOffers read batches, Lane B pricing snapshots, authorized sellers data, authorized MAP breaks, bulk-tier MAP breaks, seller names, and price history.

How it relates: it connects MAP monitoring, seller intelligence, buy box outcomes, and business-pricing exceptions. This tile is a likely place to spot pricing mismatch confusion.

Franz guidance: if a product looks compliant in one place and noncompliant in another, ask, “Am I looking at consumer price, business price, bulk-tier price, featured offer, or our own store price?”

7. Authorized Sellers & MAP Compliance

Purpose: this tile separates authorized seller behavior from unauthorized seller behavior, and tracks MAP compliance over time.

Current working status: active and central to MAP work. The dashboard shows authorized seller coverage and MAP compliance; data is loaded from authorized seller summary/detail files and `authorized-map-breaks.json`. Some summary files are older, so timestamp awareness matters.

Dependencies and data sources: authorized seller roster, authorized seller detail, authorized MAP break history, seller names, pricing snapshots, and MAP reference data.

How it relates: it answers “who is allowed to sell” and “who broke MAP.” Price Intelligence answers “what pricing signal did we observe.” Brand Alerts answers “which of those observations became an alert.”

Franz guidance: if a seller looks suspicious, ask, “Is this seller authorized, unauthorized, unknown, or just missing a storefront-name mapping?”

8. Brand Alerts

Purpose: Brand Alerts is the unified alert log for MAP and brand-monitoring events.

Current working status: active. The current `brand-alert-log.json` was generated on 2026-05-06 and shows 978 current/open alerts. It is intentionally a log and triage surface, not an action button for live Amazon changes.

Dependencies and data sources: generated brand alert log, pricing/MAP derivations, alert policy, email sender state, and eventually settings stored in Cloudflare R2.

How it relates: it is downstream of MAP and pricing detection. Price Intelligence and Authorized Sellers explain the facts; Brand Alerts organizes the notification layer.

Franz guidance: if an alert looks noisy, ask, “Is this alert current, historical, resolved elsewhere, or duplicated by a business-pricing/bulk-tier signal?”

9. Alert Settings

Purpose: Alert Settings controls recipient and dry-run/live-mode policy for MAP alert emails.

Current working status: active UI/API source of truth is Cloudflare R2 for non-secret settings. The docs state that provider API keys must not be stored in R2 or returned by the UI. The cron sender still has a remaining migration step because it keeps provider credentials and send-time config locally.

Dependencies and data sources: `/api/map-break-alert-settings`, R2 settings and activity-log objects, local sender configuration, and provider credentials outside the dashboard.

How it relates: Brand Alerts is what happened. Alert Settings is who gets notified and whether sending is dry-run or live.

Franz guidance: do not modify recipients or live/dry-run behavior unless Brent or Fergus explicitly approves. Ask, “Is this a dry-run test, a live alert policy change, or just a dashboard display issue?”

10. April 1 MAP Changes

Purpose: April 1 MAP Changes tracks products affected by the April 1 doTERRA MAP change and ranks them by projected brand-wide volume and current seller violations.

Current working status: active and recently refreshed. `april1-old-map-holdouts-report.json` was generated on 2026-05-07 and shows 98 affected ASINs in the sheet, 97 checked, 3 ASINs with sellers below new MAP, and 3 total seller violations. The base April 1 map sheet was last updated on 2026-04-03.

Dependencies and data sources: April 1 MAP sheet, competitive pricing current/summary, brand revenue estimate, authorized sellers, suppression analysis, price history, and CPT history.

How it relates: this is a specialized MAP change tile. It overlaps with Price Intelligence, MAP Pricing Monitor, Authorized Sellers, and Buy Box Health, but the lens is specifically “what changed on April 1 and who has not adapted?”

Franz guidance: if April 1 numbers disagree with another pricing tile, ask, “Which MAP reference date is this tile using: old MAP, new April 1 MAP, current competitive pricing, or current business-pricing data?”

4. How the top 10 connect as a workflow

Warehouse workflow:

1. Warehouse Inventory says what is physically in the building.
2. SKU Mapping says which Amazon/FNSKU rows match which doTERRA product IDs.
3. Restock Dashboard says what should be ordered after accounting for velocity, FBA inventory, and previous-order reserve evidence.
4. Restock Order Form turns the recommendations into a draft order.
5. Prep & Pack Workspace turns that order into prep lanes and shipment-ready operational guidance.

MAP and pricing workflow:

1. Price Intelligence observes consumer, business, B2B, bulk-tier, and buy box signals.
2. Authorized Sellers & MAP Compliance explains whether a seller is authorized and whether they broke MAP.
3. April 1 MAP Changes focuses on one special MAP-change event.
4. Brand Alerts records and summarizes alert-worthy events.
5. Alert Settings controls notification policy.

The bridge between these worlds is profitability and inventory pressure. A product can be high opportunity, understocked, pricing-sensitive, and MAP-sensitive at the same time.

5. What to ask Fergus when confused

Use this escalation style: describe the tile, the row, the product or ASIN, the data source, and the exact mismatch.

Good examples:

• “In Price Intelligence, ASIN X looks below MAP, but MAP Pricing Monitor says it is at target. Am I comparing consumer price to business price or bulk-tier price?”
• “Restock Dashboard recommends ordering ASIN X, but Warehouse Inventory shows units on shelf. Is the order form applying EXPIRING and ON SHELF stock, and is GOLDEN excluded?”
• “SKU Mapping shows two FNSKUs for one ASIN. Is this a duplicate-ASIN inherit case, a multipack, or a mapping error?”
• “April 1 MAP Changes shows three violations, but Brand Alerts has many open alerts. Are the alerts historical/current, and are they tied to old MAP or new April 1 MAP?”
• “Prep & Pack says bubblewrap for this product, but I expected poly. Is Amazon prep guidance current or is there a manual override?”
• “Authorized Sellers shows a seller as authorized, but Seller Intel/price history looks suspicious. Is this a storefront-name mismatch or seller ID mismatch?”

Bad escalation pattern: “This tile is wrong.”

Good escalation pattern: “This tile shows X, another source shows Y, and I think the mismatch may be price type, date, mapping, or source freshness.”

6. Sensitive-action routing rules

Franz, your safe zone is observation, interpretation, and escalation.

Do:

• Read tiles.
• Compare timestamps.
• Note mismatches.
• Ask Fergus or Brent for approval when the next step could affect Amazon or a customer-facing workflow.
• Treat Under Construction tiles as provisional.

Do not:

• Change prices.
• Change business pricing.
• Change MAP data.
• Edit listings.
• Edit SKUs or inventory in Amazon.
• Create or alter shipments.
• Change payments or seller account settings.
• Trigger live emails or notification policy changes without approval.
• Scrape Amazon public pages.

If a dashboard action looks like it might write to Amazon, stop and ask Fergus. The current onboarding work is local dashboard/data interpretation only.

7. Appendix: lower-priority or on-the-wayside tiles

These are still useful, but learn them after the top 10.

• Opportunities: identifies authorized seller gaps and out-of-stock listings. Current local summary shows 75 opportunities: 15 missing from store and 60 currently listed out of stock.
• MAP Profitability: gross ROI by MAP price. Useful for deciding whether MAP price still supports margin.
• WA vs Wholesale Profitability: compares WA/LRP versus flat wholesale economics.
• Sell Price Calculator: standalone tool to test a price against MAP profitability.
• 2025 Margins Summary: ASIN-level gross and net margin view for 2025.
• Preferred Member Logic and Professional Account Logic: rebuilt spreadsheet logic for purchase-to-profit and account-level calculations.
• Loss Sellers: identifies sellers pricing at a loss or close to loss. Current local summary shows 64 offers, 6 ASINs at loss, and 47 MAP violations in that older snapshot.
• Level Brands Compliance: focused seller compliance history. Current local summary shows 4 total breaks and 0 currently active breaks.
• Buy Box Health: tracks suppression and BSR damage. Current local snapshot shows 72 fully suppressed, 38 MAP-breaker, and 204 healthy ASINs.
• ASIN Monthly Volume Calculations: sales estimates by variation family using sales intelligence and BSR tables.
• Sales & Revenue, Orders Summary, FBA Fees, Seller Performance, Customer Returns, IPI Score, Product History, ASIN Seller Price History: operational background views.
• Variation Sales and Variation Groups: under construction; useful but still validation-heavy.
• FC Distribution Intelligence: under construction/older snapshot; valuable for fulfillment-center coverage and transfer-risk thinking.
• Stuck Inventory, Brand Health, Inbound Noncompliance: monitoring tiles that need timestamp/context checks before relying on them.
• Advertising Performance: API setup required; the spec says disconnected state exists first and live campaign metrics come later.

8. Quick checklist for an overnight liaison

1. Start with the row: which workflow am I in?
2. Check the tile timestamp before trusting the number.
3. Identify the price type: consumer, business, bulk-tier, buy box, MAP, or our own price.
4. Identify the product bridge: ASIN, SKU, FNSKU, doTERRA Product ID, or warehouse product name.
5. Compare related tiles before escalating.
6. If the next step would write to Amazon, stop and ask for approval.
7. When asking Fergus, include tile name, ASIN/product, observed value, conflicting value, timestamp, and suspected cause.

Recommendation

Franz should learn AmazonOps in this order: Warehouse workflow first, then MAP/pricing workflow, then profitability/background tiles, then under-construction experiments. This gives him the safest useful overnight coverage: he can notice inventory/restock issues, pricing/MAP mismatches, and alert noise without touching live Amazon controls.

Next steps

1. Franz should listen to this lesson once while scrolling the dashboard home rows.
2. Then he should open the top 10 tiles one at a time and say out loud: purpose, timestamp, data source, and what would trigger escalation.
3. Fergus or Brent should give him 3 practice cases: one pricing/business-pricing mismatch, one warehouse/order-form mismatch, and one SKU mapping ambiguity.

End of lesson.