For hospitals and medical supply companies

One platform to run and track supply requests between hospital and supplier, through to delivery

Raise the request, get the supplier's confirmation and an expected delivery time, and follow what is past its response window — and how each supplier performs — from one screen.

A demonstration. The stages and their colours are the product's own, not a drawing of them.

Every stage a request goes through, on both screens

  1. Draft
  2. Submitted
  3. Received
  4. Accepted
  5. Preparing
  6. On the way
  7. Delivered

How it works

The side that owns a stage changes it, and the other side sees it in the same moment — no page refresh, and no phone call asking where the order got to.

  1. 1

    The hospital raises the request

    Items, quantities, priority and department in one form. It stays a draft that nobody outside the hospital knows about until it is sent.

  2. 2

    The supplier is told within seconds

    The notification reaches the addressed supplier and nobody else — on screen and on the device — not everyone on the platform.

  3. 3

    Both sides follow it to the receipt

    Accepted, then an expected delivery time, then preparing, then on the way, then delivered — and then the hospital closes it itself, which is the acknowledgement that it arrived.

One request, from raised to received

Eight stages, and each of them has exactly one side allowed to move it. The order below is the one enforced in the database, not a description written next to it.

  1. 1DraftMoved by: Hospital

    The hospital coordinator writes the items, quantities, priority and department. It is a draft, and nobody outside the hospital knows it exists.

  2. 2SubmittedMoved by: Hospital

    The hospital sends it to the addressed supplier and to nobody else, and the response window for that priority starts running.

  3. 3ReceivedMoved by: Supplier

    The system records receipt the moment the supplier opens it — so "did you get it?" is no longer a question anybody answers verbally.

  4. 4AcceptedMoved by: Supplier

    The supplier accepts, and the time taken is fixed against the response window. From here they set the expected delivery time.

  5. 5PreparingMoved by: Supplier

    It is being prepared, and the hospital can see that without asking.

  6. 6On the wayMoved by: Supplier

    It has left. From this stage the hospital can no longer cancel on its own — the goods are on the road.

  7. 7DeliveredMoved by: Supplier

    The supplier records the delivery. This is the supplier's account of it, not the hospital's.

  8. 8ClosedMoved by: Hospital

    The hospital closes the request, acknowledging receipt. This stage alone belongs to the hospital and takes its own permission — it is what separates "we delivered" from "we received".

Why this platform

Live, actually

A change reaches the other side over a channel belonging to that request, not by polling every few seconds. The message, the stage and the notification all land in the same moment.

Arabic first

The interface is Arabic right-to-left throughout, not a translation laid over an English product. English is one click away for whoever needs it.

Each organization's data is its own

Organizations are kept apart by per-role permission controls and logical separation at the database layer rather than in the interface alone, with an audit trail behind every administrative change. The detail is on the security and hosting page.

A record of every administrative change

Who changed it, what it was, what it became, and when. Readable by whoever holds the permission, and exportable.

Where this sits next to the system you already have

This is not a procurement system, not an ERP and not inventory, and it replaces none of them. It runs the stretch between the request being raised and the goods actually arriving — the stretch that is run today on phone calls and messages.

Stays in your existing system

Approval, budget, the purchase order, the invoice, inventory and the accounting entries. We touch none of it and ask for no copy of it.

Runs here

Execution and follow-up: notifying the supplier, their confirmation, the expected delivery time, preparing, dispatch, delivery, and the hospital's acknowledgement of receipt — with both sides talking on the request itself.

The join between them

There is no ready-made integration today and we do not claim one. The platform runs alongside your existing system from day one without touching it, and an integration is a scoped item to be agreed and built when it is needed.

What you get

Requests and their lifecycle

Defined stages and four priorities, with a response window per priority that each organization sets for itself.

A thread with two channels

One channel both sides read, and an internal one the other side never sees — and the difference is written on the message itself, not only coloured.

Attachments

Photos, documents, spreadsheets, video and audio, behind short-lived links that open only for the people on the request.

Delivery and acknowledged receipt

An expected delivery time the supplier sets, a delivery they record, and a close the hospital signs off as received. A rep may share their location on the road if they choose — an optional extra that nothing else rests on.

Reporting and export

Response times against the deadline, per-supplier performance, and daily request volume — exported in a file that opens in Excel with Arabic intact.

Tags and search

A tag is created from use rather than from a settings screen nobody visits, and search reaches requests, tags and thread messages from any screen.

What the platform measures from day one

These are computed inside the platform and can be exported. No customer figures are shown here: the product has not run at a customer long enough for such a number to exist, and a number that does not exist is worse than none.

Response against the window
How many answers landed inside the window set for their priority and how many did not, and how many requests are still open with no answer at all.
Time to answer, time to deliver
Average time from sending to the supplier's answer, and average time from sending to delivery.
Performance per supplier
Aggregated one supplier at a time: sent to them, accepted, fulfilled, and their average answer and delivery times.
Request volume
Requests raised each day by status and priority, counted in your organization's own time zone.

Two doors, one platform

Each side has its own entrance, its own screens and its own permissions.

For hospitals

Raise a request, follow it, and talk to the supplier on it.

  • Raise a request with its items, priority and department
  • Follow every stage live, through to delivery
  • Talk to the supplier inside the request itself

For suppliers

Take requests in, prepare them, and deliver on time.

  • Take in requests from the hospitals you work with
  • Update the stage and the expected delivery time
  • Talk to the hospital inside the request itself