Scale Without the Swivel Chair: The Case Against One Platform to Rule Them All

The dream of one platform to rule them all is dead. I’m glad.

For years, companies tortured themselves trying to force a single system to handle every business need. They stretched their ERP to do marketing automation. They asked their CRM to manage complex billing. They pushed their accounting system to power a customer portal. The result was always the same: mediocre execution across the board, and teams working around limitations instead of working.

That era is over. Best-of-breed won. But I want to be careful about what actually won, because most of the companies celebrating that victory haven’t earned it yet.

My firm’s motto is “scale without the swivel chair.” A swivel chair is exactly what it sounds like. A person sits between two screens, reads a number off one, and types it into the other, because the two systems don’t talk. Retyping customer data from the CRM into the ERP. Creating an invoice by hand because the billing platform can’t reach the general ledger. Copying subscription details across three platforms just to process one renewal. The chair is the tell. Where you find one, you have an architecture problem wearing a headset.

What killed “one platform to rule them all”

Two things changed.

The first is that integrations stopped being scary. Native connectors and iPaaS platforms — middleware that moves data between systems on a schedule or a trigger, without anyone writing custom code — got good enough that connecting specialized systems is no longer the risky part of a project. Around 2020, I watched companies stop hunting for the mythical all-in-one solution and start assembling an ecosystem instead: a billing platform built for complex subscription models, an ERP optimized for financial operations, a CRM that is genuinely a CRM. Each system excels at what it does. None pretends to be everything to everyone.

The second is that the scope of an ERP project moved outward. Ten years ago, implementations were about the general ledger, AP and AR, and inventory. Today, customer portals, ecommerce, and automated customer communications matter as much as your chart of accounts. Your customer does not care that your close is streamlined if they can’t check an order status online. No single vendor is best at your revenue recognition and best at your customer experience, and it is no longer embarrassing to admit that.

So the architecture answer changed. Pick the best tool for each job, then connect them intelligently.

That is the part everyone quotes. It is also the part that is half a sentence.

The condition on the win

Running multiple systems is often the smartest decision you can make — if you have the discipline to connect them properly.

Without that discipline, best-of-breed is worse than the monolith it replaced. At least the all-in-one platform was bad at things in one place. A stack assembled without a data rule is bad at things in five places, and every seam between them is staffed by a person.

Here is how it happens, and it never looks reckless in the moment. A company buys a tool to solve the pain of the moment. The pain is real, the tool is good, the purchase is defensible. But the decision is scoped to the pain, not to the flow. Nobody asks what the new system now owns, what it must publish, and who downstream will need it. So the tool solves one problem and creates one handoff. Do that four times in three years and you have a modern stack, a healthy software budget, and more rekeying than you started with.

I’ve seen it too many times to call it bad luck. It’s a missing rule.

Why one-way integrations are a red flag

Two requests make me slow a project down. One is a custom build where a pre-built connector or an iPaaS solution would do the job — usually asked for because custom is what someone learned to do fifteen years ago, and finance folks in particular can get stuck in the past. Custom builds are less flexible and cost more over their life.

The other is a one-way integration.

One-way is fine while only one system owns the data. Orders push from the CRM into the ERP, and that’s the whole relationship. But most companies are well past that point. Both systems are actively sharing responsibility for the same customer, and the moment that’s true, one-way starves the front of the house. Sales can’t see invoice status, AR balances, or inventory levels — exactly the things that should inform a customer conversation or a decision on a new deal.

So what does the sales team do? They email finance. Finance answers by hand. Or someone provisions a read-only ERP login for a rep who needs one number a week. Or — the worst outcome, and the most common — the rep starts keeping their own spreadsheet of who has paid.

You automated the typing on one side and left the swivel chair sitting on the other. In focusing on the pain point of the moment, companies miss that a two-way integration is what unlocks the visibility that made the purchase worth making.

My working rule: any field that two teams make decisions on has to be visible to both of them, in the system where they already work.

What “enter it once” actually requires

This is the unglamorous half, and it’s the half that determines the outcome.

