The traditional telecom KAM model was built for a world where one account manager could carry the whole relationship: know the customer, manage renewals, and pull in a pre-sales engineer when a technical question came up. That model holds up for connectivity. It breaks when the same KAM is also expected to sell cloud, security, IoT and analytics, each of which needs technical depth that no single person can hold across a full book of accounts.
This module opens Part 4 of the course, Run the Team. It is written for sales leaders structuring a team against a segment target, and it builds on the account planning approach in Module 5 and the stakeholder work in Module 8.
A KAM who has to be the expert on everything ends up being the expert on renewals.
Four roles in a modern telecom KAM model
Figure 1. Four roles. The KAM owns the account; the other three supply depth the KAM cannot be expected to carry alone.
| Role | Owns | Common failure if missing |
| KAM | The account plan, the relationship, and the revenue number | No one is accountable for the account as a whole |
| Solution architect | Pre-sale technical credibility and solution design | Technical questions are answered late or generically, losing deals to hyperscalers (Module 4) |
| Specialist overlay | Deep expertise in one platform category, shared across several KAMs | KAMs avoid selling categories they do not understand, leaving whitespace untouched |
| Service manager | Post-sale service health and usage reporting | Usage data never reaches the KAM, so expansion signals (Module 3) are missed |
Three coverage models
| Model | How it works | Fits when |
| Generalist KAM | One KAM per account set, pulling in pre-sales on request | Book is mostly connectivity and platform deals are occasional |
| KAM plus pooled overlay | KAMs own accounts; a shared pool of specialists covers platform categories | Platform pipeline is growing but not yet large enough to justify dedicated specialists per KAM |
| Pod model | Each KAM is paired with a dedicated solution architect, with specialists pooled | Platform revenue is a material share of the target and deals are technically complex |
Most teams moving from connectivity toward platform revenue pass through all three in sequence. The mistake is jumping to a pod model before platform pipeline justifies the cost, or staying generalist long after technical depth has become the reason deals are lost.
Sizing the team to the target
A useful sizing check starts from the target, not the headcount budget. Work backward through four numbers:
- Target split. What share of the segment target is expected from platform services versus connectivity? If platform is under roughly a fifth of the number, a generalist or pooled model is usually sufficient.
- Deal capacity. How many actively worked platform opportunities can one solution architect support at a time? Use the team’s own recent history rather than an assumed figure.
- Pipeline coverage. Using the qualification scoring from Module 7, how much qualified pipeline is needed to cover the platform portion of the target at the team’s actual win rate?
- Gap. Divide required active opportunities by deal capacity per architect. The result is the technical headcount the target implies, which can be compared directly against what the team currently has.
Worked example
A five-KAM segment team carries a target where platform services are now planned to make up about a third of the number. The team has one shared pre-sales engineer.
- Diagnose. Platform deals in the last two quarters show a pattern: long technical cycles, several losses citing a hyperscaler’s stronger solution design, and two KAMs with almost no platform pipeline at all.
- Choose the model. A third of the target from platform is too large for a single shared engineer, but not yet large enough to justify an architect per KAM. The team moves to KAM plus pooled overlay: two solution architects shared across five KAMs, with cloud and security specialists borrowed from a central team.
- Fix the information flow. Service managers are asked to send monthly usage summaries to each KAM, feeding the account-reading checklist from Module 3 directly.
- Review in two quarters. If platform pipeline per KAM rises and technical losses fall, the structure is working; if pipeline concentrates in the two strongest KAMs, the next step is targeted coaching (Module 15), not more headcount.
What comes next
Module 14 covers forecasting platform revenue, which behaves very differently from connectivity revenue and is one of the main reasons team structure decisions get made on the wrong numbers.
Which coverage model does your team actually run today, and is it the one your target split requires?