How to Audit Your Marketing Technology Stack Before Investing in New Tools

The renewal notice lands in a shared ops inbox nine days before the auto-renew date. It is for a data-enrichment subscription somebody bought two years ago. The ops lead forwards it to the demand-gen manager, who forwards it to the person who ran demand gen before her, who left in the spring. Nobody on the thread can say which fields the tool writes to, whether its API key is still live in the Marketo instance, or who signed the original order form.

The renewal goes through. At that point in the calendar, it always does. Nine days is not a negotiation.

Three weeks later the same team sits in a meeting about buying an intent-data platform, and the business case rests on a capability that the unowned subscription already covers. Nobody connects the two.

Start the inventory from the objects

An audit that begins with the invoice list ends exactly where the invoice list ends, which is at the boundary of whatever finance happens to hold a signed contract for. A line item tells you what the company pays and nothing at all about what the tool does to your data.

Start from the objects instead. Lead, contact, account, opportunity, campaign, activity. For each one, write down every system that writes to it, every system that reads from it, and which single system is authoritative when two of them disagree.

The exercise is boring for about twenty minutes and then it stops being boring. You find that three tools write to the lead object: the form handler, the enrichment vendor, and a Zapier workflow somebody built to push webinar registrants in from a platform the team no longer pays for. You find that the account object has an owner in name only, because the enrichment job rewrites the Industry picklist every night and nobody ever chose that behaviour, it arrived switched on.

Three writers, one object, no owner.

Campaign is the object where this breaks in public, because two teams define it differently and both definitions are defensible. Marketing counts a campaign as a program with a budget line behind it. Sales counts it as whatever touched the opportunity last. Until somebody writes down which Campaign Member status values mean attended, engaged and converted, the campaign-influenced figure in the quarterly deck is an opinion with a decimal point attached to it.

That is the shape of a finding worth writing down. It names an object, a field and a writer, and it gets to the third sentence before it mentions a logo. Teams that repeat the exercise on a cycle end up holding a documented map of the B2B revenue technology stack rather than a vendor list, and the map is what makes the next purchase arguable on evidence instead of on enthusiasm.

Six questions that sort a stack faster than a feature matrix

Feature matrices are built for buying, and they compare what tools claim against each other, which is the wrong axis entirely when the real question is whether something already installed is doing any work at all. Six questions get further, and each one takes roughly ten minutes per tool:

• Which object does it write to, and which named fields?
• Who approved the purchase, and is that person still at the company?
• What stops working tomorrow morning if its API key is revoked tonight?
• Which live report, routing rule or nurture stream depends on its output?
• Who has logged in during the last thirty days, by name?
• When does the contract renew, relative to the next planning cycle?

Question three does the most damage, in a useful way, because asking it about any tool in the stack gets one of exactly two answers back: a precise list of things that would break, or a shrug. The shrug is the finding.

What to record for each tool

The record should fit on one screen per tool, because anything longer and the audit does not get finished, and a finished audit matters more than an exhaustive one.

The decision-owner column is the one people argue about, and the argument is the point of including it. A tool with no named owner is being used badly whatever its login count says, because nobody is accountable for what it writes into the CRM.

Login counts and API logs tell different stories

Adoption gets measured in seats and logins because those numbers are the easiest ones in the building to pull, and what they describe is human attention, which says very little about whether a given tool is load-bearing.

A reverse ETL job running out of Snowflake goes a full quarter without a single human login and is still the thing keeping the lifecycle stage field honest in Salesforce. Switch it off and the lifecycle report drifts within a week, quietly, in a direction nobody catches until a board deck. Meanwhile a conversation-intelligence platform with daily logins across the whole sales team feeds exactly one dashboard that two managers glance at before a Monday call.

Read the two numbers together. Logins tell you who would complain. API call volume and integration error logs tell you what would break. The tools worth cutting score low on both, and there are more of them in a mature stack than the procurement spreadsheet implies.

Shelfware comes in three shapes

The word shelfware suggests a single failure mode, a tool nobody opens. There are three shapes, and they need different responses.

One is the tool bought for a plan that changed, an account-based platform like 6sense or Demandbase picked up for a motion the company then deprioritised two quarters later in a reorganisation nobody saw coming. Nobody did anything wrong, the strategy moved, and the clean answer is to let it lapse at renewal rather than reverse-engineer a use case to justify the spend.

The expensive shape is the tool bought to fix a process problem. A routing product gets purchased because leads keep landing with the wrong reps. Leads keep landing with the wrong reps. Same reps. The territory definitions were never agreed to begin with, so the new tool goes on executing the same unagreed rules, faster now and with much better logging. It works exactly as sold, and the fault was never in the software, which is why a second purchase will not find it either.

The quietest shape is the tool that works perfectly and belongs to one person who has since changed roles. It still runs, and it still writes to fields on the contact object every night. Nobody holds the admin credentials or the context, so the team routes around it, and eventually somebody proposes buying a product to do the job the orphaned one is already doing. No handover, no notes, no reason anybody would know.

Overlap shows up at the field level

Two tools overlap when they write to the same field, not when their marketing pages use the same vocabulary. Vocabulary is free. That distinction is worth real money at renewal time.

Operations Hub and a separate iPaaS both running data sync is genuine overlap worth resolving, while a CRM and a marketing automation platform both holding an email address is simply the design working the way it was meant to. In between sits the case that actually costs something: two enrichment sources writing employee count and industry to the same account record on different schedules, so the value sitting in the field depends on which job ran last night.

The fix there is almost never a purchase. Pick one source per field, write the choice down, and set the other source to read-only on those fields. (The integration user's login history is the fastest way to find out which sources are in play.) Check it before the meeting. I have never seen a team regret making that call. I have watched a few of them burn a quarter arguing about which vendor has better data, when what was really happening was both vendors winning on alternate nights.

Turning the audit into a purchase decision

An audit earns its keep in the fortnight before a buying decision, which means it has to produce something a VP can act on in one sitting rather than a document that gets praised and shelved.

Three outputs do that work. A list of fields with more than one writer, each line carrying a proposed single source and the name of the person who agreed to it. A list of tools with no named owner and a renewal date inside the next two quarters, sorted so the nearest date sits at the top where somebody will actually see it. A one-line statement, per product under consideration, of which of those two lists the purchase would shorten.

If a proposed tool shortens neither list, the business case is thinner than it looked in the deck. Buying anyway is a legitimate choice. It just needs somebody to write down what the purchase is actually for, which is the step that gets skipped when a renewal date is driving the calendar. Where that work stalls for lack of hands, marketing operations services get hired to own the audit itself, and the deliverable worth insisting on is the field-level map first, with the tooling recommendation second.

Start with the renewal calendar. Pull your contract dates for the next two quarters into one list, sort it by date, and count back sixty days from each. Any tool you cannot complete a row for by that date goes on the agenda, and the notice period you stop triggering by accident pays for the afternoon it took.