Map the master data before you move a single transaction. Master data is the set of records that persist and that transactions point at: customers, vendors, items, employees, subsidiaries, the chart of accounts. A client’s internal team once spent months building an integration between their operational system and their ERP. On go-live, everything failed. They were sending vendor bills before the vendors existed downstream, so the ERP rejected every transaction — it had nothing to match the vendor reference against. Months of work, dead on arrival, because the steps were in the wrong order.

Before you move any transaction, answer four questions. What master data does this transaction reference? Does that master data already exist downstream? If it fails, can we safely retry without creating duplicates? Which fields have to be populated, and what source data drives them — including your segmentation? Then sequence it: sync the vendors, run the approvals, sync the bills with all the required fields and GL segments, and set up monitors and alerts to catch it when things drift out of sync. Document the dependencies before you build, or you’ll debug them in production while bills are bouncing.

Reconcile the values, not just the field names. Mapping between systems is rarely one-to-one. The CRM has one set of picklist values; the ERP expects something different. Reconcile that upfront or you get orders that won’t sync and reports that don’t tie.

Deduplicate first. The same customer exists twice under slightly different names, the integration runs, and now two invoices go to one client. They call, furious, asking why they’re being billed twice. Finance scrambles, and your credibility takes the hit. Get the data right or nothing else matters.

Capture the field where it originates, even when that team grumbles. The most common violation of enter-once isn’t a technical failure at all. It’s letting the originating team skip a field because it isn’t their problem yet. Ask sales to capture a few extra attributes at quote so billing, collections, and commissions can automate downstream, and you will hear about “more data entry.” Then invoicing becomes automatic, finance closes faster, and sales gets paid sooner. The field costs one person eight seconds at the source. Skipped, it costs someone else an afternoon at the swivel chair.

Give the discipline an owner. No vendor sells a single source of truth. It is not a feature; it’s a rule that somebody enforces. That’s what a governance council is for — representation from IT, Finance, and Operations reviewing changes to fields, workflows, and integrations, because those are the people who can say “that will break the integration we just built” or “that’s going to wreck month-end close.” Your operating system is like the electrical system in your office. You wouldn’t let just anyone open a wall and start cutting wires.

The violations nobody notices

The dramatic failures are easy to spot. These are the ones that pass for diligence:

• Top-side entries. Adjustments made in a spreadsheet to make the reported numbers work. It starts with one. No shame — we get it. Then a few more. Before long there’s a shadow version of your books living in Excel. And then it breaks: the system no longer matches what’s reported, audits get messy, and one spreadsheet error puts wrong financials in front of the board.
• Consolidation outside the system. A multi-entity company owns a perfectly capable ERP and still runs consolidated financials out of an Excel workbook — then books manual journal entries in the ERP to make it agree. That’s usually an intercompany setup problem, and it is fixable.
• The unintegrated payment processor. Swivel chair to a third-party tool to process payments. The ERP never reflects the latest payment activity, so month-end becomes manual matching and an argument about which invoices are actually paid.
• The offline contract. Billing terms in PDFs, collection notes in a spreadsheet, amendments buried in email chains, revenue schedules rebuilt by hand every month. Duct tape, applied by competent people.
• Duplicate entry across departments. A CFO once asked me to help him add AI for efficiency, so I asked to see the current process. Three departments were entering the same data in different formats, nobody had documented who was responsible for what, and reconciliation was happening in someone’s personal spreadsheet. Do you think AI was going to fix that? No. It amplifies whatever you feed it.

None of these show up as an integration failure. They show up as a hardworking team. That’s exactly why they survive for years.

What it looks like when the rule holds

A services company of roughly 250 people allocated labor costs by hand for five years — about 30,000 rows of time entries every month, mapped to labor rates across multiple entities, all in spreadsheets. It worked, sort of. It was also error-prone and couldn’t keep pace with growth. We integrated their time-entry system with their ERP so hours ingest automatically and the ERP produces the journal entries. Their close went from six days to five.

The day count is the headline. The part I care about is quieter: the hours were entered once, by the person who worked them, and every system downstream got them from there.

Pick the best tool for each job. Insist the connection runs both ways. Enter the data once, and let it flow downstream.

If someone on your team is still swiveling, you didn’t buy an ecosystem. You bought a collection.