LMNT: Establishing Omni (Accelerator) — Ramp-Up Assessment and Recommendation

Prepared by: Brainforge Prepared for: Shivani Amar, Philip McKeating, Jason Wu (and LMNT leadership as needed) Date: 2026-02-28 Status: Draft


Objective

This memo helps LMNT decide how and when to run the Omni accelerator on top of your Snowflake, ETL, and dbt foundation. We recommend a phased 1–2 month pilot (proof of concept) focused on one high-value domain—wholesale or unified omnichannel revenue—followed by expansion aligned to your Omnichannel Revenue Plan and Instagantt milestones. This path supports your goals: governed metrics, self-service exploration, cross-channel visibility (Shopify, Amazon, wholesale, retail), and a clear path beyond Source Medium.


Why This Decision Matters Now

LMNT is already building the data foundation: Snowflake, Polytomic/Fivetran ETL, dbt models, and the documentation-first Omnichannel Revenue Plan with Definitions Council, Instagantt master plan, and channel-by-channel deliverables. The next step is a BI layer where business users can answer strategic questions without waiting on analysts or stitching CSVs—with metrics defined once and consistent across Finance, RevOps, and commercial teams.

Current state challenges:

  • Source Medium phase-out — Existing reporting works but lacks clear ownership and is hard to extend. You need a governed system where metrics are defined once and stay consistent across all users.
  • Cross-channel complexity — Carlos and the commercial team need to answer questions that span Shopify, Amazon, wholesale partners, and retail (Emerson/SPINS). Manual stitching across systems is error-prone and slow.
  • Self-service gap — Business users have strategic questions but either wait for analyst support or export CSVs. LMNT needs a tool where business users can explore data directly without SQL, while analysts control metric definitions.
  • Metrics drift — Different teams can calculate contribution margin, LTV, or payback differently without a single source of truth, which creates confusion in leadership meetings.

Running the Omni accelerator on top of your existing foundation turns the warehouse into the place where Shivani, Phil, Carlos, Laura, and others can explore data, build dashboards, and get answers through Omni’s semantic layer (Topics)—with optional AI-assisted exploration—while staying aligned to your documentation-first principles and Definitions Council.


Evaluation Criteria

We used these criteria to compare phasing and scope options:

  1. Time to first value — How quickly can an LMNT user get a real answer or dashboard from Omni? Prefer options that deliver a working pilot within 4–6 weeks of warehouse connectivity.
  2. Fit with Omnichannel Revenue Plan — How well does the path align with Instagantt milestones, Definitions Council, and channel-by-channel delivery (Shopify, Amazon, Wholesale, Retail)?
  3. Governance and semantic layer — Can analysts define metrics once (Topics) so Finance, RevOps, and commercial all use the same definitions? Prefer options that use the semantic layer as the boundary.
  4. Cross-channel (wholesale + retail) — Can the pilot include both wholesale and retail data so the tool is validated for LMNT’s most important reporting needs?
  5. Handoff and adoption — Can LMNT own and extend Topics and dashboards after Brainforge steps back? Prefer options that include documentation and training tied to your sprint cadence.

Options Considered

Option 1: 1–2 month phased ramp-up (pilot first, then expand)

Connect Omni to Snowflake and agree the pilot domain (e.g. wholesale or unified omnichannel revenue). Build the first Topics and 1–2 dashboards using marts and definitions already locked via the Omnichannel Plan. Validate with real business questions (e.g. wholesale 360, contribution margin by channel); iterate on relationships and filters. In the second phase, add more domains (e.g. retail, full omnichannel) using the same pattern and align to Instagantt “Dashboard live” milestones. Document and train the team that will own Omni. This is the recommended approach.

Option 2: Big-bang rollout (all channels at once)

Define Topics and dashboards for Shopify, Amazon, wholesale, and retail in parallel. Delivers breadth quickly but spreads effort thin and makes it harder to learn from one domain (e.g. date logic, refund harmonization) before scaling. We did not recommend this because it increases risk and complicates handoff during an already busy Omnichannel Plan rollout.

