The redfly Portal: where alerts, suggestions and dashboards land

An AI model that spots a short pick (an order line a picker could not fill because the stock was not where the system said) has done half the work. The other half is getting that finding in front of the supervisor who can walk over, check the shelf and fix the count. If the finding sits in a log file or a spreadsheet nobody opens, the floor carries on as if the model had never looked.

When we integrate AI into the systems you already run, the question is not only what the AI reads, but what it hands back and to whom. Our answer is the redfly Portal: the place where alerts, suggestions and dashboards land for your people to act on.

Output needs an address

An integration, in our language, is one piece of AI woven into the systems you already run. It reads from your warehouse system, either through its API (the published way other software asks it for data) or from a copy of its database. It never takes over the system that runs the floor.

That boundary raises a practical question. Where does the output go, the warnings and ideas that need a human eye before anything changes? Output without a fixed address tends to fail in familiar ways:

• It lands in an inbox and competes with every other email of the day.
• It lands in a report that someone reads the next morning, after the moment has passed.
• It lands nowhere in particular, and people stop trusting that it exists.

The Portal gives every integration the same address. Supervisors, dispatchers and customer service staff know where to look, and each integration has one place to put what it finds.

The Portal holds only the AI's own output. It does not replace your own reports or any portal your team builds; those stay with you.

What lands there

Three kinds of output land in the Portal. They differ in what they ask of the person reading them.

Alerts

An alert says something needs attention. Short pick and stock mismatch alerts in a warehouse, temperature drift warnings in cold storage, late load alerts in trucking and equipment failure warnings at a quarry all share this shape. The alert does not fix the problem. It points a person at it, for that person to review.

Suggestions

A suggestion proposes an action and waits. Stock move suggestions between distribution branches are one example; appointment scheduling around peaks, offered for a person to confirm, is another. The AI does the legwork of preparing the option. The decision still belongs to someone who knows the customer, the crew on shift and the things no system holds.

Dashboards

A dashboard shows the state of things at a glance. Daily site summaries for head office and daily vessel summaries for the office are the kind of output that fits here. Dashboards are less about a single decision and more about keeping people oriented through the day.

These are examples; you pick the first integration, and with it, the shape of its output.

A person stays in charge

The Portal is where the line between the AI and your people is drawn. AI suggests, alerts and prepares; people act. It shapes the output from the first design conversation.

When we design an integration, we decide where the AI runs, what it reads and what it hands back. What it hands back is the part that lands in the Portal, and it is written with the person on the other end in mind. A dispatcher reading a late load alert needs different things from a plant manager reading a quality drift alert, so the output is designed for the role that will act on it.

Keeping a person in charge also protects you while trust is being earned. A new integration can be wrong in ways nobody predicted. When its output is a suggestion a person confirms, a wrong suggestion costs a moment of someone's attention rather than a bad change on the floor.

The AI prepares the decision; a person makes it.

How the output earns its place

Output does not become part of everyday work until it has been through the same path as the rest of the integration. We build it against your systems, then a small group uses it on real work in a pilot. We test it with a set of checks until it holds up on a busy floor, and only then do we roll it out for everyone, under our watchful eye.

The pilot matters most for the Portal. A small group living with the alerts and suggestions on real work shows whether they are useful, too noisy or aimed at the wrong person. Those answers shape the output before everyone else sees it.

What a busy floor does to output

Busy sites change how a system behaves. Peaks, exceptions and shift changes all affect what the AI sees and how much time people have to read. An alert that seems sensible in a quiet demo can turn into noise during a peak, which is why testing happens on a busy floor.

Sites also lose their connection, and distant sites sit on slow links where every request takes a noticeable while to answer. The system has to cope and catch up.

Where redfly fits

You bring how your operation works today; we work out where AI fits, build the integration against the systems you already run, and put its output in the redfly Portal for your people to act on. A person stays in charge of what happens next.