IMDAD: Turning a Procurement Policy Manual into a Platform
Ask any procurement team where the rules actually live, and they will point at the same thing: the policy manual. A thick binder that defines who may raise a request, who must approve it, what changes above each spending tier, and how goods are allowed through the gate.
IMDAD is what happens when you take that binder seriously. It is an end-to-end procurement platform that digitizes a complete procurement policy manual into a working PR → RFQ → PO → delivery lifecycle — tiered approvals, letters of credit, gate passes, product recalls, and a supplier portal, all driven by a configurable workflow engine with role-based access across 38 personas. And the scope is exactly as wide as it sounds: healthcare procurement, end to end.
Why Procurement Still Runs on Binders
Here is the uncomfortable truth about most procurement software: the manual stays in charge.
The rules live on paper. The system is a form-filler. Enforcement lives in people's heads — the veteran buyer who knows this category needs a different approval path, the finance officer who remembers which payment terms require a letter of credit. Policy exists, but compliance is a matter of memory, and audit becomes archaeology.
The interesting product problem was never building the forms. It was this:
How do you encode policy as software without losing auditability?
The manual answers "who may do what, and when." A real platform has to answer the harder question: "who actually did what — and why was it allowed?"
PR → RFQ → PO → Delivery, One Unbroken Chain
IMDAD runs the whole lifecycle as one connected flow, the way the manual always intended.
Purchase Requisition. The need starts where the work is — the requesting side of the persona list includes clinical roles like nurses and physicians, not just procurement staff. A PR is raised, and the tiered approval ladder the policy defines starts doing its job. No side channels, no "I'll get sign-off later."
Request for Quotation. Once approved, the requisition goes to market. Buyers and sourcing officers run the RFQ, and suppliers respond through their own supplier portal — inside the same system, not over email attachments.
Purchase Order. Award becomes a PO. Where payment terms demand it, letters of credit are part of the flow rather than a parallel paper process.
Delivery. Goods do not simply arrive; they pass through gate passes that control what physically enters. And when something has to leave — a defective batch, a flagged product — product recalls are a first-class flow, not an improvised scramble.
Every step is the policy manual, executed. The chain from "we need this" to "it is on the shelf" never leaves the platform, which means the audit trail writes itself as a by-product of doing the work.
Policy as Configuration, Not Code
The principle underneath IMDAD is the one I keep returning to across products: the rules of the system should be data, not developer interpretation frozen in code.
Chapters of the manual become workflow configuration. Approval tiers are configuration. Routing is configuration. The 38 personas — from nurses and buyers to supply chain leadership and supplier representatives — are the manual's org chart made executable, with role-based access deciding exactly what each of them can see and touch.
A policy that lives in a binder is a suggestion. A policy that lives in the workflow engine is enforced — and because every action passes through a defined gate, taken by a named role, auditability is not a reporting feature bolted on at the end. It is the shape of the system.
I have applied the same conviction elsewhere — in StoryIQ's config-driven approval workflow and in encoding regulatory rules as software for Wathiq. IMDAD is the largest expression of it so far: an entire procurement rulebook, running as a platform.
FAQ
What problem does IMDAD solve?
Most procurement systems leave the policy manual in charge: rules on paper, enforcement in people's heads, audits done by archaeology. IMDAD moves the manual into a configurable workflow engine, so approvals, routing, and access are enforced by the system — and every action leaves a trail tied to a named role.
What does the IMDAD lifecycle cover?
IMDAD runs the full chain: a purchase requisition is raised and climbs the tiered approval ladder, an RFQ goes to suppliers through the supplier portal, award becomes a purchase order — with letters of credit where terms require them — and delivery is controlled through gate passes, with product recalls handled as a built-in flow.
How does IMDAD handle roles and permissions?
IMDAD ships role-based access across 38 personas — spanning clinical requesters, buyers and sourcing officers, finance, supply chain leadership, and supplier representatives — so each user sees only what their role in the policy manual permits.
Where can I see IMDAD?
You'll find IMDAD listed with my other product work, and the platform itself runs at imdad.khalil-am.com. Have a policy manual of your own that deserves the same treatment? Get in touch.
— Khalil