Option 3: Pilot-only (defer expansion)

Run a 1-month pilot (e.g. wholesale + retail as in the BI tool recommendation) and defer the decision to roll out more broadly until the pilot is validated. Valid if LMNT wants to prove value or secure budget before committing. Compatible with the recommended path—pilot is the first phase; expansion can follow once the pilot is signed off.

Options not evaluated in depth

  • Other BI tools — This memo assumes Omni is the chosen or preferred BI direction for LMNT, consistent with the BI Tool Recommendation (1-month Omni pilot, governance, self-service, wholesale + retail).
  • Omni without a semantic layer — Topics are the recommended way to govern metrics; ad-hoc exploration over raw tables was not evaluated for governance reasons.

Comparison

Criterion1–2 month phased (pilot first)Big-bang (all channels)Pilot-only (defer expansion)
Time to first valueHigh — pilot in ~4–6 weeksMedium — first answers laterHigh — same as phased for pilot
Fit with Omnichannel PlanHigh — aligns to Instagantt, Definitions CouncilMedium — same fit but more concurrent workHigh — same as phased
Governance and semantic layerHigh — one pilot domain, clear boundaryLower — many domains at onceHigh — same as phased
Cross-channel (wholesale + retail)High — pilot can include bothHigh — all at onceHigh — pilot includes both
Handoff and adoptionHigh — one success to document and train onLower — many things to hand off at onceMedium — handoff after pilot only
Implementation time~1–2 months (pilot + accelerator)~2–3 months (higher risk)~4–6 weeks (pilot only)

Our Recommendation

We recommend Option 1: a 1–2 month phased ramp-up with a single pilot domain (or focused pilot spanning wholesale + retail) first, then accelerator expansion aligned to the Omnichannel Revenue Plan.

Leading with a tight pilot—e.g. wholesale 360 and/or unified revenue views that span the channels you’ve already defined in the Omnichannel Plan—proves value quickly and keeps governance simple. Your Definitions Council and signed definitions (revenue vs sales, order date taxonomy, refund handling) become the source of truth for Omni Topics, so metrics stay consistent. Once business users see consistent numbers and can explore in Omni, expanding to more domains (e.g. full retail, NetSuite readiness views) follows the same pattern and can align to Instagantt “Dashboard live” milestones.

Why not big-bang (all channels at once)

Spreading effort across all channels from day one makes it harder to tune relationships and harmonize definitions (e.g. refund logic across Amazon and Shopify) for any one area and complicates handoff. One pilot domain or a focused wholesale+retail pilot de-risks the rollout and creates a template for the rest.

Why not deferring Omni

Your Omnichannel Plan already calls for selecting a “cross-org BI front end” and leaving existing Looker acquisition reporting in place until then. Deferring Omni leaves that decision open and delays self-service and governed metrics. A 1–2 month pilot is short enough to fit your three-week sprint cadence and validates the BI direction without blocking other plan deliverables.


Trade-offs and Risks

  • Pilot domain choice — Choosing a domain with unclear definitions or low stakeholder availability can slow adoption. Mitigate by picking an area where definitions are already locked (or close) via the Definitions Council and where Shivani, Phil, or a clear business owner will use the dashboards.
  • Date and filter defaults — Discrepancies between “old” and “new” dashboards often come from different date ranges or filters. Mitigate by aligning date logic (order date, ship date, rev-rec date) and filter defaults with your Data Dictionary and documenting them in Omni.
  • Topic and dashboard maintenance — When dbt marts or unified transaction logic change, Topics and dashboards may need updates. Mitigate by tying Omni review to your change process (e.g. PR or Definitions Council) and Instagantt milestones.
  • Omni licensing — Someone on LMNT’s side should confirm Omni licensing, seat count, and cost. Brainforge can outline what to check but cannot approve spend or contracts.

Implementation Path

