Once a month I get on a call with the owner of an organization whose contract with us covers several smaller projects, and for a while I didn’t look forward to it. The status of every project lived in a spreadsheet, the hours lived in our time tracker, and the truth usually lived in an email somebody had sent the week before. I’d ask the person doing the work to update the sheet before each call, and something was always out of date anyway. So I’d end up telling a customer, “My sheet says that one’s in progress, but I think I saw an email go out saying it was finished.” Every system we had was working, and I still sounded like I didn’t know what was happening on his account.

That’s a data silo, and almost every small manufacturer I talk to has several.

A data silo is information that lives in one system, one spreadsheet or one person’s head and doesn’t reach the place where somebody needs it, so a person carries it across by hand, or nobody does. In a small manufacturer, the cheapest fix is usually to connect the systems you already own, one gap at a time, starting with the gap that costs the most hours every week.

Search “data silos” and you’ll find definitions written for companies with a data team and a warehouse budget, and most of them end by recommending the author’s own platform. This page is for the founder-led manufacturer running three to eight business systems, with nobody in-house whose job is to connect them. We don’t sell or resell software. If a vendor ever offers us a commission for recommending them, it comes to you as a credit on your invoice. So nothing below ends in a product, and a lot of it ends in “keep what you have.”

What is a data silo in a small manufacturer?

In a small manufacturer, a data silo is any place where work moves from one system to another and a person has to carry it. The enterprise definitions talk about departments guarding their data. In a shop your size, the departments usually get along fine, and the trouble sits between the pieces of software: the CRM, the quoting tool, the accounting package, the project tracker, the time tracker, and the spreadsheet sitting next to all of them.

You can probably find three of these in your own building before lunch:

  • The quote that gets typed twice. It’s written in the quoting tool, then re-keyed into whatever runs the job, then keyed a third time to invoice it.
  • The “won” deal nobody told the shop about. Sales marks it closed in the CRM. Operations finds out when the customer calls to ask where it is.
  • The Monday report. One person exports from two systems, lines them up in a sheet, and sends it around. Nobody else knows how it’s built.
  • The invoice that depends on a memory. A discount agreed on a phone call exists only in the owner’s head until the invoice goes out at the old rate.
  • The status call. Someone updates a tracker by hand before the meeting, and it’s wrong anyway.

Every one has the same shape. The information exists, it’s sitting in software you paid for, and it doesn’t reach the next system unless somebody’s hands are on a keyboard.

Do you have to run an ERP to have data silos?

No, and this is the part the enterprise pages get wrong. A lot of $2M to $20M manufacturers don’t run a true ERP at all. In the last few weeks I’ve talked with two shops that track their work in other ways. One runs projects in Monday.com. He was on NetSuite, found it was more system than he needed, and is moving to QuickBooks. His real problem has nothing to do with which package he picked. Customers and projects live in the CRM, the project work lives in Monday, and the money lives in finance, and he wants to see real margin on each job. Getting there means connecting the three, whatever the finance system ends up being called.

If you do run an ERP, it’s one more place data can get stuck, and the same rules apply. But start from the question “where does a person carry information from one place to another?”, not from the question “which software do we own?” The first question finds the silos. The second one finds a vendor.

What are the three types of data silos?

In a small manufacturer, data silos come in three types: a dead handoff between two systems, a shadow spreadsheet beside a system, and one person who is the connection. Those three make up the middle tier of the nine-constraint map we call Connect, because each one is a place where data should move between systems and a person moves it instead.

  • Dead handoff. Work jumps from one system to the next and a person carries it. Error-prone on its face, and on a busy week it just doesn’t happen.
  • Shadow spreadsheet. You bought the system and your people still do the work in Excel next to it. The spreadsheet is the cheapest answer they’ve found to a question the system can’t answer yet.
  • One person is the system. Someone who has to remember the step, and whose memory is the only thing holding it in place.

There’s a fourth kind hiding underneath, and it’s the one that wrecks integration projects: two systems that are connected and still mean different things by the same word. I’ll come back to it, because it decides the order you fix everything else in.

