How I'd approach the post-sales function for Allium's usage-based data platform: onboarding to first value, a usage-based health model, expansion, QBRs, and the voice-of-customer loop — plus a benchmark of Allium's support/success against peers. Company facts are sourced; the CS models are illustrative frameworks I'd propose.
Allium sells data into other people's systems — Snowflake, BigQuery, Kafka — on consumption pricing. A customer can churn quietly: usage decays and one quarter they don't recommit. So the CS job is to prevent that — wire the data in fast, watch the usage signals, and keep finding the next workflow it should power, tied to an outcome the customer cares about. That maps to what I've done: I run a live data-API product (consumes commercial APIs, serves its own REST API — Allium's business from both sides), worked the customer ↔ engineering seam at a Bitcoin L2 (BOB) and an Ethereum app (Aztec), and built AI-QA scorecards + Python eval harnesses at KIP. This page sketches how I'd run it.
Allium is "the system of record for onchain finance" — it translates raw data from 150+ chains into clean, decoded, audit-ready tables, then delivers them wherever the customer already works. The Series B (Amplify Partners, with Kleiner Perkins, Theory Ventures & Pruven Capital) and the "build out post-sales + hire the team" framing of this role say the same thing: Allium has product-market fit and is now scaling the customer base it has to defend and expand. That's the CS mandate.
Visa (Onchain Analytics, with BCG), Stripe, Coinbase, Uniswap, Phantom, MetaMask, MoonPay, Grayscale, Magic Eden — with data cited by the Federal Reserve, Stanford and Paradigm. Sold as data shares (Snowflake premier partner, BigQuery, Databricks Delta Sharing) on credit-based usage pricing.
Two buyer types in one book of business: institutions with mature data stacks, and self-serve developers on the free tier scaling up. §03 splits the motion.
Series B / customer / funding figures: Business Wire, Fortune & Allium blog (Jun 2026) — cited in §12. Tagged reported where they come from company or press announcements rather than a metric I can independently recompute.
Nine responsibilities in the JD. Here's what each one actually means week-to-week for a usage-based data infra product, and where I cover it on this page.
| JD responsibility | What it means in practice here | Covered in |
|---|---|---|
| End-to-End Customer Journey | Own onboarding, adoption, training, renewals, advocacy & expansion: wire data into their warehouse fast, then keep deepening it. Renewal is a lagging side-effect of adoption. | §04 · §06 |
| Strategic Success Planning | Scalable success strategies aligned to lifecycle stage and revenue goals: triggered playbooks, in-product nudges, lifecycle content tuned to each stage. | §03 · §04 |
| Expansion Leadership | Partner with Sales on upsell / cross-sell (Explorer → Developer → Datastreams, more chains / seats), fired by usage signals. | §06 |
| Executive Alignment | Trusted strategic advisor: multi-thread beyond the one data engineer; map an exec sponsor; QBRs in their currency (FTEs saved, infra avoided). | §07 |
| Product Collaboration | Translate feedback into product insight — coverage gaps & schema pain, incl. behavioral VoC (failed queries, uncovered chains), routed weighted by ARR. | §08 |
| Customer Health Metrics | A comprehensive, usage-led health-scoring system that catches silent at-risk decay before the recommit — the central risk of consumption CS. | §05 |
| Process & Playbook Development | Frameworks, QBR templates, customer-education & proactive-engagement models the growing team reuses. | §07 · §10 |
| Customer Advocacy | Turn green-health customers into references, case studies, logos & product-advisory-board members. | §05 · §08 |
| Team Leadership (Future) | Contribute to early hiring, mentoring & scaling of the CS org — I've already managed & mentored customer-facing teams; design the playbooks & tiering a growing team runs. | §03 · §10 |
Requirements: 5+ yrs CS / account management / partnerships incl. team-building; depth in Web3 / blockchain / infra-as-a-service with developer-workflow fluency; both enterprise and high-velocity digital-first users; health modeling & account planning; early-stage company experience; cross-functional with product / eng / sales. Fit mapped in §11.
The JD asks for someone who can run both a Visa-class account and a long tail of self-serve developers. You can't give every logo a named CSM, and you can't run Visa out of a shared inbox. The answer is explicit tiering by expansion potential & strategic value — then let automation handle everything below the line so human hours flow where a human changes the outcome.
~10–20 named accounts. Named CSM + SE, mapped exec sponsor, Slack Connect, quarterly QBRs, proactive schema-change briefings. Justified by a large expansion ceiling & reference value.
~40–80 accounts across a pod. Shared queue, 1-to-many onboarding webinars & office hours; human touch fires on a health/usage trigger. QBR-on-demand.
Hundreds of self-serve devs. No named human by default — in-product nudges, docs, lifecycle email, an AI support agent (Intercom Fin) for deflection, community. A human appears only on a product-qualified signal (sudden 5× usage, a prod pipeline).
Because this is a data/dev product, the highest-leverage CS channel is the console and the docs. Empty-state prompts ("run your first query on Ethereum logs →"), a banner at 70% / 90% of committed datastream throughput, a cross-chain nudge ("you've queried Ethereum 200× — the same query runs on Base"). Health scores computed in the warehouse (dogfooding Allium's own product) feed Slack alerts and auto-assign playbooks. Tiering is dynamic: a digital account that crosses a usage threshold gets promoted; a flat, unresponsive Tier-1 gets relegated.
Onboarding means data flowing into the customer's own systems, with a person depending on it. Every step moves the data closer to load-bearing; time-to-value is measured in days.
Consumption customers rarely announce churn — usage quietly decays and they don't recommit. So the model leans on leading usage signals; the usage trend tells you more than relationship sentiment. Here's the model I'd ship (weights sum to 100%).
The top five signals are all usage/adoption-based (74%); relationship signals are 16% by design. For self-serve, "exec engagement" becomes "≥2 active users".
A sharp, sustained usage drop forces the score toward red even if relationship signals are green. "Healthy but coasting" — high relationship score, flat usage far below commit — is a disguised red: shelfware that won't recommit at the same level. Alert on threshold crossings in near-real-time, while there's still time to act.
Health computed in-warehouse on Allium's own product → CS tool + Slack alerts → auto-assigned playbooks. This is the analytic muscle I built as an analyst at KIP Protocol (AI-QA scorecards, Python eval harnesses) and certified via HubSpot RevOps (KPI / dashboard design, forecast validation).
In consumption pricing, expansion is mostly won by adoption — find where usage already proves appetite, then place the offer. Two axes, fired by concrete triggers.
Explorer (explore) → Developer (build against the API) → Datastreams (real-time). Each step is a larger, stickier contract.
More chains, more protocols, more datasets (transfers → DEX trades → NFT → lending), and more seats / teams within the same logo — the compliance team's win pulls in trading and product.
Mechanics: CSM surfaces the signal and writes the expansion thesis, partners with the AE to close on Tier-1, and routes self-serve devs through an in-product upgrade path (add a chain, bump throughput) with a human only on the larger jumps. Green health accounts are the expansion pipeline — handed to the AE with a usage-evidenced thesis already attached. This is the BD-pipeline discipline I ran at deBridge (target → pitch → integration, e.g. 1inch), now pointed at installed-base growth.
A QBR for a data subscription must answer one question for the customer's exec: "what did this data let us do that we couldn't — or would have paid more to do — otherwise?" Structure it as a story, anchored to the value defined at kickoff.
Lead with what they shipped/saved: "Allium now powers your compliance dashboard across 6 chains; you retired your in-house indexer (~1.5 FTE saved)."
The usage data as evidence of value — each metric paired with the workflow it powers, with the trend line.
Licensed-but-unused datasets; use cases peers run that they don't; chains adjacent to what they query. Seeds expansion without a sales pivot.
An honest view. Over commit → frame the upsize now (good problem). Under → a joint adoption plan so renewal isn't a downgrade. No surprises at renewal.
New chains/datasets relevant to them, and the status of feature requests they filed — closing the VoC loop visibly is a huge trust-builder for technical buyers.
A concrete next step tied to an outcome: "to extend to your Solana line, here's the dataset + a 2-week eval." Leave with a documented outcome, owners, dates.
Bring the data engineer and the exec sponsor — multi-thread the QBR itself. Quantify ROI in their currency: FTEs saved, infra avoided vs. self-running nodes/indexers, faster time-to-market, revenue enabled. Quantified ROI is what carries the renewal.
Technical buyers judge you by whether their feedback changes the product. The JD's "translate feedback into product insights" only works if the loop is visible and evidence-rich.
QBRs, tickets, Slack Connect, churn reasons — and the unbiased signal customers never file: failed queries, chains they tried to query but you don't cover, high-interest / low-coverage datasets. Usage data is feedback.
Every item tagged: account, ARR at stake, use case, type (coverage gap / data-quality / schema / freshness / docs), severity. Route aggregated themes: "$1.4M ARR across 6 accounts blocked on Solana DEX decoding."
When product ships, tell the customers who asked (gold for renewals); tell product the outcome ("Solana decoding unblocked 4 accounts → $X expansion") so the next ask carries weight. A loop that visibly moves the roadmap is itself a retention feature.
This is the customer ↔ product seam I worked at Aztec (relayed structured user feedback to product) and BOB (docs born from recurring ticket themes). The discipline is the same; here it's weighted by revenue and backed by usage telemetry.
CS for a blockchain-data platform has failure modes a generic SaaS CSM never meets. Naming them honestly is half the job.
| The hard problem | Why it bites on a data product | How a great CSM mitigates it |
|---|---|---|
| Schema changes break pipelines | Allium data lives in their dbt models & prod consumers; a column rename silently breaks them — and it reads as your outage. | Own a CS↔Product deprecation discipline: map which datasets each account actually queries, warn only the affected accounts before the change, ship a migration note. Outage → handled heads-up. |
| Data freshness / accuracy | Customers benchmark against the chain itself; a reorg lag or decode error on a "real-time" stream reads as a fundamental trust break. | Set explicit freshness SLAs per dataset; proactively disclose incidents (don't let them discover it); fast accuracy-escalation path into data eng; treat any data-trust incident as a health override. |
| Multi-chain coverage gaps | The customer's roadmap moves to a chain you don't decode yet → their use case stalls, the door opens to a rival or in-house build. | Track each account's chain roadmap as a leading indicator; aggregate gap demand into weighted VoC; give honest timelines & bridges — never bluff coverage. |
| Silent churn of data engineers | No renewal drama — the engineer quietly builds in-house, or the champion leaves and usage decays unnoticed. | Lead with usage telemetry over vibes (§05 overrides), multi-thread beyond the one engineer, watch for build-vs-buy tells (usage drop + questions about raw access). |
| Proving ROI on a subscription | Data is an input; the value accrues to their product, so the line back to your invoice fades and it looks cuttable. | Define the ROI baseline at onboarding (nodes/indexers/FTEs avoided), re-quantify every QBR, and make integration so deep the build-it-yourself alternative is visibly more expensive. |
I looked at Allium's public support surface — docs, status page, sign-up, changelog, careers — alongside six blockchain-data peers. The read: Allium already runs a high-touch, audited, enterprise motion; the natural next layer as it scales is scaled enablement (certification, published SLAs, community) — which is squarely CS work.
support@allium.so.allium-cli, MCP/AI tooling, a unified multi-chain SQL schema.| Dimension | Allium | Dune | Nansen | Chainalysis | Flipside | Goldsky |
|---|---|---|---|---|---|---|
| Delivery model | Warehouse-native: Datashares, Datastreams, Realtime APIs, Explorer SQL, Beam | Hosted SQL IDE, dashboards, API; adding warehouse delivery | Curated trader product: labels, Smart Money, alerts, API | Compliance software: KYT monitoring, Reactor tracing | Data Studio SQL, API, Snowflake Shares (data biz → SonarX) | Real-time pipelines: subgraphs, Turbo Pipelines → Postgres/ClickHouse/Kafka |
| Built for | Institutions, fintechs, compliance, data engineers | Analysts, traders, protocol/DAO teams, enterprises | Mainly traders & investors; some desks | Governments, law enforcement, exchanges, banks (70+ countries) | Analysts, protocols, enterprise finance teams | Developers & data engineers building onchain apps |
| Support & success motion | Dedicated CSM + SE; "24/7 enterprise SLA" claim, no numbers | Community/Discord default; enterprise 24/7 Slack, custom SLA | Self-serve/community; ~24h email; no enterprise plan | CSM, TSE, Solutions Architects; 24/7; SLAs undisclosed | Community/Discord; data support/renewals via SonarX | Tiered: Scale 24h email; Enterprise 4h Slack, dedicated |
| Education / certification | CSM programs forming; AI NL-to-SQL; no public academy | Dune 101, video series, Spellbook; no certification | Nansen Academy articles; no certification | Academy: 41k+ certified, 1,500+ institutions, free w/ license | Blog/Discord via CEA bounties; no certification | Docs + support only; no academy |
| Community / self-serve scale | Deliberately closed; free-units tier; no public dashboards | 1M+ users, public dashboards, Spellbook, bounties | Social/Discord; alert distribution; no analyst ecosystem | Closed/proprietary; no public analyst community | CEA token-bounty network: $2M+ paid, ~19k/mo onboarded | Free no-card tier; dev self-serve; no analyst community |
| Reliability / data quality | Status page, SOC 1/2, KTH-validated 0.000011%, weekly changelog | Detailed status page; tracks data-freshness incidents | Curated label accuracy; no public status page found | Proprietary attribution; status page; third-party outage reports | Curated Snowflake datasets; no public status page found | Auto-failover, 24/7 on-call; uptime % undisclosed |
| Pricing model | Consumption credits (Explorer + Developer units, non-expiring); enterprise custom | Credit tiers: Free → Pro ~$400–1,000/mo; Enterprise custom | Free + Pro $49–69/mo; API priced per call | Custom annual; est. ~$50k–200k/yr, contact-sales | Freemium core; usage-billed API/Snowflake; enterprise custom | Transparent usage: free Starter, pay-as-you-go, custom Enterprise |
Compiled from each vendor's site, docs & status pages (Jun 2026); sources in §12. Cells are short reads, not exhaustive; "n/a" where not publicly found.
High-touch CSM/SE + auditable, SOC-certified, KTH-validated data quality (0.000011% deviation vs ~7.2% for Dune / BigQuery) + status transparency — a solid institutional-trust foundation.
Published SLA response tiers, a customer-certification track, and scaled self-serve for the long tail — the usual next steps as a usage-based business grows its base.
Turn the 24/7 SLA into published response tiers, stand up an enablement / certification track for compliance & data personas, and keep curated, audited quality as the core differentiator.
Where the bar sits for usage-based infra CS, researched from public sources (cited in §12). The benchmark that matters for a consumption business is net revenue retention (NRR) — expansion net of churn — because that's what CS is actually paid to move.
NRR ~125% (FY26) → 126% (Q1 FY27), down from 131% in FY24 (and higher before). Dedicated CSMs & QBRs for its largest accounts; CS uses Snowflake's own usage data to prevent churn. Land, expand, operationalize consumption — the template for Allium.
NRR >140% (top-decile); 800+ accounts at $1M+, 70+ at $10M+. Borrow: multi-product adoption is the expansion engine — Explorer → Developer → Datastreams is Allium's version.
Datadog ~120% net retention as a customer's observability footprint grows. Borrow: expansion follows the customer's own growth in usage — the CSM's job is to remove friction from that curve.
Chainalysis Academy ships with every subscription; 41,000+ professionals across 1,500+ institutions certified. Borrow: customer education (the JD's word) is a retention & adoption lever.
Dune: 200k+ public dashboards, 1M+ users; Flipside's bounty-driven "community-enabled analytics" has paid out $2M+. Borrow for the digital-first tier: community & templates scale solutions-engineering past where named CSMs reach.
Snowflake's usage-data-driven CS + Databricks' multi-product expansion + Chainalysis' education flywheel + Dune's community scale for the long tail. NRR benchmarks: strong consumption businesses run ~120–140%+ — a north star for the function.
The rest of this page is the argument; this is the résumé line. 4+ yrs on the customer ↔ engineering seam — Customer Success at an Ethereum app (Aztec), front-line support & docs that cut repeat queries at a Bitcoin L2 (BOB), managing & mentoring the support/community team for thousands of users (FrodoBots), and a partnership BD pipeline at deBridge (→ 1inch). As an analyst at KIP I built the exact health-modeling muscle this role needs — AI-QA scorecards + Python eval harnesses — and I'm HubSpot Revenue Operations Certified. Crucially, I run a live data-API product (Malaysia4U: consumes commercial APIs, serves its own REST API), so I know Allium's business — and its data-engineer buyers — from both sides. Native EN / 中文 / BM, I build onchain AI agents and read SDKs/contracts, so I'm credible to a customer's engineers and Allium's alike.
What I bring is the full seam this role spans — customer-facing depth (Aztec CS, BOB support, Intercom Fin), team leadership (managed support & community teams), data & analytics rigor (KIP scorecards, HubSpot RevOps), the data-API-product domain (Malaysia4U), strategic-partnership & expansion range (deBridge → 1inch), and early-stage range — with a bias toward building repeatable systems. Happy to walk through any section live.
Company facts (Series B, funding, customers, product surface) are sourced from Allium & press and tagged reported. The CS models in §05 / §06 are explicitly illustrative — frameworks I'd propose, not internal Allium numbers. Peer NRR figures in ❖ are from company filings & press. Nothing on this page uses non-public Allium data.
Role: Customer Success Manager · Allium (Ashby)
Company: allium.so
Series B: Fortune — Allium Series B (Amplify Partners)
Allium support surface: docs.allium.so · status.allium.so
Data-quality validation: KTH arXiv 2503.19548 (Allium 0.000011% vs ~7.2%)
Peer CS — Snowflake: NRR 125% (FY26)
Peer CS — Databricks: NRR >140% / 6+ products
Peer CS — Chainalysis Academy: 41k+ certified · Dune: 250k+ dashboards
Claims are split into confirmed (verified from public sources), reported (company / press announcements) and illustrative (CS models I'd propose) throughout; every load-bearing figure was independently fact-checked against primary sources.
Prepared by Edward Tay · for the Allium Customer Success Manager role · Jun 2026 · edwardtay.com · Edwardtay7@gmail.com