MG × ecoATM Proposal — Structural Pattern Study

Why this is in the vault

Two single-page commercial+tech proposal artifacts from Mammoth Growth's ecoATM engagement ($98k fixed-fee, May→July 2026). Founder is at MG for 4 more days; Jeff asked for help closing this deal. Beyond the immediate close, the proposal SHAPE is the durable artifact — these are unusually well-designed services-proposal one-pagers, and the structural patterns transfer cleanly to future RDCO services work (Client Reporting Automation, MAC consulting tier, future FDE-style engagements).

Filed as reference (not SOP) per founder direction 2026-05-14 17:19 ET — SOPs are for RDCO operational procedures; this is studying an external artifact for pattern absorption.

The artifacts

Both are single-page, high-density infographic-style proposals — not multi-page narrative SOWs. That format choice is itself the load-bearing pattern.

The deal shape

$98k fixed-fee, 10 weeks, three workstreams:

1. ID Resolution — email hashing solve, SMS phone unification, identity spine build, Iterable enrichment audit
2. Audiences & Analytics — LTV scoring framework, Streamlit dashboards in Snowflake, high-value audience pockets, repeat-buyer segments
3. Integrations — Snowflake↔Iterable resync, Snowflake→Funnel.io pipeline, audience sync to Meta & Google, push opt-in foundation, CAPI handoff

Tools: Snowflake, Iterable (Data Share + Profiles), Funnel.io, Streamlit, dbt, SFMC, Meta/Google CAPI, Shopify. Notably absent: no reverse-ETL vendor (no Hightouch / Census / Segment / mParticle / LiveRamp). Custom dbt smart-ingest daily sync handles activation.

The architecture "magic solve" (tech proposal): Iterable Data Share now exposes unencrypted email + transaction_id in Snowflake, so transaction_id becomes the unification join key. SFMC takes signup-priority 1, Iterable priority 2 for dedupe. Daily smart-ingest sync at 3-4am PT pushes Gold to Iterable Profiles. Five new silver models, one simplified gold sync, refactored backfill model.

Outcome milestones tied to specific dates (not week ranges): hashing solve in production by end of May; unified C360 + first audience scores by mid-June; Funnel.io + Iterable pipelines automated by July 4.

The 10 structural patterns worth absorbing for RDCO

These are what makes the artifacts work as commercial documents. Each is reusable in any RDCO services proposal shape — they encode design discipline, not domain knowledge.

1. Single-page visual one-pager format

Not a 20-page narrative SOW. High density, strong typography hierarchy, modular content blocks. Signals craft. Removes proposal-fatigue friction. The buyer reads the whole thing in 90 seconds, gets the shape, and can take it into an exec conversation without preamble.

RDCO application: Client Reporting Automation pitch, MAC consulting tier, future FDE proposals all should default to this format. Multi-page only when procurement explicitly requires it.

2. Two-panel opener: pain in client's language, then solution

"The Opportunity" panel names the client's operational pain in THEIR words — "data foundation underneath it has stalled," "SMS opt-ins sit on placeholder profiles," "competitors leveraging AI-driven marketing to win the resale and trade-in funnel." MG's framing language doesn't appear until after the client's pain has been mirrored.

RDCO application: any services pitch should open with the buyer's pain in their language. For MAC: "your team is shipping data quality coverage that misses the edge cases your stakeholders find on the dashboard, and the fixes are landing in the wrong week." For Client Reporting: "your monthly close compiles 40 hours of human stitching across spreadsheets that nobody trusts."

3. "One Build, Multiple Consumers" matrix mapping capability → named internal champions

The marketing proposal includes a panel mapping each capability to three internal stakeholders by FIRST NAME (Dhwani / Andrea / Alec) with what each gets. Turns ONE engagement into THREE internal advocates inside the buyer's organization.

RDCO application: in any multi-stakeholder pitch, identify 2-3 internal champions by name and show what each gets from the engagement. The named-person specificity is what makes this work — it forces the seller to actually map the value chain.

4. "Why us, why now" RELATIONAL case (not capability-list)

The five-pillar block argues from RELATIONSHIP not CAPABILITY:

