Your martech stack wasn't planned. It happened.

Nobody sat down on day one and designed your marketing technology stack. Nobody drew the architecture, evaluated the options, and made deliberate choices about which platforms to buy, how they'd connect, and what the long-term operating model would look like.

What actually happened was this: someone bought a CRM because sales needed one. Later, someone bought an MAP because marketing needed to send emails at scale. Then someone added an analytics tool because reporting was a mess. Then an enrichment vendor because the data was incomplete. Then an event platform, a social scheduler, a project management tool, a webinar platform, and an ABM tool - each purchased to solve a specific problem at a specific moment by a specific person who may or may not still be at the company.

Each purchase made sense at the time. None of them were made with the full picture in mind. And now the stack has 12 to 20 tools, multiple overlapping capabilities, integrations held together with workarounds, and a total annual cost that would make the CFO uncomfortable if anyone ever added it up in one place.

Your stack wasn't planned. It happened. And the difference between a stack that happened and a stack that was designed is the difference between a marketing operation that runs efficiently and one that spends half its time managing its own complexity.

The question nobody asks until the money gets tight

"What should our martech stack actually look like?" is a question most organizations never ask while things are going well. The tools work well enough. The team knows how to use them well enough. The integrations hold together well enough. Nobody's going to volunteer for the painful exercise of evaluating, consolidating, and potentially ripping out tools that people have built workflows around.

The question gets asked when the budget gets squeezed. When the CFO wants to know why marketing is spending six figures a year on tools. When a new CMO arrives and wants to understand what they've inherited. When a merger or acquisition forces two stacks to become one. When the team tries to do something new and discovers that the existing tools can't support it without yet another purchase.

By that point, the stack has accumulated years of decisions, dependencies, and technical debt. The evaluation isn't just "which tools do we need" - it's an archaeology project to understand what exists, why it exists, who uses it, and what breaks if it's removed.

The teams that ask the question proactively - before the crisis forces it - have a significant advantage. They make decisions from a position of clarity rather than pressure. They consolidate deliberately rather than cutting blindly. And they build a stack that serves the business as it is today, not the business as it was when each tool was originally purchased.

Most stacks have three categories of tool

When you strip away the vendor names and the feature descriptions, most martech stacks sort into three categories. Understanding which tools fall into which category is the starting point for any honest stack evaluation.

Tools the team depends on daily. The MAP, the CRM, the analytics platform - whatever the team logs into every day to do their core work. These tools are operational infrastructure. They're configured deeply, integrated tightly, and removing them would require a migration project. These aren't candidates for cutting - they're candidates for optimizing. The question here isn't "do we need this" but "are we getting full value from it."

For these tools, the evaluation should focus on utilization. What percentage of the platform's capability is the team actually using? Most organizations are paying for enterprise-grade platforms and using them at a fraction of their potential. The scoring engine exists but runs a basic model. The dynamic content capability exists but every email uses static templates. The advanced reporting exists but the team pulls the same three reports every month. Closing the utilization gap on the tools you already depend on is almost always more valuable than buying a new tool to fill a gap that your existing platform could fill if someone configured it properly.

Tools that solve a real problem but could be consolidated. The enrichment vendor that overlaps with what the ABM platform offers. The reporting dashboard that duplicates what the CRM can do natively. The social scheduling tool that the MAP now handles. These tools were purchased because a gap existed - but the gap may have closed since the purchase, either because another tool expanded its capabilities or because the team's needs changed. These are candidates for consolidation.

The evaluation here requires talking to the people who use the tool and the people who manage the platforms it overlaps with. Often, the team using the standalone tool doesn't know the core platform can now do the same thing - because nobody told them when the feature was added. And the person managing the core platform doesn't know the team is paying for a separate tool that duplicates what they already have. The overlap only becomes visible when someone maps the capabilities of every tool against each other, which most organisations have never done.

Before consolidating, test the replacement. Don't cancel the standalone tool and hope the core platform can handle the workload. Run them in parallel for 30 days. If the core platform genuinely covers the use case, cancel the standalone tool. If it doesn't - if the standalone tool does something the core platform can't replicate - keep it and document why. The goal is informed decisions, not blind cutting.

Tools nobody can justify but nobody will cancel. The platform that was bought for a project that ended. The tool a previous team member championed that nobody else uses. The vendor whose renewal goes through automatically because cancelling it requires a conversation nobody wants to have. These are candidates for immediate removal - and most stacks have more of them than anyone expects.

The test is simple: if this tool disappeared tomorrow, would anyone notice within a week? If the answer is no - if the team would continue operating without a gap - the tool is dead weight. The licence fee is waste. The data sitting inside it is an unmanaged liability. Cancel it, export anything useful, and redirect the budget toward something that's actually being used.

Sorting your stack into these three categories takes a day. The decisions that follow can save significant budget and reduce operational complexity in ways the team will feel immediately.

The integration question matters more than the tool question

Most stack evaluations focus on individual tools - do we need this one, is it worth the cost, does it do what we need. That's necessary but insufficient. The more important question is how the tools connect.

A stack with five well-integrated tools will outperform a stack with fifteen poorly integrated ones every time. Integration determines whether data flows cleanly between systems, whether the team has a single version of the truth, and whether automations can work across platforms without manual intervention.

