企业客户战略账户规划

作者原文

Strategic account planning and execution for enterprise deals. Use when planning complex sales cycles, managing multiple stakeholders, applying MEDDICC qualification, tracking deal health, or building mutual action plans. Includes the "stale MAP equals dead deal" pattern.

SkillPi 解读

能完成的任务

企业客户战略账户规划

适合谁

请按作者原文中的适用场景判断。

输入和输出

以作者完整文档为准；本站未运行验证产物。

软件、账号及付费要求

使用前按完整文档确认软件、账号、费用及权限；由宿主核对并授权实际文件读写和外部服务。文档引用域名（非运行白名单）：github.com, linkedin.com

限制与区别

原文中的功能、版本状态和效果描述属于作者陈述；中文为对应翻译。仅核对固定版本及静态附件证据，不保证运行效果、外部服务或兼容性。

实测状态

未测试

安全评级与访问范围

caution · 静态证据核验，不代表运行安全保证。

使用前按完整文档确认软件、账号、费用及权限；由宿主核对并授权实际文件读写和外部服务。文档引用域名（非运行白名单）：github.com, linkedin.com

使用前请由宿主核对并授权实际文件读写、外部服务和联网目的地；本站的核验不会授予任何运行权限。

原始 SKILL.md

---
name: gtm-enterprise-account-planning
description: Strategic account planning and execution for enterprise deals. Use when planning complex sales cycles, managing multiple stakeholders, applying MEDDICC qualification, tracking deal health, or building mutual action plans. Includes the "stale MAP equals dead deal" pattern.
license: MIT
metadata:
  author: Smit Patel (https://linkedin.com/in/smitkpatel)
  source: https://github.com/beingsmit/technical-product-gtm
---

# Enterprise Account Planning

Strategic account planning and execution for enterprise deals. Turn complex sales cycles into systematic wins — or at least know when they're dying before you waste months.

## When to Use

**Triggers:**
- "How do I plan this enterprise deal?"
- "This deal has been in motion 3 months, why isn't it closing?"
- "Should I create a full account plan or simplified version?"
- "How do I know if this deal is actually moving?"
- "MEDDICC qualification"
- "Building a mutual action plan"

**Context:**
- Strategic deals above your average ACV
- Multiple stakeholders involved
- Sales cycle exceeds 60 days
- Complex buying process (legal, procurement, security)
- Enterprise or mid-market accounts

---

## Core Frameworks

### 1. If Your MAP Hasn't Been Updated in 3 Weeks, That Deal Is Dead

**The Pattern I've Seen:**

The Mutual Action Plan (MAP) is the single best indicator of deal health. Not pipeline stage. Not verbal commitments. Not "they love the product."

**The MAP tells you everything:**

**Healthy deal:**
- MAP updated weekly
- Customer adding their own action items
- Both sides completing tasks on schedule
- New stakeholders appearing in MAP
- Dates moving up (not pushed out)

**Dying deal:**
- MAP last updated 3+ weeks ago
- Only your side has action items
- Customer tasks marked "pending" for weeks
- No new stakeholders engaged
- All dates in the past

**Why This Happens:**

When a deal is real, the customer wants it to happen. They're doing work. They're involving stakeholders. They're moving through their process.

When a deal is dying, you're doing all the work. They're "too busy." They'll "get back to you next week." The economic buyer is "traveling."

**The 3-Week Rule:**

If your MAP hasn't been updated in 3 weeks, the deal is dead — you just don't know it yet. **I've never seen a deal close with a stale MAP. Not once in 11 years.**

**What to Do:**

**Week 1 of silence:** Send MAP update: "Here's what we've completed. What's your status on [specific customer action]?"

**Week 2 of silence:** Escalate to champion: "Haven't heard back on MAP. Are we still on track for [date]? If priorities shifted, let me know."

**Week 3 of silence:** Qualify out or reset: "It seems like timing might not be right. Should we pause and reconnect in [timeframe], or is there a blocker I can help with?"

**Common Mistake:**

Keeping deals in pipeline because "they said they want it." Verbal interest ≠ action. If they're not doing work, they're not buying.

---

### 2. The EB Discovery Problem (And Why Deals Die at Week 8)

**The Pattern:**

You're 8 weeks into a deal. POC went great. Champion loves you. Technical validation complete. You send the proposal.

Then: radio silence.

**What happened?** You never met the Economic Buyer.

**The Economic Buyer (EB) is the person who:**
- Controls budget allocation
- Makes final purchase decision
- Signs the contract

**Not:**
- Your champion (they influence, don't decide)
- The technical lead (they validate, don't buy)
- The VP who attended one demo (they advise, don't sign)

**Why Deals Die Without EB Access:**

You built the business case with your champion's assumptions. But the EB has different priorities:
- Champion cares about: solving their team's pain
- EB cares about: ROI, risk mitigation, strategic alignment

When you send proposal to EB through the champion, EB sees:
- Price tag with no context
- Solution to a problem they didn't articulate
- Risk they haven't evaluated

**Result:** Deal stalls or dies.

**The Framework: EB Validation Checklist**

Before sending proposal, validate:

- [ ] Have you identified the EB? (Name, title, confirmed by champion)
- [ ] Have you met the EB? (Video call minimum, in-person ideal)
- [ ] Does EB agree on the problem? (In their words, not yours)
- [ ] Does EB agree on success metrics? (How they'll measure ROI)
- [ ] Does EB know the price range? (Ballpark discussed, not surprised)
- [ ] Does EB understand timeline? (Implementation, go-live, value realization)

**If you answered "no" to any, don't send the proposal yet.**

**How to Get EB Access:**

**Ask your champion:**
"Before we finalize pricing, I'd love 15 minutes with [EB name] to make sure we're aligned on outcomes and timeline. Can you intro us?"

**If champion blocks:** "I can handle that, you don't need to talk to them"
→ This is a red flag. Either champion doesn't have access (not a real champion) or they're afraid EB will kill the deal (which means deal is weak).

**Push back:**
"I totally understand. At the same time, I want to make sure [EB] sees the full value before seeing the price. In my experience, when economic buyers aren't involved early, deals get delayed in procurement. Can we do a quick alignment call?"

**Common Mistake:**

Treating EB meeting as "nice to have." It's mandatory for any deal >$50K. No EB access = no deal.

---

### 3. Personal Win Mapping (People Buy for Themselves)

**The Pattern:**

Enterprise software purchases are made by committees. But committees don't buy. **People buy.**

And people buy for personal reasons:
- Career advancement
- Looking good to their boss
- Reducing their workload
- Covering their ass (CYA)
- Proving they were right
- Not looking stupid

**Framework: Personal Win Identification**

For each stakeholder, map:

**Professional Win:**
- What do they get credit for if this succeeds?
- What pain goes away for them personally?
- How does this make them look good?

**Professional Risk:**
- What happens to them if this fails?
- What's their reputation cost if this goes wrong?
- Who's skeptical of them internally?

**Personal Motivations:**
- Are they new in role? (Need quick wins)
- Facing budget cuts? (Need to justify spend)
- Up for promotion? (Need visible success)
- Burned by vendors before? (Extra risk-averse)

**Example: VP of Engineering**

**Professional Win:**
- Reduce on-call burden for team (they'll stop complaining to her)
- Faster incident response (looks good in QBRs)
- Attract better eng talent (modern tooling)

**Professional Risk:**
- Team rejects new tool (she forced it on them)
- Migration goes badly (downtime, incidents)
- Vendor fails (she picked them)

**Personal Motivations:**
- New in role (6 months), needs wins
- Under pressure to improve uptime metrics
- Previous monitoring tool she picked failed

**How This Changes Your Pitch:**

**Generic pitch:**
"Our platform improves incident response time by 40%."

**Personal win pitch:**
"You mentioned the on-call burden is burning out your team. We've seen teams reduce on-call pages by 40% in the first month, which helps with retention. And since you're focused on uptime metrics for the board, the improved response time shows up immediately in your QBR dashboards."

**The Difference:**

Generic = business case
Personal = career case

Both matter. But personal wins close deals.

**Common Mistake:**

Selling only to the business problem. "This saves money. This improves efficiency." That's necessary but not sufficient. **People need to see what's in it for them personally.**

---

### 4. Enterprise Account Plan Structure (Four Components)

A complete account plan has four interconnected pieces. Each feeds the others.

**Component 1: Account Summary**
- Company basics (HQ, size, industry, subsidiaries)
- Technical landscape (infrastructure, tools, platforms)
- Top corporate initiatives (from press, annual reports, LinkedIn)
- Hypothesis: "How can we help?" (write this before engaging)
- LinkedIn keyword analysis (quantify their investment in your domain)

**Component 2: Org Chart**
- Map all relevant contacts: name, title, location, LinkedIn, email, phone, notes
- Notes capture: domain of responsibility, technical specialties, personal win
- Include people across levels: C-suite, directors, architects, leads, specialists
- Don't just map buyer — map influencers, users, potential blockers

**Component 3: Opportunity Plan (MEDDICC)**
- **M - Metrics**: How will the customer measure success? (Validated with EB)
- **E - Economic Buyer**: Who has budget authority? Have you met them?
- **D - Decision Criteria**: What criteria will they use to decide? (Technical, business, political)
- **D - Decision Process**: What's their buying process? (Procurement, legal, security review)
- **I - Identified Pain**: What specific pain have they articulated? (Their words, not yours)
- **C - Champion**: Who inside the account is actively selling on your behalf?
- **C - Competition**: Who else are they evaluating? What's the competitive dynamic?

Plus: Issues/Risks table with mitigation plans, help needed, responsible parties

**Component 4: Mutual Action Plan (MAP)**
- Joint timeline with: Action, Your Owner, Customer Owner, Others Involved, Due Date
- Both sides must have actions — if only your team has actions, it's not a deal, it's a demo
- Track status (complete/in-progress)
- Use MAP as running agenda for check-in calls
- **If MAP isn't updated in 3 weeks, deal is dead**

**Decision Criteria:**

Full account plans worth investment for top 10-20% of accounts by potential deal size. For rest, use simplified version (summary + MEDDICC + next steps).

**Common Mistakes:**
- Creating account plan after deal is in motion (build before first engagement)
- Not maintaining MAP weekly (stale MAP = stale deal)
- Filling MEDDICC with assumptions instead of validated info
- Mapping only obvious contacts instead of full org chart
- Not tracking personal win for each stakeholder

---

### 5. LinkedIn Keyword Analysis for Account Intelligence

Before engaging strategic account, quantify their investment in your domain via LinkedIn.

**How to Execute:**

1. Define 8-10 keywords relevant to your space (e.g., category terms, technical roles, workflow keywords)
2. Search LinkedIn for "[company name] + [keyword]" and record count
3. Map concentrations: Which locations? Which departments?
4. Identify outliers (high keyword concentration in specific departments signals maturity)

**Why This Works:**

If a company has 50 employees with "SRE" in their profile, they're mature in site reliability. If they have 2, they're not ready for advanced observability tools.

This tells you:
- Whether to pursue the account (do they have the team?)
- Who to target (where are the concentrations?)
- How to personalize outreach (reference their specific context)

**Example:**

Searching "[Company] + DevOps":
- 120 results → Mature DevOps org, good fit
- 5 results → Early, not ready

Searching "[Company] + SRE":
- 50 results → They care about reliability, pitch uptime/incident reduction
- 0 results → Don't lead with SRE value prop

**Common Mistakes:**
- Just searching job titles (vary wildly) instead of keywords (consistent)
- Not comparing counts to total employee count
- Not refreshing analysis (hiring trends change quarterly)

---

### 6. The Unified Sales Process (Stage Gates)

Enterprise sales follows defined stages with clear exit criteria. Don't advance stages without meeting criteria.

**Stage 0 — Pipeline Generation:** Prospecting → Qualified interest confirmed
**Stage 1 — Discovery:** Environment/pain/requirements → Pain identified, stakeholders mapped
**Stage 2 — Demonstrating:** Product demo, champion building → Champion identified
**Stage 3 — Proving Value:** POC/trial → Technical validation complete
**Stage 4 — Proposal:** Pricing, terms, scope → Proposal delivered, EB aligned
**Stage 5 — Paper Process:** Legal, procurement, security → Approvals secured
**Stage 6 — Closed Won:** Deal signed → Customer success handoff

**Exit Criteria Matter:**

Don't move from Stage 2 → Stage 3 until you have a champion.
Don't move from Stage 3 → Stage 4 until POC success criteria are met.
Don't move from Stage 4 → Stage 5 until EB has approved.

**Common Mistake:**

Advancing stages based on activity, not criteria. "We demoed, so we're in Stage 3" — but if they haven't agreed to POC, you're still in Stage 2.

---

## Decision Trees

### Do I Need a Full Account Plan?

```
Is deal size above average ACV?
├─ No → Simplified plan (summary + MEDDICC)
└─ Yes → Continue...
    │
    Sales cycle >60 days?
    ├─ Yes → Full account plan
    └─ No → Simplified plan
```

### Is This Deal Actually Moving?

```
Is MAP being updated weekly?
├─ Yes → Healthy
└─ No → Continue...
    │
    Has it been >3 weeks since last MAP update?
    ├─ Yes → Dead deal (qualify out or reset)
    └─ No → At risk (escalate to champion)
```

### Should I Send the Proposal?

```
Have you met the Economic Buyer?
├─ No → Don't send yet (get EB access first)
└─ Yes → Continue...
    │
    Does EB agree on problem and success metrics?
    ├─ Yes → Send proposal
    └─ No → Align with EB before sending
```

---

## Common Mistakes

**1. Creating account plan too late**
   - Build before first engagement, not after deal is in motion

**2. MEDDICC filled with assumptions**
   - Validate each element with customer, don't guess

**3. Stale Mutual Action Plan**
   - If MAP isn't updated weekly, deal is stalling. 3+ weeks = dead.

**4. Mapping only the buyer**
   - Need full org chart: influencers, users, blockers

**5. Ignoring personal wins**
   - People buy for career/reputation reasons, not just business ROI

**6. Not tracking deal health**
   - Green/yellow/red indicators catch dying deals early

**7. Skipping champion validation**
   - Without internal champion, you're selling alone

---

## Quick Reference

**MAP Health Check:**
- Green: Updated weekly, both sides have actions, customer completing tasks
- Yellow: Updated bi-weekly, mostly your actions, customer slow to respond
- Red: 3+ weeks stale, only your actions, customer unresponsive → **Dead deal**

**MEDDICC Validation:**
- [ ] Metrics: Success criteria agreed with EB
- [ ] Economic Buyer: Met them, validated problem/solution
- [ ] Decision Criteria: Understand their evaluation rubric
- [ ] Decision Process: Know procurement/legal/security steps
- [ ] Identified Pain: In customer's words, not yours
- [ ] Champion: Actively selling internally on your behalf
- [ ] Competition: Know alternatives they're considering

**Personal Win Questions:**
- "What does success look like for you personally?"
- "What happens to your team if this works? If it doesn't?"
- "What are you being measured on this year?"
- "Who internally is skeptical? Why?"

**Account Plan Checklist:**
- [ ] Account summary with hypothesis
- [ ] Org chart with personal wins mapped
- [ ] MEDDICC fully validated (not assumed)
- [ ] MAP with customer actions (not just yours)
- [ ] Weekly MAP update cadence scheduled

---

## Related Skills

- **enterprise-onboarding**: Post-close customer implementation
- **partnership-architecture**: Deals involving partner relationships
- **technical-product-pricing**: Enterprise pricing strategy

---

*Based on enterprise sales at a platform company during hypergrowth, with patterns from closing strategic accounts, navigating complex procurement processes, and learning the hard way that stale MAPs = dead deals. Not theory — lessons from watching deals die because we didn't track health metrics and closing deals because we validated EB alignment early.*

版权与许可声明

MIT License

Copyright GitHub, Inc.

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.