# AmazonOps Full Onboarding Lesson for Franz Audience: Franz, also known as angrycat.ron. Mission: understand AmazonOps well enough to support Brent and Fergus overnight without accidentally turning a dashboard observation into a live Amazon action. Important safety disclaimer: do not be scared. AmazonOps is primarily a read-only operations dashboard. Your job is to read, compare, interpret, and escalate. Do not change prices, listings, SKUs, inventory, shipments, payments, MAP rules, notification policy, or Seller Central settings. Do not scrape Amazon public pages. If a step could affect Amazon, a customer-facing workflow, a live email, or a warehouse/order decision, ask Fergus or Brent first. ## 1. The mental model AmazonOps is the operations brain for The Natural Life. It combines official Amazon SP-API reads, local generated datasets, Keepa-derived history, doTERRA reference data, seller/pricing intelligence, warehouse counts, order artifacts, and prep workflows. Think in four layers: 1. Data layer: JSON reports and snapshots, mostly under `/Users/fergus/Projects/amazonops/data`, plus live read-only API pulls and R2-backed dashboard data. 2. Tile layer: each tile answers one operational question. Example: “Who is under MAP?” “What should we order?” “Which FNSKU maps to which doTERRA product?” 3. Row layer: rows group related tiles into workflow lanes. Rows are not decoration. Rows explain why tiles belong together. 4. Surface layer: surfaces decide who sees what: Seller Tools, Brand Tools, Warehouse Tools, MAP Tools, and WIP Tools. The most important rule from the repo itself: AmazonOps is read-only against Amazon. Reads and fee estimates are allowed. Listing edits, price changes, inventory updates, buyer messages, shipment creation, and account modifications are forbidden from the dashboard workflow unless Brent and Fergus deliberately build and approve a safe write path. ## 2. How rows and surfaces work Rows answer: “Why would someone open these tiles together?” Core rows: - New Tiles: staging row. New or recently expanded tiles land here before promotion. - Seller Tools: seller operations, buy box, pricing, catalog health, orders, account performance. - Brand Tools: brand-side monitoring, seller coverage, MAP, revenue intelligence. - MAP Violations: all-seller MAP breaks and pricing intelligence. - Warehouse: physical stock, SKU mapping, restock, order form, prep workflow. - Inventory Management: FBA stock, stuck stock, aging inventory, inbound issues. - Under Construction / WIP: prototypes and incomplete tiles. Treat as provisional. A tile or row can appear on multiple surfaces. That is intentional. MAP information helps both seller and brand workflows. Warehouse information helps seller and warehouse workflows. Seeing the same truth in multiple places is not necessarily duplication. But some tiles do overlap, and part of your job is to recognize the lens each tile uses. ## 3. The three workflows Franz must master first ### Workflow A: Warehouse to order to prep 1. Warehouse Inventory tells you what is physically in the building. 2. SKU Mapping Validation translates between Amazon/FNSKU rows and doTERRA product IDs. 3. Restock Dashboard tells you what should be ordered based on FBA inventory, sales velocity, and reserve evidence. 4. Restock Order Form turns recommendations into an order draft. 5. Prep & Pack Workspace turns the order into shipment/prep instructions. Primary failure modes: stale snapshots, wrong mapping, warehouse stock not applied, GOLDEN inventory included/excluded incorrectly, previous-order reserve double-counted or not counted, prep override mismatch. ### Workflow B: MAP and pricing intelligence 1. Price Intelligence / Lane B observes consumer, business, B2B, bulk-tier, featured offer, and our-store pricing. 2. All MAP Violations Log records marketplace MAP breaks across all sellers. 3. Authorized Sellers & MAP Compliance tells you whether a seller is allowed to sell and whether authorized sellers broke MAP. 4. April 1 MAP Changes tracks one special MAP-change event. 5. Brand Alerts turns detected events into alert records. 6. Alert Settings controls who gets notified and whether emails are dry-run or live. Primary failure modes: comparing consumer price to business price, comparing old MAP to new MAP, treating bulk-tier price as normal retail price, seller-name mismatch, current alert versus historical alert confusion. ### Workflow C: Opportunity, profitability, and account health 1. Opportunities finds gaps: products missing from our store or out of stock. 2. Profitability tiles explain whether the price still makes money. 3. Buy Box and pricing tiles explain whether the market is letting us win. 4. Sales/revenue/volume tiles explain whether the product is worth attention. 5. Inventory/account-health tiles explain operational constraints. Primary failure modes: high revenue but no margin, good margin but no stock, good stock but poor buy box, apparent opportunity that is actually a dangerous-goods or prep/mapping issue. ## 4. The top 20 core tiles This is my recommended expanded onboarding set. It is more useful than a top 10 because AmazonOps is now broad enough that Franz needs a full map, not just the hottest build area. The list is prioritized by operational importance and confusion-risk, not by visual position alone. ### 1. Restock Dashboard Purpose: answers “What should we order, how much, and why?” Current status: active and central. The local snapshot I inspected showed 298 SKUs, 75 needing restock, 3,240 total suggested units, and about $89,538.75 estimated order cost. Main sources: FBA inventory, velocity, mapping, previous order reserve evidence, shipment details, restock dashboard JSON. Relationship: upstream of the Restock Order Form; depends heavily on SKU Mapping and Warehouse Inventory. Escalate when: a quantity seems too high/low, a previous order may already cover demand, or a warehouse quantity should have reduced the order. Ask Fergus: “Is this using the newest restock snapshot, and was previous-order reserve applied?” ### 2. Restock Order Form Purpose: turns restock recommendations into an order draft. Current status: active artifact. The inspected order-form artifact showed 46 products, 2,065 units, about $59,460 cost, and 54,935 PV. Main sources: Restock Dashboard, doTERRA Product IDs, SKU Mapping, warehouse overlay quantities, order history. Relationship: downstream of Restock Dashboard and upstream of Prep & Pack Workspace. Escalate when: order quantities differ from restock recommendations, warehouse stock is unexpectedly included/excluded, or GOLDEN inventory appears to be used incorrectly. Ask Fergus: “Is EXPIRING and ON SHELF stock automatically applied here, and is GOLDEN opt-in or excluded for this row?” ### 3. Prep & Pack Workspace Purpose: turns an order into prep lanes, shipment notes, and item-level handling guidance. Current status: active and recently refreshed. The inspected prep document showed 72 items, 3,125 singles, 13 dangerous-goods items, and 59 standard items. Main sources: prep document JSON, prep requirements JSON, order-form artifacts, Amazon prep requirement reads, local overrides. Relationship: downstream of the order form; validates physical prep realities before shipment. Escalate when: prep method seems wrong, dangerous-goods status looks inconsistent, or Amazon prep guidance differs from local expectation. Ask Fergus: “Is this Amazon prep guidance current, or is a manual pack/prep override controlling this row?” ### 4. Warehouse Inventory Purpose: tracks physical stock, sections, counts, and events in the warehouse. Current status: active build path. Inspected warehouse data showed 60 active products and 1,559 total units across shelf/golden/replacements/returns and related counts. The future spec points toward movement tracking for received, pulled, adjusted, shipped, returned, and notes. Main sources: warehouse inventory JSON, warehouse mapping overrides, section definitions, reconciliation notes, eventually movement records. Relationship: protects restock/order form from buying product already in the building. Escalate when: dashboard stock and physical stock disagree, a product appears in the wrong section, or an old starting balance may be mistaken for current balance. Ask Fergus: “Is this a starting balance, movement-adjusted balance, or manual note?” ### 5. SKU Mapping Validation Purpose: links Amazon SKUs/FNSKUs/ASINs to doTERRA product IDs. Current status: critical bridge tile. Inspected data showed 247 FNSKUs, 245 matched, 2 unmatched, 50 multipacks, and 288 reference products. Main sources: SKU mapping JSON, reference products, kit contents, warehouse mapping overrides, candidate matching logic. Relationship: mapping errors propagate into Restock, Warehouse, Order Form, Prep, profitability, and sales analysis. Escalate when: one ASIN maps to multiple products, a multipack looks like a single, or a warehouse product has no clean product ID. Ask Fergus: “Is this a duplicate-ASIN inherit case, a multipack, a kit, or a missing doTERRA Product ID?” ### 6. Price Intelligence / Lane B Pricing Purpose: monitors B2B pricing, business offers, bulk-tier signals, featured offer behavior, and our-store pricing context. Current status: very active. The inspected snapshot tracked 330 ASINs, 310 with business offers, 244 with our B2B offer, 94 own-store buy box wins, and a 38.52 percent own-store buy box win rate. Bulk-tier MAP break derivations were also active. Main sources: SP-API itemOffers read batches, Lane B pricing snapshots, authorized sellers, MAP breaks, seller names, pricing history. Relationship: connects MAP, seller intelligence, buy box, and B2B exceptions. Escalate when: a product looks compliant in one tile but not another, especially if business/bulk-tier pricing is involved. Ask Fergus: “Am I comparing consumer price, business price, bulk-tier price, featured offer, or our own store price?” ### 7. All MAP Violations Log Purpose: chronological all-seller log of marketplace offers detected below MAP. Current status: central MAP investigation tile. It is the broadest MAP-break lens: all sellers, current and historical, known and unknown. Main sources: MAP break history, competitive pricing, seller names, authorized seller matching, pricing snapshots. Relationship: broader than Authorized Sellers & MAP Compliance; more violation-focused than Price Intelligence. Escalate when: the same seller/product appears multiple times, a violation seems resolved but still active, or the MAP reference date is unclear. Ask Fergus: “Is this current active MAP, historical lifecycle, or a stale snapshot?” ### 8. Authorized Sellers & MAP Compliance Purpose: separates authorized seller coverage and authorized-seller MAP behavior from unauthorized marketplace noise. Current status: active and important. Some summary data may be older, so timestamp checks matter. Main sources: authorized seller roster, authorized seller detail, authorized MAP break history, seller names, pricing snapshots. Relationship: tells you who is allowed to sell; All MAP Violations tells you who broke price rules; Seller Intel tells you who they may be. Escalate when: seller authorization status contradicts seller behavior, or storefront name and seller ID do not line up. Ask Fergus: “Is this seller authorized, unauthorized, unknown, or just missing a storefront-name mapping?” ### 9. Brand Alerts Purpose: unified alert log for MAP and brand-monitoring events. Current status: active. Inspected alert data showed 978 current/open alerts. Treat this as a triage/logging layer, not as a command center for live Amazon changes. Main sources: brand alert log, pricing/MAP derivations, email sender state, alert policy. Relationship: downstream of MAP and pricing detection. It summarizes what deserves attention. Escalate when: an alert looks duplicated, stale, noisy, or tied to the wrong MAP basis. Ask Fergus: “Is this alert current, historical, resolved elsewhere, or duplicated by business-pricing or bulk-tier data?” ### 10. Alert Settings Purpose: controls alert recipients, dry-run/live mode, and non-secret email policy settings. Current status: active UI/API source of truth is Cloudflare R2 for non-secret settings. Provider API keys must not be stored in R2 or returned by the UI. The cron sender still has migration caveats. Main sources: `/api/map-break-alert-settings`, R2 settings/activity logs, local sender config, provider credentials kept outside dashboard settings. Relationship: Brand Alerts is what happened; Alert Settings is who gets told and whether sending is dry-run or live. Escalate when: anyone wants recipient changes, live/dry-run changes, or a test email. Ask Fergus: “Is this a dashboard display issue, a dry-run test, or a live notification policy change?” ### 11. April 1 MAP Changes Purpose: focuses specifically on products affected by the April 1 doTERRA MAP change. Current status: active and recently refreshed. The inspected holdouts report showed 98 affected ASINs in the sheet, 97 checked, 3 ASINs with sellers below new MAP, and 3 total seller violations. Main sources: April 1 MAP sheet, current competitive pricing, brand revenue estimates, authorized sellers, price history. Relationship: specialized MAP-change view. It overlaps with MAP Violations and Price Intelligence, but its lens is “did the market adapt to April 1?” Escalate when: April 1 compliance differs from current MAP or another pricing tile. Ask Fergus: “Which MAP basis is this using: old MAP, April 1 MAP, current pricing, or business-pricing data?” ### 12. Opportunities Purpose: identifies authorized seller gaps and out-of-stock listings. Current status: useful strategic tile. Inspected data showed 75 opportunities: 15 missing from our store and 60 currently listed out of stock. Main sources: authorized seller coverage, store activity, profitability, sales estimates, availability signals. Relationship: connects stock, catalog coverage, and revenue potential. It often points you back to Restock, SKU Mapping, or profitability. Escalate when: a suggested opportunity appears unmapped, unprofitable, restricted, or dangerous-goods complicated. Ask Fergus: “Is this a real opportunity or just a missing mapping/availability artifact?” ### 13. MAP Profitability Purpose: shows gross ROI by MAP price and helps decide whether a MAP-compliant price still makes money. Current status: active business-planning tile, not a live pricing control. Main sources: product fees, purchase cost, MAP reference prices, profitability models. Relationship: pairs naturally with Sell Price Calculator, WA vs Wholesale Profitability, and April 1 MAP Changes. Escalate when: a product is MAP-compliant but margin looks too thin, or a proposed sell price breaks margin logic. Ask Fergus: “Are we checking gross ROI, net margin, MAP floor, or account-type profitability?” ### 14. Buy Box Health Purpose: tracks buy box suppression, buy box damage, and BSR-related risk. Current status: active analytical tile. Inspected local data showed 72 fully suppressed, 38 MAP-breaker, and 204 healthy ASINs in that snapshot. Main sources: buy box suppression data, competitive pricing, BSR/history, pricing state. Relationship: overlaps with Competitive Pricing / Buy Box and Buy Box Win Rate, but focuses on health and suppression, not just current win/loss. Escalate when: an ASIN has stock and reasonable price but appears suppressed or losing visibility. Ask Fergus: “Is this a suppression problem, a MAP-breaker problem, or a current buy-box competition problem?” ### 15. Buy Box Win Rate and Competitive Pricing / Buy Box Purpose: shows whether The Natural Life is currently winning the buy box and how pricing compares. Current status: active seller-ops view. It is narrower than Buy Box Health and more immediately tactical. Main sources: competitive pricing current data, item offers, own seller ID, buy box winner/featured offer signals. Relationship: compare with Price Intelligence for B2B/business context and Buy Box Health for suppression context. Escalate when: our price is close but we are not winning, or another tile says we should be healthy. Ask Fergus: “Is this a consumer buy box issue, a business featured-offer issue, or a suppression issue?” ### 16. Seller Intel Purpose: builds dossiers on sellers, especially unauthorized or suspicious storefronts. Current status: active intelligence layer. It helps explain who a seller might be, not just what price they showed. Main sources: seller names, seller history, storefront relationships, price history, unauthorized seller history. Relationship: downstream of MAP and pricing signals; supports enforcement/research decisions. Escalate when: a seller appears under multiple names, seller ID/name mapping is inconsistent, or a seller’s behavior changes rapidly. Ask Fergus: “Are we looking at one seller, related storefronts, or just name-resolution noise?” ### 17. ASIN Monthly Volume Calculations / Sales Intelligence Purpose: estimates monthly units and sales volume by ASIN or variation family. Current status: useful strategic layer. The inspected sales-intelligence data was older, so timestamp awareness is important. Main sources: BSR conversion tables, sales intelligence JSON, Keepa/BSR history, variation grouping. Relationship: feeds opportunity sizing, restock priority, brand revenue, and April 1 MAP prioritization. Escalate when: a volume estimate drives a big business decision but the timestamp or method is unclear. Ask Fergus: “Is this observed sales, BSR-estimated sales, variation-family estimate, or fallback estimate?” ### 18. Brand Revenue and ASIN Revenue Purpose: estimates revenue at brand and ASIN levels, usually using observed data first and Keepa-backed estimates when needed. Current status: important for prioritization but estimate-based in places. Main sources: brand revenue estimate, revenue history, BSR-to-unit conversion, buy box price, observed sales where available. Relationship: tells you whether a MAP issue or opportunity is financially worth attention. Escalate when: revenue estimate conflicts with sales volume or buy box history. Ask Fergus: “Is this observed revenue, estimated revenue, blended history, or Keepa fallback?” ### 19. Listing Health / Catalog Health Purpose: monitors listing quality, brand health, and catalog problems that can affect sales and compliance. Current status: useful support tile. It should be read as a diagnostic surface, not a direct fix button. Main sources: listing status/issues, brand health data, listing quality generation, catalog health records. Relationship: explains why a product may underperform even if price and inventory look fine. Escalate when: a product has stock, price, and demand but still poor sales or visibility. Ask Fergus: “Is this a listing quality issue, brand health issue, suppressed listing, or data freshness issue?” ### 20. Inventory Management: FBA Inventory, Aging Inventory, Stuck Inventory, IPI Purpose: monitors Amazon-side inventory health, age, reserved/stuck stock, and IPI performance. Current status: operationally important but usually second-layer after Restock/Warehouse. Use it for diagnosis. Main sources: FBA inventory summaries, inventory age, IPI logger/server data, stuck inventory calculations, inbound/noncompliance data. Relationship: explains whether Amazon-side inventory is available, aging, reserved, stranded, or creating account-health pressure. Escalate when: Restock says one thing but FBA inventory/aging/stuck inventory says another. Ask Fergus: “Is this sellable FBA stock, reserved stock, unfulfillable stock, aged stock, or physically warehouse stock?” ## 5. Secondary tiles and how to think about them These are real and useful, but Franz should learn them after the top 20 or use them as supporting evidence. - WA vs Wholesale Profitability: compares WA/LRP versus flat wholesale economics. Good for account-type decisions. - Sell Price Calculator: fast what-if price testing against MAP/profitability assumptions. - 2025 Margins Summary: historical gross/net margin by ASIN. - Preferred Member Logic: rebuilt spreadsheet logic for purchase-to-profit under preferred-member assumptions. - Professional Account Logic: reduced PV, bonus, unilevel, and professional account logic. - Loss Sellers: identifies sellers pricing at or near loss. Useful for enforcement context. - Level Brands Compliance: seller-specific compliance history. Useful but narrower than the main MAP tiles. - Sales & Revenue: month-level units and revenue trend. - Orders Summary: recent order volume and units sold. - FBA Fees / Product Fees: Amazon fee estimates and fee-related analysis. - Seller Performance: account metrics and seller health context. - Customer Returns: return trends and possible product-quality signals. - doTERRA Reference Change Log: reference sheet changes, including MAP/reference updates. - doTERRA Website Availability Log: website table changes for product availability. - doTERRA Master Change Log: merged reference and website changes. - The Natural Life Store Activity: seller events for Brent’s own store. - doTERRA Org and Rob Whitney: brand/org context, not day-to-day ops. - Product History and ASIN Seller Price History: historical price/BSR/seller timelines. - Advertising Performance: API setup required; useful spec exists, but live ad data is not connected yet. - FC Distribution Intelligence: fulfillment-center coverage and transfer-risk analysis; valuable but timestamp-sensitive. - Variation Sales and Variation Groups: useful for family-level interpretation, but validate carefully. - Inbound Noncompliance: use when Amazon shipment/inbound compliance issues appear. - Equipment: shared warehouse equipment/request queue. ## 6. Redundancy and overlap map Some redundancy is healthy because different people need different lenses. But here is where Franz should expect overlap. ### MAP/pricing overlap Tiles involved: Price Intelligence, All MAP Violations Log, Authorized Sellers & MAP Compliance, April 1 MAP Changes, Brand Alerts, Loss Sellers, Level Brands Compliance. How to separate them: - Price Intelligence: what price did we observe, including business and bulk-tier context? - All MAP Violations Log: who was below MAP and when? - Authorized Sellers & MAP Compliance: was the seller authorized, and how did authorized sellers behave? - April 1 MAP Changes: did sellers adapt to the April 1 MAP update? - Brand Alerts: which events became alerts? - Loss Sellers: who is below breakeven or close to it? - Level Brands Compliance: focused seller compliance history. Potential consolidation later: Brand Alerts and Alert Settings stay separate. MAP Violations, Authorized Sellers, and April 1 should probably remain separate but share more common components. Loss Sellers and MAP Profitability may belong in a profitability/pricing analysis row rather than a MAP investigation row. ### Buy box overlap Tiles involved: Buy Box Health, Competitive Pricing / Buy Box, Buy Box Win Rate, Price Intelligence. How to separate them: - Buy Box Health: are we healthy, suppressed, or damaged? - Competitive Pricing / Buy Box: current consumer-market competition. - Buy Box Win Rate: current hold rate and tracking. - Price Intelligence: B2B/business/bulk-tier/featured-offer nuance. Potential consolidation later: Competitive Pricing / Buy Box and Buy Box Win Rate may be candidates for a combined buy-box operations tile, with Buy Box Health remaining as the diagnostic health layer. ### Profitability overlap Tiles involved: MAP Profitability, WA vs Wholesale Profitability, Sell Price Calculator, 2025 Margins Summary, Preferred Member Logic, Professional Account Logic, FBA Fees. How to separate them: - MAP Profitability: profitability at MAP. - WA vs Wholesale: account model comparison. - Sell Price Calculator: quick what-if. - 2025 Margins Summary: historical margin. - Preferred/Professional logic: rebuilt spreadsheet assumptions. - FBA Fees: fee inputs. Potential consolidation later: a single Profitability Hub could absorb most of these with tabs. That would reduce tile clutter. ### Revenue and volume overlap Tiles involved: Sales Intelligence, ASIN Monthly Volume, Sales & Revenue, Brand Revenue, ASIN Revenue, Revenue History, Variation Sales. How to separate them: - Sales Intelligence / ASIN Monthly Volume: units and volume estimates. - Sales & Revenue: seller-side units/revenue trend. - Brand Revenue / ASIN Revenue: broader brand/ASIN revenue estimates. - Variation Sales: family/group level view. Potential consolidation later: Revenue and volume could become one Revenue Intelligence hub with observed, estimated, and variation views clearly labeled. ### Inventory overlap Tiles involved: Restock Dashboard, FBA Inventory, Warehouse Inventory, Aging Inventory, Stuck Inventory, IPI, Inbound Noncompliance. How to separate them: - Restock Dashboard: what to order. - FBA Inventory: what Amazon currently has. - Warehouse Inventory: what Brent physically has. - Aging Inventory: what is getting old. - Stuck Inventory: what is not flowing. - IPI: account-level inventory performance. - Inbound Noncompliance: shipment/inbound problems. Potential consolidation later: keep Restock, Warehouse, and Prep separate. Consider grouping Aging, Stuck, IPI, and Inbound into an Inventory Health row or hub. ## 7. The safe escalation pattern When confused, do not say “the tile is wrong.” Say this: “I’m looking at [tile name]. For [ASIN/product/seller], it says [observed value] as of [timestamp]. But [other tile/source] says [conflicting value] as of [timestamp]. I think the mismatch may be [price type / MAP basis / mapping / stale data / warehouse section / estimate method]. Should I treat this as a real issue or a data-lens mismatch?” Examples: - “Price Intelligence says ASIN X is below MAP, but MAP Violations does not show it. Am I looking at business price or consumer price?” - “Restock recommends ordering 80 units, but Warehouse Inventory shows 50 ON SHELF. Is the order form applying that stock?” - “Brand Alerts shows many open alerts, but April 1 MAP Changes shows only three violations. Are the alerts broader than the April 1 scope?” - “Buy Box Health says suppressed, but Buy Box Win Rate says we won recently. Is this a timestamp issue?” - “SKU Mapping shows duplicate-ASIN inherit. Is that safe here or does this need human validation?” ## 8. Sensitive-action routing rules Your safe zone: - Read dashboard tiles. - Compare timestamps. - Identify which data lens you are using. - Record mismatches. - Ask Fergus or Brent for approval. Stop and ask before: - Sending or changing live alerts. - Changing recipients. - Changing dry-run/live mode. - Making order decisions. - Treating a restock recommendation as final. - Changing warehouse counts or movement records. - Interpreting a MAP break as enforcement-ready. - Taking any step that touches Amazon directly. Never do without explicit approval: - Change Amazon prices. - Change business pricing. - Edit listings. - Edit SKUs. - Create or alter shipments. - Update inventory on Amazon. - Message buyers. - Change account settings. - Scrape Amazon public pages. ## 9. Daily operating checklist for Franz Start of shift: 1. Check whether you are in Seller, Brand, Warehouse, MAP, or WIP surface. 2. Check tile timestamps before trusting numbers. 3. Identify whether a price is consumer, business, bulk-tier, buy box, MAP, or our own price. 4. Identify whether a product key is ASIN, SKU, FNSKU, doTERRA Product ID, or warehouse product name. 5. For restock/order questions, inspect Warehouse Inventory and SKU Mapping before trusting a quantity. 6. For MAP/pricing questions, inspect Price Intelligence, MAP Violations, Authorized Sellers, and Brand Alerts together. 7. For profitability questions, separate margin, MAP, account type, fee, and revenue assumptions. 8. Treat WIP and Under Construction as provisional. End of shift: 1. Summarize the top mismatches found. 2. Separate real operational risks from data-lens confusion. 3. Flag stale-data tiles. 4. List anything requiring Brent/Fergus approval. 5. Do not make silent changes to live settings. ## 10. Recommended onboarding sequence Session 1: Orientation. Learn surfaces, rows, timestamps, and the read-only safety rule. Session 2: Warehouse workflow. Open Warehouse Inventory, SKU Mapping, Restock Dashboard, Order Form, and Prep & Pack Workspace. Session 3: MAP/pricing workflow. Open Price Intelligence, All MAP Violations Log, Authorized Sellers, April 1 MAP Changes, Brand Alerts, and Alert Settings. Session 4: Profitability and opportunity. Open Opportunities, MAP Profitability, Buy Box Health, Buy Box Win Rate, Seller Intel, Sales Intelligence, Brand Revenue, and Catalog Health. Session 5: Redundancy drills. Pick one ASIN and trace it through inventory, pricing, profitability, seller intelligence, and MAP. The goal is to learn why different tiles disagree without assuming one is wrong. ## Recommendation Use the top 20 as Franz’s official AmazonOps onboarding curriculum. Keep the top 5 warehouse/order/prep tiles as mandatory first-pass training because they are where a small misunderstanding can create real operational confusion. Then train MAP/pricing because it has the highest redundancy risk. Finally, teach profitability, opportunity, revenue, and inventory-health tiles as decision-support layers. My consolidation recommendation: do not delete tiles yet. First label overlapping tiles by lens: MAP detection, MAP alerts, buy box operations, profitability, revenue intelligence, inventory health. Once Franz and the team can identify which overlaps are genuinely confusing, consolidate hubs in this order: Profitability Hub first, Revenue Intelligence second, Buy Box Operations third, Inventory Health fourth. Keep Restock, Warehouse, SKU Mapping, Order Form, Prep, Price Intelligence, Authorized Sellers, Brand Alerts, and Alert Settings distinct. ## Next steps 1. Franz listens to this lesson while scrolling the dashboard rows. 2. Franz opens the top 20 tiles and writes one sentence for each: purpose, source, escalation trigger. 3. Fergus gives Franz three practice cases: one warehouse/order mismatch, one MAP/business-pricing mismatch, and one SKU mapping ambiguity. 4. After one overnight shift, collect Franz’s confusion points and use them as the first redundancy/consolidation evidence. End of expanded lesson.