Consolidation pitches are almost always binary. One side says every tool you own is a tax and you should run the business from a single platform. The other says best-of-breed wins and integration is a solved problem. Both are selling. The decision is not made once for the whole stack, it is made per tool, and there is a test that settles most cases quickly.
The test: who owns the record?
Replace a tool when it owns a record that another part of the business needs to read or change in the course of normal work. Keep a tool when it owns a domain nobody else touches.
That distinction is doing all the work, so it is worth being precise. A record is a business fact with an identity and a lifecycle: the customer, the deal, the order, the ticket, the invoice, the stock level. A domain is a technical capability with its own engineering problem: getting email into an inbox, moving money, producing a signature with an evidence trail.
When two systems both hold a record, one of them holds a copy, and a copy can disagree with its source. Every sync job, mapping table and nightly reconciliation exists to manage that disagreement. When a system owns a domain instead, there is no shared record to drift, and the integration is a request and a response rather than a promise about tomorrow.
Applying the test across a typical stack
The verdict, category by category
| Category | Does it own a shared record? | Verdict | Reason |
|---|---|---|---|
| CRM | Yes, the customer and the deal | Replace | Support, finance and fulfilment all need this record |
| Help desk | Yes, the ticket and its requester | Replace | The requester is the same person as the customer, or you are reconciling by email address |
| Inventory | Yes, the stock level | Replace | Promises made in sales must be enforced by the same number fulfilment picks from |
| Invoicing and ledger | Yes, the invoice and the entry | Replace | Every posting is caused by an event in another module |
| Quotes and orders | Yes, the document chain | Replace | A quote that cannot become an order without re-entry is a copy with extra steps |
What to keep, and why
These categories own something that is not a record of your business. Absorbing them buys nothing and costs a specialist.
| Category | Does it own a shared record? | Verdict | Reason |
|---|---|---|---|
| Email delivery | No, it owns deliverability | Keep | Reputation, bounce handling and feedback loops are a full-time engineering problem |
| Card payments and payouts | No, it owns money movement | Keep | Compliance scope and risk modelling you do not want to own |
| Bank data aggregation | No, it owns connectivity | Keep | Thousands of institution-specific connections maintained by someone else |
| E-signature | No, it owns the evidence trail | Keep | The audit trail is the product, and it is relied on legally |
| Product analytics | No, it owns event analysis | Keep | Reads events, owns no operational record |
| Identity provider | No, it owns authentication | Keep | You want one directory in front of everything, not one per app |
| Accounting package your accountant uses | Contested | Keep, and sync | The record is shared, but the constraint is a human who will not move |
The last row is the honest edge case. Sometimes the deciding factor is not architecture but a person whose workflow you do not control, and the right answer is a stated sync cadence rather than an argument.
The failure case: consolidating a domain that was not a record
A thirty-person company moved its entire stack onto one platform, including outbound email. Previously, sales sent from each rep’s own mailbox and marketing sent bulk mail through a dedicated delivery provider on a subdomain with its own warmed reputation. After the move, everything sent from the platform’s shared sending pool.
Open rates fell within a week. Nobody noticed for three, because the platform reported sends and the drop was in delivery, not sending. Reply rates on outbound sequences fell to roughly nothing, and the sales team concluded their messaging had gone stale and rewrote it, which made the numbers worse by introducing a second variable. The actual cause was that a warmed sending domain had been abandoned and replacement volume was arriving from a pool shared with strangers, with no dedicated bounce handling and no feedback-loop processing.
The lesson is not “never consolidate email”. It is that deliverability was a domain, not a record. Nothing was being reconciled, no copy was drifting, and the consolidation removed a specialist capability in exchange for one fewer invoice. That trade is available in every category, and it is a bad trade in the keep column.
Four questions that resolve the ambiguous cases
Does anyone export from this tool and import into another one regularly? A recurring CSV between two tools is a shared record with a human as the sync job. Replace.
Does a support agent have to open this tool to answer a customer question? If yes, the record belongs where the conversation is. Replace.
Would the tool still make sense if it held no customer identities at all? If yes, it is a specialist. Keep.
If this tool disappeared tomorrow, would you need its data or its capability? Needing the data means it owns a record. Needing the capability means it owns a domain.
The cost of consolidation, stated honestly
Consolidation has a price, and a pitch that skips it is incomplete.
Migration is the largest line. Mapping fields, moving history, bringing in opening balances and picking a cutover date is a project with a date, not a weekend. It is paid once, which is the argument for doing it, but it is paid in full.
Depth regressions are normal. A platform module is very rarely as deep as the specialist it replaces. Before committing, list the three things your team does most often in the outgoing tool and check each one against the incoming module specifically.
Retraining costs more than expected. People are fast in the tool they know. A month of slower work across a team is a real number that consolidation business cases usually omit.
Concentration is a genuine dependency. One vendor holding the CRM, the books and the stock is a larger dependency than five vendors holding a fifth each. The mitigation is not avoiding consolidation, it is demanding export tooling, import tooling and published limits before you commit.
Warning signs in a consolidation pitch
A vendor claiming to replace every category on your list is describing their pricing model, not your architecture. Three specific signals are worth acting on.
A platform that will not name what its modules do not do has not been measured against real use. A platform with no export path is asking you to make an irreversible decision. And a platform that describes integrations as a weakness while depending on payment processors and email providers itself is arguing against its own design.
How Oneop draws its own line
Oneop consolidates the record-owning categories and integrates the specialists, and the integrations page shows the division directly. Payments run through Stripe Connect into your own Stripe account. Bank data arrives through Plaid, reading your own bank. Books can sync to QuickBooks where your accountant lives, with inbound changes arriving by webhook and outbound pushes running on demand rather than being described vaguely as two-way. E-signature on quotes goes to DocuSign or Dropbox Sign, which own the evidence trail. Transactional mail leaves through SendGrid or Postmark, and sales outreach sends from each rep’s own Gmail, Microsoft 365 or SMTP mailbox, so the reputation belongs to the sending person rather than a shared pool. Slack and Microsoft Teams receive notifications through a webhook you create in your own workspace.
What Oneop does not integrate, it owns: the contact, the deal, the ticket, the order, the stock level and the ledger entry are rows in the same database, which is the architecture described in the architecture behind CRM, finance and inventory in one platform. The wholesale solution page also publishes what is missing for distributors, including no EDI and no B2B ordering portal, because that is the information you need to scope a migration rather than discover one afterwards.
If you are running this exercise on your own stack, start with the categories where two teams open two tools to answer one question. That overlap is where consolidation pays, and the rest of the list can wait. For the support side of that overlap specifically, we mapped the channel decision in running a two-channel support operation, and the pricing trap that drives a lot of premature consolidation in the hidden cost of per-seat and metered AI pricing.