TAM Expertise
TAM Expertise — BI, Reporting, Writing, Risk, Churn, Sentiment & Account Management
Reference skill compiled from 120+ authoritative sources. Full context in tam-expertise-context.md.
When NOT to use
- MongoDB Premium Services operating procedures → use
tam-reference - Active case management and TS Tools API → use
case-tracker - Atlas cluster diagnostics and troubleshooting → use
atlas-diagnostics-expert - Code review, frontend design, or implementation tasks → use domain-specific skills
When to use
- Writing or reviewing account deliverables (EBRs, QBRs, architecture reviews, post-mortems, runbooks, migration guides, case notes)
- Assessing account health, churn risk, or customer sentiment
- Building KPI frameworks, dashboards, ROI analyses, or adoption reports
- Applying communication frameworks (BLUF, STAR, Pyramid, SCQA, Diataxis)
- Onboarding accounts (30-60-90), managing escalations, navigating stakeholder dynamics
- Benchmarking SaaS metrics, calculating NRR, or scoring customer health
Skill guidance
- Treat
tam-expertise-context.mdin this directory as the source of truth for frameworks, templates, and benchmarks. - Prefer the frameworks, checklists, templates, and benchmarks in the context before improvising.
- Cross-reference with
tam-referencefor MongoDB Premium Services specifics. - Cross-reference with
case-trackerfor case management specifics. - Apply the Diataxis framework for document structure and BLUF/Pyramid/STAR for communication.
- SaaS benchmarks are 2025-2026 vintage; verify current figures for customer-facing deliverables.
Common mistakes
- Mixing Diataxis types: a runbook (how-to) that drifts into explanation, or a reference doc that tries to teach via tutorial.
- Unoperationalized RYG scores: every score state needs a mandatory action, not just a color.
- Benchmarks without recommendations: presenting a number without a prescriptive next step.
- Score inflation: defaulting accounts to Green without data-backed justification.
- Single-audience framing: writing for engineers when the deliverable serves both engineers and executives. Use layered structure: exec summary → findings → technical appendix.