One product, many sites per customer

When a vendor first plans a central application, the picture in mind is often one customer with one site. That picture is tidy, and it is rarely what the contracts look like a year later. The customer who started with one warehouse now runs your product in four, and wants to see all of them at once.

Why one customer usually means several sites

Customers who buy software for warehouses, depots or plants tend to operate more than one of them. A distribution business grows by opening another building, not by making the first one endlessly bigger. If your product works well in one place, the natural next step for the customer is to put it in the next place too.

That growth is good news for your business, but it changes the questions your customer asks. At one site, the question is how that site is doing. At four sites, the questions become comparisons and totals:

• Which building is falling behind on its daily work?
• How much stock does the customer hold across every location?
• Is a problem at one site also showing up at the others?

None of those questions can be answered from inside a single site. They need the data from every site in one place, with each site still clearly identified.

The problem with treating each site as its own island

The common first attempt is to collect each site on its own terms. One site gets a nightly export, another gets a script someone wrote during an urgent week, and a third gets a cloud database of its own. Each one works, more or less, until the customer asks for a single view.

At that point the costs show up. Every site has a slightly different collection job, so every failure has a slightly different cause. A cloud database for each site is a monthly bill that keeps growing with the number of sites, for what is often a modest set of reports. And when an export fails quietly, the first sign is usually a customer asking why the numbers do not match.

A view that is a day behind is a view nobody trusts.

The deeper issue is that nothing ties the sites together, so combining them is done by hand each time.

One central store, one space per site

Our approach is simpler. A small service runs inside the network at each site, beside the site database, and sends changes outward only. Nothing reaches back into the site. Every site sends its data to the same central store, which is low-cost document storage rather than a separate cloud database for each location.

Inside that store, each site keeps its own space, and every row is stamped with the site it came from and the time it arrived. Data from one building does not mix with data from another, because each lands in its own place. Edits and deletes at a site carry through, so the central copy shows what each table looks like now, not a growing log.

What the site stamp gives you

The stamp on every row is what makes the store useful for a vendor with many sites per customer. It means your application can do two things with the same data:

1. Look at one site alone, for example when your support desk is helping a single building with a problem.
2. Group a customer's sites together, for totals and comparisons across every location they run.

Because the separation is built into how the data arrives, you do not have to rebuild it in every report. Your team decides how to group sites by customer, region or anything else that matters to your product.

Adding them up for the customer

With every site in one store, the central application you build reads from one place instead of from each site. Your dashboards, support tools and analytics point at the central copy. The site databases carry no reporting load. That leaves headroom on the onsite servers, so they stay resilient during busy periods.

The central copy is current to within a couple of minutes. The point is not speed. It is that a customer looking across all their sites sees roughly the same moment at each one, not one site from last night and another from this morning.

We keep the data flowing, and your team builds the application your customers see. The reports, dashboards and any customer portal are yours to design, with our support.

What it takes to add the next site

A second or third site for the same customer is not a switch someone flips. Each site needs its own setup: a machine inside the site network with access to the database and outbound internet, a chosen and ranked list of tables, and one technical contact for the install. A person drives the rollout.

What the second site does not need is a new design. The same service, the same central store and the same site stamp apply. Each site gets its own encryption key, its changes queue on site if the link drops, and delivery is at-least-once, so nothing is lost while the link is down. For SQL Server sites, changes are found through change tracking (a built-in feature that notes which rows changed), read on a short interval; MongoDB and PostgreSQL sites work too.

Where redfly fits

redfly is the site service and central store described here, built for vendors whose product runs at many customer sites, often several per customer, over links they do not control.