• Prior Art — existing MSA + 4 prior SOWs → zero procurement delay
• Self-Funded — discretionary, outside IT queue (sells around organizational friction)
• Apollo Mandate — references a specific executive directive that makes this work feel pre-approved
• Agentic Speed — measurably 4x faster
• Zero Ramp — same partner, full context retained from prior work

Notably ABSENT: a list of MG capabilities. The case is "we already know your org and your data; we can move faster than anyone else without ramp time."

RDCO application: when pitching to a buyer who has prior context with the founder (phData clients, MG alumni connections, etc.), lead with relational specificity not capability claims.

5. Outcome milestones with specific dates, not week ranges

"End of May," "mid-June," "July 4" — not "Week 4-6 deliverable." Specific dates pin the engagement to a real calendar and surface accountability before any scope debate.

RDCO application: every services proposal should commit to specific dates, not week-N labels. Forces the seller to actually think through the calendar. Buyer sees commitment.

6. Strikethrough cycle-time row as visual proof of agentic speed

The MammothOS phase row (THINK / PLAN / BUILD / EVALUATE / ADOPT) shows day-scale estimates STRUCKTHROUGH and replaced with hour-scale estimates. Visual claim that agentic delivery collapses cycle time. Rhetorical device worth keeping.

RDCO application: for any RDCO services pitch where agentic delivery IS the differentiator (which is all of them), find the equivalent visual proof element. Could be the same strikethrough device, or a "before/after" cycle-time bar chart, or specific time-stamped artifacts (skill ship date → output date → review cycle date).

7. Paired commercial + tech docs, same visual system, only commercial has price

The tech-proposal one-pager carries no dollar figure. Lets the architect speak architect language (medallion layers, join keys, model names, field counts) without polluting the commercial frame. The commercial doc gets the executive buyer; the tech doc gets the engineer buyer; both share the same visual identity so they're obviously the same engagement.

RDCO application: for any deal where there's both an executive buyer and a technical buyer, ship paired commercial + tech docs in the same visual system. MAC commercial pitch + MAC tech-architecture one-pager. Client Reporting commercial + Client Reporting data-flow one-pager.

8. On-page risk register with 8 named mitigations

The tech proposal exposes 8 specific risks with mitigations on the same page:

• Encryption fallback if Data Share slips
• Gold parity validation before cutover
• Data Share timing
• Double-counting dedupe
• Array-field growth
• Performance regression
• Email casing drift
• Q3 Gazelle trade-in flow accommodation

Unusually transparent for a sales artifact. Signals operational maturity. Builds engineer-buyer confidence because the risks the engineer is ALREADY worried about are surfaced and addressed.

RDCO application: every RDCO tech proposal should include an on-page risk register with named mitigations. Most agencies hide risks until contract negotiation; surfacing them on the sales artifact is a maturity signal.

9. Field-count specificity, not abstract C360

The tech proposal's unified customer profile is described as "21 fields across 3 categories" with specific counts called out ("7 fields," "6 fields," "8 fields") for each category. Not "comprehensive C360" or "rich customer profile" — concrete field counts that signal real deliverable shape.

RDCO application: any RDCO services proposal that promises a data artifact (matrix, dashboard, profile, report) should commit to specific counts: "12 dbt tests across 4 categories," "6 dashboard tiles with named metrics," "8 retainer-week deliverables." Concrete numbers prove the deliverable was actually scoped, not boilerplate.

10. Branded methodology framework (MammothOS) with named phases

MG names its methodology — MammothOS, with THINK / PLAN / BUILD / EVALUATE / ADOPT phases. Visual proof-of-discipline. Lets the buyer understand the engagement as following a system, not as ad-hoc consulting.

RDCO application: name the RDCO services methodology. Could be tied to the 4-tier BUY/BUILD model ([[concepts/2026-05-14-four-tier-buy-build-stack-soloproneur-tam-filter]]) — e.g. "the Buy/Build Audit" or "the Tier-3 Build Wedge" or "the Operating Stack Review." Whatever the name, the buyer should understand they're getting a system, not a one-off project.

MG's broader positioning to study

The branding is "AI-FIRST DATA AGENCY." MammothOS framework. Tagline pair: "agents build, humans direct and judge." The strikethrough cycle-time claim is the load-bearing differentiator — they're not selling cheaper consulting, they're selling FASTER consulting via agentic delivery.