High-level 1–2 month path. Exact dates should align to LMNT’s three-week sprints and Instagantt milestones.

1. Weeks 1–2 — Foundation and pilot scope

Connect Omni to Snowflake

  • Create a database connection in Omni pointing at LMNT’s Snowflake account (warehouse, database, schema for marts or staging). Use the credentials and role that have read access to the pilot schemas. Omni supports password or key-pair (RSA) authentication; key-pair is recommended for production.
  • Optionally restrict the connection to specific schemas so the pilot only sees the marts (or staging) in scope; this keeps the model focused and improves performance. See Restricting connection schemas.
  • Confirm RBAC: the Omni connection should use a Snowflake role that can read the pilot tables/views (e.g. dbt marts). Document which schemas and tables are in scope for the pilot.
  • If LMNT uses dbt and you want two-way sync (metrics in dbt visible in Omni), connect the dbt project to the same Omni connection. See Connecting dbt to Omni and Integrating dbt.
  • Connect the Omni instance to LMNT’s GitHub repository so that Topics and model assets are version-controlled and the team can collaborate (e.g. PRs, history). This supports a consistent workflow with dbt when the dbt project lives in the same org/repo and enables tooling (e.g. MCP) that expects Omni + GitHub.

External reference: Connecting Snowflake to Omni, Connect data (overview), Connect a database; Setting up the git integration (GitHub) (version control).

Lock pilot domain and definitions

  • Agree the pilot domain (e.g. wholesale 360, or unified revenue across channels). Align Omni Topics to definitions already signed in the Definitions Council (revenue vs sales, refunds, order date taxonomy). The Data Dictionary and metric naming from the Omnichannel Plan become the source for Topic field labels and descriptions.

Rough effort: 2–3 weeks for Brainforge + LMNT alignment.


2. Weeks 3–6 — First value (pilot)

Build the first Topics

  • Topics in Omni are curated datasets built on top of your connection’s views/tables. Each Topic has a base view, optional joins, and can define default filters, descriptions, and which fields are exposed. For the pilot, create one or two Topics (e.g. “Wholesale 360”, “Unified revenue”) that map to the pilot marts and Definitions Council metrics.
  • Use Topic parameters to set default filters (e.g. date range) and descriptions so business users see consistent behavior. Document any default_filters or always_where_filters so they match the Data Dictionary (e.g. order date vs ship date).
  • Follow Topic best practices: build for your audience (e.g. wholesale vs finance), keep topics focused, and add sample queries to help users get started. See Curating datasets with topics and Topic best practices.

External reference: Curating datasets with topics, Topic best practices, Topic file parameters, Topic design inspiration.

Context Engineering / Semantic Engineering

  • Treat Topic design as context (semantic) engineering: descriptions, default filters, and sample queries define the semantic layer so that Blobby and other consumers get consistent, interpretable answers. Invest in clear, well-scoped Topics and metadata during the pilot so the layer is well-governed from day one.

Enable Blobby for customer-facing use

  • Blobby is Omni’s AI assistant—the main way business users ask questions and get answers in natural language (and create content from prompts). Blobby works out of the box when Topics exist; there is no separate setup step. Once the first Topics are built and published, Blobby is available for questions and for creating dashboards or analyses.
  • Mention Blobby explicitly in customer- and stakeholder-facing documentation and training (e.g. “Ask Blobby” for self-serve, where to find it in the UI). See Dashboard Assistant (Omni’s doc name for this capability).

Build 1–2 dashboards

  • In Omni, dashboards are built from workbooks: you select a Topic, add dimensions and measures, and create charts/tables. Save the workbook as a dashboard and publish it so the business owner can view and filter. Use the same date and filter defaults as in the Topics to avoid discrepancies. Users can also ask Blobby questions or ask it to create content on top of the same Topic (see Blobby subsection above).