Why do data silos form when you bought good software?

Data silos form because software gets bought and implemented and never finished: the feature that would answer the question was never switched on, or the question spans two systems nobody connected. Google’s AI Overview for “data silos” lists departmental culture as a cause, meaning teams treating data as their own property. I rarely see that in a small shop. What I see is a team doing the sensible thing with what’s in front of them.

If leads live in the CRM and deal size lives in your invoicing software, any report that ties the two together has to be built by a person out of two exports. Connecting them is the harder project, so people start doing it themselves, and then they keep doing it.

The person keeping that spreadsheet usually knows there’s a better way. What they’re missing is the access to change the system, the knowledge that the feature exists, or a reason to stop when the spreadsheet works well enough to get through Monday. Given what’s in front of them, the spreadsheet is the rational move, and it’s telling you exactly where the implementation stopped.

Dead handoffs: why does one order get typed into three systems?

One order gets typed into three systems because each system was bought to do one job and nobody built the connection between them, so a person became the connection. Every retype is a chance to get it wrong, and on a busy day it’s also a chance for it to not happen at all.

The skipped step is the expensive one, and we had one in our own shop. A new client signs the contract in our CRM, pays the first invoice in QuickBooks and books a kickoff call, and then somebody has to set them up in Harvest for time tracking and in ClickUp for the project. When the Harvest project didn’t exist before kickoff, the team logged that day’s hours to a temporary code, and somebody had to move them later. When the ClickUp tasks and client profile weren’t built, our strategist walked into the kickoff asking questions I’d already answered during the sale. It took anywhere from a couple of days to a couple of weeks for anyone to notice, and the longer it ran, the less of the history we could rebuild. We automated it. Now the signed contract builds the project, its phases and its contacts before the kickoff call, and the strategist reviews it all first.

I’ll put a number on it, with the caveat that it’s my estimate and not a measured figure. For a three-person team, that automation and the reporting around it saves us at least 10 to 15 hours a week. The hours aren’t the most interesting part. Much of that work would never have happened. Checking that no ClickUp tasks are overdue, and knowing every week how many hours we’ve put into each client against the target, are jobs that get skipped when a person has to build the report by hand. Half the weeks, we would have been flying blind.

That’s the real cost of a dead handoff, and it matters more in a shop than in an office. A manufacturer told me this month that he works out what a project made only after it’s finished. There’s no forecast up front and no live view while the job runs. He isn’t careless. The information is spread across systems that don’t talk, and building the view by hand every week isn’t realistic. A killed handoff is usually the first win in an engagement with us because it’s the fastest one to count: somebody gets hours back every week, and you can write the number down.

When two systems share a customer and disagree about what it means

Your CRM, your project tracker and your accounting package each have their own idea of what a customer, a project and an order are, and connecting them before those ideas agree moves bad records faster. Every system has its own nouns. One calls them clients, one calls them organizations, one calls them projects, and even inside one tool there’s more than one way to set them up.

In ClickUp, we don’t make each client a separate organization. We have one organization, and each client is a space inside it. Connect that to a system where the equivalent thing is called a project, and the mapping has to say that a space in ours is a project in theirs. Get it backwards and the connection runs perfectly. Records flow, nothing errors, and every one of them lands in the wrong place.

The words themselves cause more trouble than the software. Take “booked revenue.” I know a company, not a manufacturer, whose salespeople earn commission when a contract is signed. Two months into onboarding, it sometimes becomes clear the customer isn’t a fit and the work stops. The revenue never arrives, and now somebody has to claw back a commission. Was that deal revenue the day it was signed, the day it was booked, the day it was paid, or the day the project was delivered? Four reasonable answers, and the company had been using all four in different places.

Manufacturers have their own versions. A job starts with a fixed scope, halfway through the customer needs more widgets, and the order goes up. Is the deal worth the first signed value or the new one? On a multi-year order with an option year, do you count the option? And on the cost side: do you spread 40 percent overhead across every project because the admin time has to go somewhere, or do you treat it as a fixed cost and leave it out of job margin? Neither answer is wrong. Two systems using different answers is how you get two reports that disagree about one job.

