Grow your Key Accounts

The account looks smaller than it is. Each site is a separate record, each rep sees their own, and nobody sees the total relationship. The practical consequences are pricing inconsistency between sites of the same customer, a renewal negotiated without knowing what the group spends overall, and two reps calling the same parent company in the same week with different proposals.

A parent-child field records one relationship. A hierarchy supports several levels and lets information roll up through them, which is what a group with divisions, regions and individual plants actually needs. The test is whether you can ask "what is our total revenue with this customer including everything beneath it" and get an answer without exporting to a spreadsheet.

Whatever was never recorded leaves with them, which in most businesses is the relationship map: who actually decides, who blocks, what went wrong in 2023. Activity history alone does not carry it. This is the argument for capturing contact roles and relationships as structured data rather than as notes, because the successor can read the structure but will never read four years of call notes.

Both cases break the simple hierarchy. Selling to a customer who also competes with you in another segment needs visibility controls rather than a different structure. Selling through a distributor to an end user needs the end user visible as an account in their own right, linked to the distributor, or you lose sight of actual demand. Deciding this before the data is loaded is much cheaper than retrofitting it.

It is comparing what a customer buys from you against what they could buy, and treating the gap as a target. For a manufacturer or distributor that usually means product categories bought at one site and not another, which is the most actionable form because you already have a reference sale inside the same customer. It only works if the product data is categorised consistently, which is more often the blocker than the analysis itself.

Keep the plan inside the system where the work happens rather than in a slide deck. An account plan that lives in a separate file gets updated before the quarterly review and ignored the rest of the time. What is worth capturing is short: who decides, what they buy today, what they could buy, what is blocking it and what happens next. Anything longer tends to be written for internal review rather than for selling.

An ERP records transactions against a customer and does that well. Account hierarchies, relationship mapping, white space and forward-looking plans are not transactions, and there is nothing in the ERP for them to attach to. This is one of the clearest cases where the ERP's own customer record is insufficient, not because it is badly built but because it was designed to answer a different question.

Share of the customer's spend in categories where you compete, the number of distinct sites or divisions buying, and the spread of contacts engaged beyond the original buyer. Revenue alone hides decline: an account can hold revenue flat while quietly narrowing to one product and one contact, which is the shape that precedes a loss.

Someone specific, or it decays within a year. Customers merge sites, get acquired and rename divisions constantly, and none of that arrives as a notification. The workable pattern is that the account owner is responsible for the structure of their own accounts, with a periodic review of the largest ones. Leaving it to whoever notices means the hierarchy is right for the accounts nobody cares about and wrong for the ones that matter.

Usually how you sell to them, because the legal structure is often irrelevant to the buying process. A group may have twelve legal entities but three purchasing decisions. Modelling all twelve creates a hierarchy nobody maintains. The exception is where contracts, credit or invoicing follow the legal entities, in which case both structures matter and the CRM has to reflect the commercial one while staying reconcilable to the financial one.