Three work fronts. One warehouse. Material requests in a WhatsApp group.
That's how many operations still run. When the material isn't picked in time, the crew waits, the warehouse scrambles, and nobody can say afterwards where the request failed — because it was never a record.
A morning every warehouse knows
At 7 AM the crew reaches the work front and material is missing. The request was sent last night, as one message in the group among forty others. The warehouse keeper saw it at 6:30, along with six more requests for 7 AM.
Nobody asked late out of carelessness: there was no timing rule and nowhere to see tomorrow's queue. The result is all the picking squeezed into the start of the morning, while the afternoon before had room to spare.
And because the request lives in a chat, nobody can say how many arrived at the last minute, from whom, or for which hours. The problem repeats without ever becoming a number — and without a number, the talk with the team becomes opinion.
“Make poor planning visible. Reduce chaos without rigidity. Respect the reality of the job site.”
What changes when a request has a deadline and a queue
Without Zelo
-
Requests come by WhatsApp, phone or paper, with no clear usage date and each person writing the material name their own way.
-
There is no cut-off. A request for an hour from now and one for next week come in the same way.
-
The warehouse can't see the coming days' load, and the peak forms at the start of the morning.
-
Nobody measures who asks at the last minute, so the same failure repeats every week.
With Zelo
-
Every request uses catalogue items, with a quantity, a usage date and time and a priority, and gets a company number. When the request comes in over WhatsApp, the AI finds those items in the catalogue.
-
Requests after the cut-off or short of the minimum notice need a justification and are flagged as unplanned, with the reason.
-
The dashboard shows the next 7 days' load and today's and tomorrow's peak hours, so whatever can be picked the day before is.
-
Average lead time and unplanned rate per engineer become data for the conversation with the team.
The planning layer your warehouse was missing
Each capability below replaces a manual step that today depends on someone remembering, calling or chasing.
Timing rules, applied
The daily cut-off and the minimum window apply to every request. Requests outside them aren't blocked: they need a justification, get flagged and show up in the analytics.
Load visible in advance
The 7-day forecast and today's and tomorrow's time slots show where picking will bunch up, so work can be spread out before the queue jams.
History that isn't rewritten
The reason and the rule in force at submission are stored with every request. Changing the settings later doesn't change how older requests were classified.
Status without calls
Pending, scheduled, in progress and completed, with an in-app alert at every change and a record of who has opened the request.
Simple rules, applied to every request.
Zelo doesn't try to guess your operation. You set the cut-off and the minimum window, and the system applies both the same way for everyone.
4:00 PM
Default cut-off, adjustable by your company. After it, a request for the next day is flagged as unplanned.
1–720 h
Range of the minimum lead-time window you set, to match how long picking really takes in your operation.
60 days
Period covered by the lead-time and unplanned-request analytics per engineer on the manager dashboard.
A request can start as a message.
If your company turns it on, engineers link their number once and send the request in a single message. Zelo's AI reads the text, proposes catalogue items, quantities and a date, and the request is created only after they check and confirm it, under the same timing rules as a request placed in the app.
Request a demo