So before we connect anything, we run three checks:

  1. Does it need connecting at all? Sometimes the answer you need already lives in one system, and the fix is making sure the right person knows where to look. That costs nothing to maintain, and every connection you build is one somebody has to maintain.
  2. Can you trust what’s underneath? If the hours aren’t logged honestly, or nobody can say which ones are billable, an automated report gets the wrong number to you faster.
  3. Do the two systems mean the same thing by a record? That’s the nouns problem, and it’s constraint 2 on the map.

I’ll be straight about where our experience sits. The connections we’ve built run between CRMs and the systems that run delivery: project management, time tracking and accounting. We haven’t built a direct CRM-to-ERP integration for a client, and we don’t build jobs inside an ERP. The shape of the problem is the same. A deal closes in one system, the work runs in another, and a person carries it across. If a shop does run an ERP, we can connect to it wherever it exposes an open interface. But if someone offers you both the connection and the ERP build in one breath, ask them which one they’ve actually done.

Why are there still spreadsheets next to the system?

The spreadsheets stay after go-live because the system was installed but never configured to answer the questions the team brings to it every week, so the team answers them in Excel. A shadow spreadsheet is a spreadsheet your team keeps next to a system the company bought, doing a job that system was supposed to do.

At one company I worked with, somebody hand-built a sales report from HubSpot every week. They filtered to the past week’s leads, copied the count at each stage, threw out the obvious spam and adjusted deals that had changed since they were entered. HubSpot could have done all of it. Nobody had ever agreed what a qualified lead was. Without that, nobody could fill in the field honestly, and the only way to get the number was to rebuild it from exports every Monday. And because a different person sometimes pulled it, a borderline lead could be qualified one week and unqualified the next, and the numbers stopped tying week over week.

The risk shows up downstream. That hand-built figure gets screenshotted into the leadership deck, where nobody in the room knows how it was made. Then the week the person who builds it gets busy, the business loses its only way to check anything about sales.

Here’s a ten-minute version of the check you can run without anybody’s help. Pick a recurring meeting where a number gets presented. Ask whoever brings it where it comes from and how long it takes to put together. Listen for “export,” “pull” or “I just drop it into my sheet.” Do that for three or four numbers and you’ll have a count.

What happens when one person is the connection?

When one person is the connection, every step that runs through them happens only when they remember it, and the steps that only help somebody downstream are the first to go in a busy month. The people who end up in that spot are usually your best and busiest. Asking them to be more disciplined almost never holds, for exactly that reason.

I’m one of those people in my own business. I manage most of our client relationships, and I know what each contract says and what I’ve agreed to. Say I’ve had a hard call and agreed to a discount. If that agreement only exists in my head, the invoice goes out on the first at the normal rate, and I’m writing back to explain I wasn’t trying to overcharge anybody. So we connected QuickBooks, where the invoices go out, to ClickUp, where the projects run, and Harvest, where the hours are logged. Before an invoice is cut, the system flags anything that doesn’t add up. If a client logged no hours this month and is about to be billed the regular rate, it asks me whether that’s right.

That’s the fix for this kind of silo. A written procedure depends on the busiest person in the building reading it on their worst day, and that day is when it gets skipped. Making the capture automatic holds up, either where the work happens or as a short confirm-or-correct list at the back end.

Should you connect your accounting software or replace it?

Connect it, unless the numbers show the tool itself is the constraint. I can’t give you a clean sign that a manufacturer has outgrown QuickBooks, because I don’t think one exists. Most of the shops I meet are on QuickBooks and fine. The manufacturer I mentioned earlier is going the other direction, from NetSuite down to QuickBooks, because NetSuite was more than he needed.

Our rule is simple. We won’t tell you to get rid of a system you’re already paying for if we can connect it to what you have. If one turns out to be a real problem, we’ll give you a recommendation, but swapping software is never where we start, and we make nothing from the answer.

