One System or Several? When to Split, When to Combine

The operations team wants the new job tracker to include customer contacts. Sales says customer contacts already live in the CRM. Finance wants invoicing in the job tracker too, because “it’s all the same customers anyway.” Within a fortnight, a simple scheduling tool has become a proposal to run half the company from one place.

Somebody has to decide where the edges are. That decision is one of the most consequential design choices you’ll make, and it usually gets made by accident.

Why boundaries matter

Every system has a boundary: the line between what it owns and what it borrows or ignores. Where you draw that line decides who maintains the data, who can change the design, and how much effort goes into keeping things in step.

Draw the boundary too wide and you get one sprawling tool that every team wants to change, with nobody able to approve anything. Draw it too narrow and you get five little tools that each hold a copy of the customer list, all slightly different. Avoiding Tool Sprawl: How Not to Trade Spreadsheet Purgatory for SaaS Purgatory covers the second problem at company scale. This post is about the decision in front of you: for this process, one system or two?

Three questions that decide it

Most boundary decisions come down to three questions. Ask them in this order.

1. Who owns it?

A system works best when one team is accountable for its design and its data. If two teams with different priorities share a tool, every change becomes a negotiation.

Say your warehouse and your customer service team both work with returns. The warehouse cares about condition, location and restocking. Customer service cares about the customer, the refund and the conversation. If one team clearly owns the returns process end to end, keep it in one place. If each owns a distinct half, there’s a case for two systems with a clean handoff, as described in Handoffs Are Where Processes Break: Designing Clean Transfers Between Teams.

2. How much data do they share?

Look at the records each process needs and see how much overlaps. A rough guide:

The middle row is the most common, and the trickiest. Two processes might both need the customer list, but one tracks deliveries and the other tracks contracts. You don’t need one system for that. You need one place that owns the customer list, and the other systems link to it or receive a copy. Connecting Your Tools: A Plain-English Guide to APIs, Webhooks and Integrations explains how that link works in practice.

3. Does the process flow through, or run alongside?

Some processes are one continuous flow: a request comes in, gets approved, gets fulfilled, gets invoiced. Splitting a single flow across several tools means every record has to jump between systems, and every jump is a chance for something to get lost.

Other processes simply run side by side and occasionally refer to each other. Field scheduling and equipment maintenance both touch vans, but they move at different speeds with different people. Those can comfortably live apart.

Signs you should split

Combining feels tidy, but these are signals that one system is carrying too much:

• Two groups keep requesting conflicting changes to the same fields or states.
• Permissions have become a maze because different teams must not see each other’s data.
• One team’s busy period makes the tool slow or noisy for everyone else.
• Nobody can describe what the system is “for” in one sentence.

That last one is a useful test. “This is where we schedule and track field jobs” is a system. “This is where operations, finance and sales do their stuff” is three systems sharing a login.

Signs you should combine

Equally, these suggest you have split something that belongs together:

• People retype the same information into two tools, often on the same day.
• Reports need data from both systems, so someone exports and merges them every week.
• Records regularly fall into the gap between systems: approved in one, never created in the other.
• Users have to check two places to answer a basic question like “where is this job up to?”

If you’re seeing these, the integration between your systems is doing too much work, or doesn’t exist. Sometimes the fix is a better connection. Sometimes it’s admitting the two tools should be one.

Decide who is the source of truth

Whatever you decide, every piece of shared data needs exactly one home. The customer’s billing address lives in one system, and everyone else reads it from there. The job’s status lives in another.

Write this down. A one-page list of “this data, owned here, edited by this team” saves endless arguments later, and it becomes the reference when someone proposes adding yet another field to yet another tool. Keeping Your Operations Tool and Accounting in Sync applies the same idea to the finance boundary specifically.

Boundaries can move

The right answer today might not be the right answer in two years. A small company might run scheduling and invoicing in one tool quite happily; at three times the size, finance may need its own system with tighter controls.

That’s fine. Make the boundary decision deliberately, record why you made it, and revisit it when ownership or volume changes. Growing Pains: Signs Your First Internal Tool Needs a Rebuild covers how to spot when that time has come.

Where to start this week

1. Pick the process you’re designing and list every record type it needs. Mark which ones another team already owns.
2. For each shared record type, name the single system that will be its source of truth.
3. Write the one-sentence purpose of each system involved. If you can’t, that’s where the boundary is wrong.
4. Check for retyping: ask the team which information they enter in more than one place, and decide whether to connect or combine.