Validate and iterate

  • Validate with real business questions (e.g. from CEO/CFO business questions or wholesale/retail stakeholders). Iterate on relationships, metrics, and filters; document date/filter choices. Run at least one session with the business owner to confirm numbers and usability.

Rough effort: 2–3 weeks.


3. Month 2 (or follow-on) — Accelerator and handoff

Expand domains

  • Add one or two more Topics (e.g. full omnichannel, retail) using the same pattern: base view from the relevant mart(s), joins if needed, default filters and descriptions aligned to the Definitions Council. Align to Instagantt “Dashboard live” milestones where applicable.

Permissions and training

Ongoing maintenance

  • Transition ownership and set a simple process for reviewing Omni assets when dbt marts or definitions change (e.g. schema refresh, Topic and dashboard review in the change process or Definitions Council). See Incorporating database changes with schema refreshes.

Rough effort: 2–3 weeks.


Decision Points for Leadership

  • Which domain (or scope) should be the pilot? — Options include wholesale-focused (Wholesale 360, reorder cadence, RFM), unified revenue (contribution margin by channel), or a tight wholesale + retail slice. The pilot should have signed or near-signed definitions and a willing business owner (e.g. Shivani, Phil, Carlos, Laura).
  • Who owns Omni licensing and usage? — LMNT to confirm Omni licensing, seat count, and any usage or cost implications. Brainforge can outline what to check but cannot approve spend or contracts.
  • Who gets training first? — Decide which analysts or business users will be trained to create or update Topics and dashboards. Training is most effective when tied to the pilot domain and your sprint cadence.

  1. Confirm pilot domain and stakeholder — LMNT (Shivani/Phil) to choose the first business area and a business owner who will use Omni. Brainforge to align on the source marts/schemas (from dbt or existing Snowflake views) and Definitions Council entries.
  2. Confirm Snowflake and Omni access — LMNT (Jason/IT) to confirm Snowflake connectivity, roles, and Omni account/access. Brainforge to use this in Week 1 planning.
  3. Kick off foundation — Brainforge to connect Omni to Snowflake and lock pilot domain and sources; schedule pilot kickoff once access and scope are confirmed. Align pilot milestones to Instagantt where applicable.

References

Internal (vault and playbook)

  • Generic Omni ramp-up memo (template): standards/02-writing/Memos/examples/omni-ramp-up-memo.md
  • LMNT Omnichannel Revenue Plan: knowledge/clients/lmnt/resources/Brainforge LMNT Omnichannel Revenue Plan.md (documentation-first, Instagantt, Definitions Council, deliverables, success metrics)
  • LMNT BI Tool Recommendation (Omni pilot): knowledge/clients/lmnt/resources/lmnt_bi_tool_recommendation.md (governance, self-service, 1-month pilot, wholesale + retail)
  • LMNT Omni demo (Jan 2026): knowledge/clients/lmnt/transcripts/2026-01-08_brainforge_x_lmnt_omni_demo_f6f33bd6.md
  • LMNT ETL platform assessment: knowledge/gtm/sales/sow-framework/examples/sow-data-etl-LMNT.md
  • LMNT stakeholder and business questions: knowledge/clients/lmnt/meeting-notes/Data calls with key stakeholders.md, knowledge/clients/lmnt/resources/CEO_CFO_BUSINESS_QUESTIONS.md
  • LMNT analysis context (optional): knowledge/clients/lmnt/resources/LMNT_Analysis_Roadmap.md, knowledge/clients/lmnt/resources/LMNT_Snowflake_Tables_and_Shivani_Questions.md

External (Omni documentation and resources)

Getting started and setup

Modeling and Topics (semantic layer)

dbt integration (LMNT uses dbt)

Workbooks, dashboards, and content

Permissions and administration

Onboarding and training

AI and product


Appendix: Omni Pilot — Domains, Owners, and Questions We Will Answer

For the Omni kickoff. Lists LMNT business domains, the immediate stakeholder for each, and the questions we expect to answer in the 4–6 week pilot using existing Snowflake marts. Use it to lock pilot scope and avoid building for questions we can’t answer yet.