The question underneath “should we replace QuickBooks?” is usually “why can’t I see margin on a job?” That’s very often a connection problem between the quote, the job and the ledger. Connect the quote to the system that runs the job, so quoted cost and actual cost land in the same place, and job margin stops being a guess.

What do data silos cost a small manufacturer?

Data silos cost a small manufacturer in three places: the hours somebody spends carrying data between systems, answers that arrive after the decision they were for, and the credibility you lose when the number on your screen is wrong in front of a customer.

The hours are the cost everybody notices, and they’re bigger than they look, because they aren’t only the retyping. Every time somebody opens a report built on a manual step and sees a number that’s empty or looks off, they go back to the source system, or back to the person who was supposed to copy it. Nobody counts that time, and it happens every time anyone opens the report.

The late answers are worse. Ask which jobs made money last quarter and somebody spends a day stitching spreadsheets, and the number arrives after the decision it was for.

The credibility cost is the one that stings. You’re on the phone with a customer, you pull up their account to answer a question, and you can see the answer on your screen is wrong. So you tell them you’ll track it down and get back to them. It’s recoverable, and it’s also the moment the customer learns you don’t know your own numbers.

There’s a fourth cost that’s newer. AI tools read whatever is in your systems, and if those systems disagree, the AI gives you a confident wrong answer faster. Grant Thornton’s 2026 AI Impact Survey found 48 percent of manufacturers are still piloting AI, against 34 percent across all industries. Plenty of shops have tried it. When an AI tool gives you a generic answer, it’s usually because it doesn’t know anything about your business, and nobody is going to type that in by hand.

Who do you hire to connect your systems, and what does it cost?

You hire somebody whose job is connecting the systems you already own and keeping them connected. Most of the people a small manufacturer calls first have a different job. Software resellers sell you the next system. A full-time hire gives you a person who becomes the single point of failure. An hourly consultant is paid for time, so a slow job costs you more. A small team on a flat monthly fee is paid for pace.

Our prices are on the pricing page, because you’d ask. The first paid step is a $1,200 systems audit: we get into the systems and you leave with a 90-day plan saying what’s binding, in what order, and what it takes to fix each one. Implement it yourself, or put us on it and the full $1,200 comes off the build. The 90-day build is $9,000, fixed price and fixed scope on the most pressing bottleneck. Ongoing work runs $4,250 to $8,150 a month, flat, never a percentage of anything, and the tier sets how many fixes run at once. By day 90 the systems and numbers the plan named are connected, they reconcile and the report ships, or we keep working at no additional cost.

On access, we ask for read access first, always, to whatever holds the numbers we’re connecting. Writes are scoped and agreed before we make any.

Which data silo should you close first?

Close the lowest silo on the map that’s holding things up. It’s rarely the one that hurts the most. A fix at the top of the map inherits every problem underneath it, and it inherits them without telling you. Connect two systems that disagree about what an order is, and you’ve automated the argument.

So I’d work in this order:

  1. Count them. Run the ten-minute check on three or four numbers that get presented every week. Most owners are surprised by the count.
  2. Check the definitions first. For each silo, ask whether the systems on both sides mean the same thing by the record. If they don’t, agreeing on the definition comes first, and sometimes that takes a single meeting.
  3. Then close the handoff that costs the most hours. Dead handoffs are the constraint I find binding most often, and they’re the one with the clearest fix.
  4. Run the three checks before you build anything. Does it need connecting, can you trust what’s underneath, and do both systems mean the same thing by a record.

This page covers the Connect tier. For the whole sequence, with capture underneath and decisions on top, read our piece on single source of truth, and for the map itself, read Nine Things Break, and They Break in Order.

If you counted a few of these in your own building while you read, good. That count is the first thing I’d ask you for. Book a 25-minute call: five questions about how your systems work today, nothing to install and nothing to prepare. You’ll leave knowing which constraint I think is binding and what I’d do about it first, and if you’d be better off spending the money somewhere else, I’ll tell you that too.