A support desk that can see the site

If your product runs at customer sites, your support desk knows a particular kind of call. A warehouse says something is wrong, and the first part of the call goes on finding out what the system looks like right now. Someone at the site reads values off a screen, someone else asks for an export, and the ticket waits on whoever can reach the building's network.

That gap is not a staffing problem. It is a data problem: the facts your support team needs sit inside a network they cannot reach, behind a link nobody at your company controls.

Why support starts blind

Most vendors with software at remote sites share the same arrangement. Each deployment keeps its own local database, and seeing inside it means being there, or asking someone who is. Remote access tools help, but they open a door into the customer's network, and many customers would rather keep that door shut.

So the desk works from descriptions. The caller says an order is stuck; the desk asks which order, what status it shows, when it last moved. Each answer costs a round trip. If the caller is busy running a shift, the issue sits.

The slowest part of most support calls is learning what the site already knows.

What changes when the data is already central

redfly runs a small service inside each customer site's network, beside your product's database. It watches the tables you choose and sends out rows that are added, changed or deleted. Those changes land in a central store your team owns, current to within a couple of minutes of the site.

For the support desk, that turns the opening of a call around. Before anyone picks up the phone, an agent can open your own support tool, filter to that site, and see the current state of the tables your product keeps there. The conversation starts from what the data shows, not from what the caller remembers.

A few properties make this useful for support rather than merely interesting:

• Every row is stamped with the site it came from and when it arrived, so there is no guessing which deployment a value belongs to.
• Edits and deletes carry through, so the central copy shows what each table looks like now, not a pile of old versions.
• Each site keeps its own space, and all of one customer's sites can be seen from one place.
• Each site reports its health, so a stalled site is noticed, not discovered halfway through a ticket.

What it does not do

It is worth being plain about the limits, because a support team will find them quickly.

The flow is one way. Data leaves the site; nothing is written back, and nothing reaches in. Your desk can look, but it cannot change a setting at the site through redfly. Fixes still go through whatever channel you use today.

It carries database tables only. Files, video, device streams and remote control are outside its scope. The central store also holds current state, not an event history, so if your team needs the sequence of changes over a day, that has to come from tables your product already keeps.

"Within a couple of minutes" means what it says. It is not instant. For most support questions that is close enough; for a problem that changes second by second, the person at the site is still the faster source.

When the link is the problem

Remote sites often sit on slow or unreliable internet, and sometimes the link itself is the reason for the call. When the connection drops, changes queue on disk at the site and are sent once it comes back, resuming table by table from where they stopped. Nothing is lost. Delivery is at-least-once, which means a change may occasionally arrive more than once, but it is never dropped.

That changes what a quiet site means. If one site goes quiet, the health it reports makes that visible, and the desk can check the link before digging into your product. You can also rank tables, so the ones support depends on stay current even while a large backlog trickles in behind them.

Who builds the support view

redfly keeps the data flowing; your team builds what your support agents see. The central store is low-cost document storage, readable with your own tools, so the support view can be a page in an application you already have or a new internal tool. We advise; the screens, filters and alerts are yours.

The site service is designed to stay out of the operation's way. Dynamic throttling preserves the site database's performance under load, and because the desk reads from the central copy, support questions add no load to the database at the site. On SQL Server, changes are picked up through the database's own change tracking, read on a short interval; on MongoDB and PostgreSQL they are streamed.

Rolling it out

Each site needs its own setup, and a person drives the rollout. A practical order is:

1. Pick one site with a support history your team knows well.
2. Choose and rank the tables your agents ask about most.
3. Build a simple support view on the central copy and use it on real tickets.
4. Add sites at your pace once the view earns its place.

redfly fits where your product already runs at customer sites and your support team needs to see them without reaching in. We handle the sync; your team decides what the desk looks at.