My Approach to Enterprise Account Management
I wanted to share my thoughts on account management. Two years ago I inherited 147 accounts, the first thing I noticed was that nobody could articulate the why. CSM’s would tell me the utilisation metrics, support had dashboards for ticket responses but there wasn’t a connection between what customers were doing with the product and what that meant to their organisations. This is my approach to tiering, execution, and playing the long game.
The Two Failure Modes
As Enterprise AE’s, the one thing you need to do is be effcicient with your time and inheriting a large set of accounts typically fail in one of two ways First: paralysis. Too many accounts, too many priorities, so nothing meaningful happens. The easiest thing to look productive is to be reactive. Second: treating every account the same. Same cadence, same check-ins, same playbook for a $1.4M enterprise and a $15k SMB. You’re going through the motions without actually managing anything. To break out of both traps, you need to be clear on what your job actually is - and what it isn’t.
AE vs CSM
It’s very easy for AE’s to lean on CSM’s because of the insights they have but you need to know that Customer Success owns the what and the how. They work with customers to use the solution, ensure that tickets are being resolved in a timely manner. I own the why and the when. Why do these outcomes matter to the business? When do you need certain things completed?
I had a meeting with a Queensland based Insurance Organisation (who sold their Banking arm to ANZ). I was talking to them about their concierge function and the metrics they pull monthly. The CSM walked away knowing they’re using the reporting tools correctly - no churn risk. However I walked away uncovering that those metrics are compliance requirements tied to customer experience KPIs. This was my pathway to expansion. Same conversation. Different outcome.
A key skill I need to posses in sales is connecting operational outcomes to executive strategy. A soft skill to compliment is curioisity. Anyone I’m talking to, I always love to ask - what does the person above you need from the work you’re doing? I’ll keep asking this until I understand how individual activity ladders up to strategic priorities and I’m able to articulate it in a way that makes sense to people across their business. Once you can understand the why - it can help drive where you spend your time.
Tiering
In order to maximise time, I inspected each account to tier them into the right places: High Touch, Mid Touch, Low Touch, and Scaled. But the tiers are fluid.
High Touch isn’t necessarily the biggest ARR. It might be an account that’s struggling and needs rescue. It might be one heading into a major tender in 18 months. The common thread: it needs focused attention and has meaningful upside if I get it right.
Mid Touch is about deepening relationships. Understanding what people do, what’s changing, where I can support them.
Low Touch accounts are rock solid. High utilisation, mature processes, don’t need my help.
Scaled accounts are too low value to justify meaningful time. But I keep across their business in case I can pattern-match to a similar High Touch account.
Accounts move between tiers based on momentum and opportunity. When multiple accounts need attention and time is finite, ARR is the tiebreaker.
Executing on tiers
Start with feel, refine with data. My time working for PE backed organisations means that I tend to look for two things: revenue protection first, then expansion probability. Tier based on instinct, validate with engagement and pipeline data. Revenue protection first because that’s what the board cares about - predictable ARR. Expansion second because that’s how i get paid.
Run the pathway with momentum. Prioritise accounts where there’s energy and movement. Those are the ones where you can create outcomes quickly.
When in doubt, pick up the phone. Let the customer tell you where they are.
Delegate to scale, not to offload. Sales is a team sport but you can’t rely on others for large tasks that eat their bandwidth. Delegate things that are quick for them and play to their strengths. I wouldn’t ask a Solutions Architect to demo something for the sake of it. I’d come with a specific outcome in mind - maybe collated documentation on a use case - and give them something they can knock out quickly. If they drop it, I’m across it enough to pick it up myself.
The long game
A WA-based Resources company started as Low Touch. Small user base, not much happening. I tried to sell them an expansion early on but internal politics blocked the budget pathway. Instead of walking away, I did the architectural work anyway. Solution architecture, security requirements, references, use case mapping. All the homework a customer needs to build an internal business case.
They went quiet for a year and it felt like I wasted my time.
However, a year later, they still had the same business problem. The only difference was now they had clarity on what they wanted - and all my documentation sitting there ready to drop into a business case. Because I’d de-risked the technical and security questions, they could move quickly through procurement.
150k AUD ARR expansion completed in 3 months.
The system didn’t make that deal happen. It created the conditions for it to happen when the timing was right.
How to get started
If you want to implement something similar: call your customers. Not to pitch them anything but to understand where they actually are. Let them tell you what tier they belong in.
The most common mistake is trying to systematise too early. People build elaborate frameworks before they understand their accounts. Or they try to do it alone instead of involving CSMs, Solutions, and other functions who can help scale the effort. Territory management isn’t a system you implement once. It’s a way of thinking about how to allocate your time across a book that’s always too big to touch everywhere.