1. Wholesale

FieldDescription
Immediate stakeholderBlake (Partnerships), Laura / Madison (Wholesale), Shivani (top partners / leadership view)
Pilot datawholesale_mart, wholesale_dm_customer (Shopify + Google Sheets CRM)

Questions we expect to answer in the pilot

  • Who are our top wholesale partners by revenue (and by what time window)?
  • What does wholesale revenue look like by week or month (ops view from Shopify/marts)?
  • How does ops wholesale revenue compare to finance (same Topic with two labeled views, or one reconciled number once we lock definition)?
  • Which partners are in the mart and what’s their reorder/activity pattern (from existing fields in wholesale_dm_customer)?

Out of pilot scope for now
Wholesale LTV, formal “at risk”/churn flags, and active vs churned definitions—need aligned definitions and possibly more history; can be a follow-on Topic.


2. Retail (Walmart + Target)

FieldDescription
Immediate stakeholderShivani, Russell (retail)
Pilot datafact_sales (Walmart + Target POS); Walmart order-management table (join in progress for total Walmart revenue)

Questions we expect to answer in the pilot

  • How is Target performing vs Walmart (e.g. sales by week, by retailer)?
  • What were sales across Walmart + Target for a given day or week (once Walmart POS + order-mgmt join is live)?
  • What is the delta between how Walmart and Target report (e.g. week-ending date, rev-rec timing)—and can we show both in one view with clear labels?
  • Retail sales by week (and, if available in the tables, by region e.g. NE vs CA).

Out of pilot scope for now
Retail payback (trade spend, chargebacks, slotting) and retail vs DTC cannibalization—require additional data and modeling; post-pilot.


3. Revenue / reconciliation

FieldDescription
Immediate stakeholderBess (Finance), Shivani
Pilot dataWholesale marts (ops); Finance source is QuickBooks/NetSuite (reconciliation today is manual)

Questions we expect to answer in the pilot

  • What is “wholesale revenue” in the tool—one number (after we lock definition with Finance) or two labeled views (“Ops” vs “Finance”)?
  • What is in scope for “net revenue” in the pilot (e.g. revenue minus discounts, refunds, shipping—document in Topic description even if we only implement one view)?
  • Revenue by channel in pilot: wholesale (from marts) and retail (from fact_sales / joined Walmart); e-commerce by channel when e-commerce mart exists (post-pilot).

Out of pilot scope for now
Full net-revenue reconciliation to QuickBooks/NetSuite in Omni; contribution margin by channel (cost data); cross-channel attribution. We can document definitions and “Ops vs Finance” in the Topic so the pilot view is clear.


4. E-commerce (Shopify, Amazon, etc.)

FieldDescription
Immediate stakeholderCarlos (E-commerce), Shivani (channel mix)
Pilot dataE-commerce mart not yet modeled; raw Shopify in RAW.POLYTOMIC.SHOPIFY

Questions we expect to answer in the pilot

  • None that require a dedicated e-commerce mart. If we expose raw or a thin staging layer in Omni, we could support “orders/volume by source (Shopify vs tagged wholesale)” only; not recommended for pilot unless we add a small e-com mart.

Recommendation
Treat e-commerce as post-pilot: build Omni Topics once the e-commerce mart and definitions (e.g. MER, buy box) are in place.


Definition gaps to align in kickoff

  • Revenue / net revenue: Finance vs Ops currently under 10% apart on wholesale; agree either one definition for the pilot Topic or two labeled views (“Ops wholesale revenue” vs “Finance wholesale revenue”).
  • Wholesale: “Active,” “at risk,” “churned” are not standardized; pilot can ship partner list + revenue/reorder from marts; formal flags in a later Topic once definitions are set.
  • Retail: Walmart = POS + order-management (two tables); Target = POS in fact_sales. Document in the Topic how “week ending” and revenue recognition differ by retailer so the view is interpretable.