Most integration problems aren't dramatic failures. They're quiet inconsistencies - a field that syncs from the CRM to the MAP but not back. A record that updates in one system and takes 24 hours to reflect in another. A data enrichment tool that writes values into the CRM but doesn't push them to the MAP, so the two systems disagree about the same contact.

Each inconsistency is minor on its own. Accumulated across thousands of records and dozens of workflows, they produce a marketing operation where nobody trusts the data because the answer depends on which system you ask.

How to evaluate your integrations. Pick a single contact record and trace it across every system in your stack. Does the CRM show the same field values as the MAP? Does the enrichment data match what's in both? If the contact has an engagement score in the ABM platform, does it align with the lead score in the MAP? If there's activity data in the event platform, has it synced to the CRM?

Do this for ten records chosen at random. The number of discrepancies you find will tell you how reliable your integrations actually are. If more than two or three of the ten records show inconsistencies, your integration layer needs attention before any other stack decision gets made - because every tool downstream is making decisions based on data that may be different depending on where it's stored.

Then map every integration: what connects to what, which direction the data flows, how frequently it syncs, and whether anyone monitors it for errors. Most teams have never produced this map. Creating it takes half a day and reveals dependencies that nobody realized existed - the enrichment tool that feeds the CRM that feeds the MAP that feeds the ABM platform in a chain where a single break corrupts everything downstream.

Stack planning isn't just about which tools to keep. It's about how the remaining tools connect - and whether those connections are reliable enough to support the automations, reporting, and AI features the team depends on.

The operating model that most stack planning ignores

Choosing the right tools is half the problem. The other half - the half that most stack evaluations skip - is defining who runs them and how.

A tool without an owner is a tool that degrades. Configuration drifts. Integrations break. Features get activated without governance. Data quality declines. The tool works on paper but nobody's responsible for keeping it working in practice.

Stack planning should include an operating model for each tool that stays. That means answering five questions per tool:

Who owns this tool - not who purchased it, who is responsible for its ongoing health? Who maintains the configuration and ensures it stays aligned with current business needs? Who monitors the integrations and gets alerted when something breaks? How often does the tool get reviewed - its configuration, its utilization, its cost-to-value ratio? What's the escalation process when something goes wrong - who gets called, what's the expected response time, and what authority do they have to fix it?

Without these answers documented and agreed, the stack consolidation produces a leaner set of tools that degrades at the same rate the old stack did - just with fewer tools degrading.

The teams that get the most from their martech investment aren't just the ones with the right tools. They're the ones with the right tools, the right integrations, and someone genuinely responsible for keeping the whole thing running.

The cost exercise that changes the conversation

Before any stack planning conversation with leadership, do one thing: add up the total annual cost of every tool in your stack in one spreadsheet. Licence fees, implementation costs still being amortised, integration maintenance, the time your team spends administering each tool, and any external consulting or support fees.

Most organisations have never seen this number in one place. The CRM cost is in the sales budget. The MAP cost is in the marketing budget. The enrichment tool is in a different cost centre. The analytics platform is shared with product. Each tool's cost is manageable when viewed in isolation. The total is almost always larger than anyone expected.

Then add a column: value delivered. For each tool, what specific business outcome does it produce? Not theoretical value - actual, demonstrable contribution to pipeline, revenue, efficiency, or compliance. Some tools will have clear answers. Many won't. The tools with no clear value delivered are the immediate candidates for review.

Present this spreadsheet - the full cost and the value column - to leadership before proposing any changes. Let the numbers start the conversation. A leader who sees £400,000 in annual martech spend with three tools showing no demonstrable value will ask the right questions without being prompted. The data does the persuasion.

Start with the audit, not the wishlist

The instinct when planning a stack is to start with what you want - the ideal tools, the ideal architecture, the ideal capabilities. That's backwards. Start with what you have.

Inventory every tool. Document who uses it, what it does, what it integrates with, what it costs, and when it renews. Then talk to the people who use each tool daily and ask two questions: what would break if we removed this, and what does this tool do that another tool in our stack also does?

The inventory reveals the overlap, the gaps, the orphaned tools, and the integration dependencies. From there, the stack plan builds itself - not from a wishlist, but from the reality of what the team actually needs, uses, and depends on.

Build the plan in phases. Phase one: remove the tools nobody can justify - immediate cost savings, zero operational impact. Phase two: consolidate the overlapping tools - run parallel for 30 days, validate the core platform covers the use case, then cancel the standalone tool. Phase three: optimize the tools that stay - close the utilisation gap, fix the integrations, assign owners, and build the operating model that keeps the stack healthy long-term.

This phased approach is important because trying to do everything at once overwhelms the team and creates risk. Each phase produces a visible result - cost savings, reduced complexity, improved utilization - that builds momentum and leadership confidence for the next phase.

At Sojourn Solutions, stack assessment and rationalization is foundational to how we work with clients. We help organizations understand what they have, what they need, where the overlap and waste sit, and how to build a stack architecture that supports the operation they're running today and the one they're building toward. The assessment produces a clear picture of current cost, current utilization, integration health, and a phased plan for consolidation and optimization. If your stack grew without a plan and you're not sure whether what you're paying for is what you actually need, that's a conversation worth starting.