This is the same productization-gap thesis RDCO has been working ([[concepts/2026-05-13-fde-asymmetric-edge-rdco-positioning]]). MG is operating at agency scale; RDCO operates at solo-operator scale. The agentic-speed positioning works the same way at both scales.

What RDCO should NOT borrow

Not everything from MG's proposal pattern is transferable:

• The brand-name dropping in the credentialing strip — MG name-drops Apollo, ISO 27001, project counts, analyst recognition. RDCO doesn't have these yet; faking them would be brittle.
• The "discretionary budget outside IT queue" framing — MG benefits from being a known-quantity agency that buyers already have on their MSA list. RDCO is new; that framing wouldn't land.
• The medallion architecture-specific examples — Snowflake medallion + dbt is MG's specific competence area. RDCO's tech proposals would name their own architecture surface (e.g. the 4-tier BUY/BUILD model + Claude substrate + skill harness).

Mapping against Ray Data Co

The 10 structural patterns above each carry an RDCO application call-out — that's the load-bearing translation work. Beyond the per-pattern applications, three meta-observations on how this artifact set maps against RDCO's positioning:

1. MG operates at agency scale; RDCO operates at solo-operator scale — same agentic-speed positioning. MG's strikethrough day-to-hour cycle time, "AI-FIRST DATA AGENCY" brand, and "agents build, humans direct and judge" tagline all sit inside the same productization-gap thesis ([[concepts/2026-05-13-fde-asymmetric-edge-rdco-positioning]]) RDCO has been building. MG is selling at $98k engagements; RDCO sells at $350 (MAC) to $10k+ (Client Reporting) tiers. Different price points, same operating-model differentiator.

2. The single-page visual proposal format is a brand-design decision RDCO already owes itself. The founder's design-taste memories (hand-drawn / engraving / texture-over-flat) make this a natural surface to apply the RDCO umbrella design system. The MG aesthetic is corporate-data-agency-clean; RDCO's would be the engraving-doodle-texture aesthetic from ray-data-co-design skill applied to a high-density one-pager. Same structural patterns, different visual identity.

3. The risk-register transparency pattern is the load-bearing RDCO-aligned tactic. Most agencies hide risks until contract negotiation. Surfacing 8 named mitigations on the sales artifact is exactly the operational-maturity signal that "agentic, but disciplined" RDCO positioning needs. Worth absorbing as a non-negotiable element of every RDCO services proposal.

Pattern-study to RDCO-asset translation

Concrete next steps when RDCO ships its first commercial services proposal:

1. Build the one-page proposal template — establish the visual system (typography, panel hierarchy, color palette tied to RDCO's design tokens) once, then specialize per engagement. Pair with a separate tech-spec template using the same visual system.
2. Name the methodology — pick a working name (e.g. "Buy/Build Audit" tied to the 4-tier model). Refine as engagements ship.
3. Build the risk-register pattern — for every RDCO services category, maintain a baseline 5-8-mitigation risk register that gets adapted per engagement.
4. Lock the field-count discipline — every deliverable promise in a proposal should have a count.
5. Lock the dated-milestone discipline — every engagement should commit to 3-5 dated outcomes, not week-N labels.

Related

• [[concepts/2026-05-14-four-tier-buy-build-stack-soloproneur-tam-filter]] — RDCO's 4-tier model is the natural methodology framework to name; MG's engagement is a worked example of tier-2 + tier-3 services delivered by an agency
• [[concepts/2026-05-13-fde-asymmetric-edge-rdco-positioning]] — the productization-gap thesis MG is operating in at agency scale, RDCO at solo-operator scale
• [[01-projects/services-offering/2026-04-16-client-reporting-automation-one-pager.md]] — existing RDCO services one-pager attempt; should be revisited against this pattern study
• [[01-projects/mac/2026-05-14-mac-pricing-intent]] — MAC pricing decision; the proposal one-pager for MAC's higher-touch tier (if it exists) should use this pattern
• [[06-reference/source-pdfs/2026-05-12-mg-ecoatm-proposal-marketing-data-rescue-reactivation.pdf]] — archived commercial proposal
• [[06-reference/source-pdfs/2026-05-12-mg-ecoatm-tech-proposal-identity-resolution-architecture.pdf]] — archived tech proposal