How to build a CDW org chart your reps actually use

Ask three people on your channel team for the current CDW org chart and you will get three files: one from the last QBR, one a CAM keeps privately because the shared one is wrong, and one from an enablement deck two reorgs ago. Nobody trusts any of them, so everyone keeps their own — which is exactly how you end up with five versions and zero sources of truth.

The fix isn't heroic data collection. It's deciding what the chart is for, structuring it so churn doesn't destroy it, and putting a refresh cadence on the calendar. Here's the version of that we'd build with nothing but a spreadsheet.

Decide what the chart is for before you add a column

An org chart that tries to be a full directory dies of its own weight. In practice a vendor team needs it to answer two questions, fast:

1. Who covers this account? Which AE at the VAR owns the relationship with a given end customer, and which SE supports them.
2. Who is the chain above them? If the AE goes quiet, who is the sales manager? If you need executive air cover for a big play, who is the RVP or segment director?

Everything you track should serve one of those two questions. If a field doesn't help a rep find the right person or escalate past a stalled one, it's decoration, and decoration is what makes charts too painful to maintain.

What to track

For each person, the fields that earn their keep:

• Name and role — and keep role to a controlled set of values (AE, SE, sales manager, RVP, specialist), not free text. The moment "Account Executive," "AE," and "acct exec" coexist, your filters lie.
• Segment and region — CDW, SHI, and the other nationals organize coverage by segment (enterprise, mid-market, SLED, federal) and geography. This is how you'll actually look people up, so it has to be structured, not buried in a notes column.
• Manager — who they report to. This is the field that turns a contact list into a chart.
• Email — the corporate one, because a bounce is your earliest churn signal.
• Verified date and source — when you last confirmed this row and how (call, email thread, LinkedIn, VAR-provided roster). A row without a date isn't data; it's a rumor with formatting.

What to skip: direct-dial numbers that rot faster than you'll refresh them, tenure guesses, and personality notes. Those belong in a CAM's head or CRM activity, not the shared chart.

Structure: two tabs, not one

The single-tab chart — people and their accounts fused into one grid — is the most common design and the first thing to break. People and coverage change at different speeds: a rep might hold their seat for two years while their account list is reshuffled twice in one. Fusing them means every coverage change edits a person row, and every person change orphans coverage.

Keep two tabs instead:

• People — one row per person, with the fields above, including the manager reference.
• Coverage — one row per account-to-person assignment: account name, the person covering it, and the date you confirmed it.

When an AE leaves, you update one People row and re-point their Coverage rows. When accounts move between reps in a realignment, People doesn't change at all. Each tab stays small enough to actually audit.

One honest caveat: a manager column is the least-bad way to model a hierarchy in a spreadsheet, not a good one. Walking three levels up a chain via lookups is fragile, and it breaks in more interesting ways once the same person shows up at two VARs. We wrote up where the spreadsheet model fails structurally — worth reading before your chart gets big enough to hit those walls.

The refresh cadence that keeps it alive

Org data doesn't rot on a schedule, but your maintenance has to run on one or it won't run at all.

Monthly, thirty minutes. Scan for bounced emails from the last month — every bounce is a departed or moved rep. Check LinkedIn for your twenty most important contacts at each major VAR. Ask your CAMs one question in the team channel: "any moves you've heard about?" Update verified dates on anything you touch.

Quarterly, before QBR prep. Walk the chain above every account that matters this quarter: is the AE still the AE, is the manager still the manager. Doing this before the QBR turns the meeting itself into a verification pass — the VAR's own people will correct your chart for free if you show it to them.

Event-driven, immediately. A VAR announcing a reorg, your champion changing roles, an intro email bouncing — each one triggers a spot check of that branch, not a full rebuild.

And give the chart exactly one owner. Shared ownership of reference data means no ownership; the owner doesn't have to make every edit, but they're the one who notices when the verified dates go stale.

When the VAR reorgs — and it will

Reorgs at large VARs are a fact of life: segments get redrawn, mid-market moves under a new director, a region splits. Two rules for surviving one:

Don't edit history away. Before you remap anything, duplicate the current People and Coverage tabs and date them. "Who covered this account before the reorg" is a question you will be asked — usually mid-deal, when a handoff went badly.

Remap coverage before people. The urgent question after a reorg isn't the new reporting chain; it's which of your accounts just changed hands. Go through Coverage first, confirm or reassign each row, then rebuild the chains above the new owners.

What to do Monday morning

Open whatever chart you have today. Add a verified-date column and a source column, and accept that most rows start blank — the blanks are the honest picture of what you actually know. Split people from coverage if they're fused. Put a thirty-minute monthly refresh on the calendar with one named owner. Then take the chart to your next VAR call and ask the rep to correct it: it's a genuinely useful conversation, and it's the cheapest verification you'll ever get.

That system fits in a spreadsheet, and for one VAR it holds up reasonably well. Where it strains is scale: several VARs, reps who show up at more than one, and a coverage tab too big to audit by eye. That's the point where we'd suggest looking at VAR Conduit — it stores the org chart as an actual tree, keeps people and coverage separate the way this post describes, and records every change so the history survives the reorg. If you're curious, tell us what your channel looks like.