Paperwork, video, audio and sensors: AI beyond the transaction table
Orders and stock are only part of what an operation knows. Emails, bills of lading, dock cameras, radio calls and sensors each suit different AI work, and each has its own meaning of ready.
When people picture the data an AI integration uses, they picture a table: orders, stock, appointments, each a row with tidy columns. That table matters, but it is a fraction of what a warehouse knows. The rest is in a shared mailbox, a drawer of bills of lading, a camera over the dock, a radio channel and a sensor in a cold room.
The large AI models of the last few years changed what counts as data, because they read documents, images, speech and streams of readings about as readily as they read a table. For an operation, this is where much of the re-keying and waiting lives, so it is where some of the most useful integrations begin.
Paperwork and emails
Orders arrive as emails with a PDF attached, as spreadsheets in a format each client invented, and as forms photographed on a phone. Bills of lading, delivery notes, scale tickets and customs paperwork arrive on paper and are keyed in, often twice. Every one of these is information that already exists and that a person retypes.
An integration reads the document, pulls out the fields the warehouse system needs, matches them against what it already knows (the client, the product codes, the expected delivery) and prepares an entry for a person to confirm. It flags what it could not read and what did not match. This is the clearest case of AI removing re-keying from a floor, and it is usually the easiest to start with.
Video from the docks and the aisles
Cameras already watch most docks, yards and some aisles, and almost nobody watches the cameras. An integration can. It notices that a bay has been empty for forty minutes while trucks wait, that a trailer has been at a door past its slot, that a pallet has been left in a fire lane, or that a shelf in a store has been empty since the morning.
Video is good at the questions a person would answer by looking: is something there, has it moved, how long has it been. It is less good at reading a label from across a warehouse or counting items in a dense stack, and a design that respects that produces alerts people trust. Footage of people also comes with rules about privacy and retention that are settled before anything is built.
Audio: radio, phone and the yard
A surprising amount of a shift happens by voice. Drivers call ahead, dispatch talks to the yard by radio, a client phones to change an order. None of it reaches a system unless someone writes it down afterwards, and much of it never is.
Audio integrations transcribe (turn speech into text) and then treat the text like any other document: a phoned-in order change becomes a proposed update for a person to confirm; a radio call reporting a damaged pallet becomes a note against the receipt. Audio is the least mature of the four and the most sensitive, since it involves people's voices, so it is usually a later integration rather than a first one.
Sensors: temperature, equipment and movement
Cold rooms have temperature probes. Forklifts, conveyors, crushers and engines have sensors that report vibration, current draw, hours run and faults. Weighbridges produce tickets. Doors, gates and docks have counters. Most of these readings go to a screen nobody watches, or to a log nobody reads until something has broken.
Sensor integrations look for the pattern before the failure: a cold room drifting upward since the morning rather than a single reading over the limit, a motor whose vibration has crept up over a fortnight, a weighbridge ticket that does not match the order it was meant for. The output is a warning with the evidence beside it, early enough to act on. These integrations often have to run at the site, beside the sensors, so they still work when the internet does not.
What ready means for each
Ready does not mean clean and it does not mean centralised. It means the integration can get at the material, and someone understands it. The practical questions differ by kind.
- Paperwork and email: can the integration read the mailbox or watch the folder, and does someone know which clients send which formats and which fields cannot be trusted?
- Video: can the feed be reached from the site network, is the camera pointed where the question is, and are the privacy and retention rules settled?
- Audio: can the calls or the radio channel be captured, have the people involved agreed, and is there a clear thing to do with the result?
- Sensors: can the readings be collected into one place, at an interval that suits the question, and does someone know which sensors lie?
If the answers for one kind of data and one task are yes, that integration can start, whatever state the rest of the operation is in. If an answer is no, it is usually a small piece of work rather than a programme: a mailbox permission, a network route to a camera, a collector for a sensor.
The table is what the warehouse writes down; the paperwork, cameras, radios and sensors are what it actually knows.
This is the range redfly works across when picking a first integration with a warehouse or distribution company: the transaction table, yes, but also the paperwork, video, audio and sensor readings the operation already produces, each read where it lives and each landing as a suggestion or warning in the redfly Portal for your people to act on.