"Just WhatsApp the site engineer" works for a studio's first material request. It stops working somewhere around the fifth concurrent project, when three different site engineers are messaging the same procurement person, half the requests have no record of who approved them, and at least one item gets ordered twice because nobody could see that someone else already requested it that morning.
What actually breaks down first
It's rarely the ordering itself — it's visibility. A material request sent over chat exists in exactly one conversation thread, seen by exactly the people already in it. There's no shared view of "what's been requested but not yet approved," no record of who signed off on a purchase, and no single library of what a studio actually stocks or regularly orders, so every request gets typed out from scratch — item name, spec, quantity — with room for the details to drift slightly each time.
The three things that specifically go wrong
- Duplicate orders — two people request the same material because neither could see the other's request, and both get approved before anyone notices.
- Unauthorized purchases — a request gets acted on before anyone with purchasing authority actually approved it, because "approval" was an implied nod in a chat thread, not a real gate.
- No traceability — weeks later, nobody can say who requested a specific material, when it was approved, or which project it was actually issued to.
What a real workflow needs
The fix mirrors the same pattern that works for budget approvals: a request has to move through distinct states — requested, approved, issued — with a specific person responsible for each transition, not an implied group chat consensus. A site engineer requests a material against a specific project; someone with purchasing authority approves or rejects it; once it's physically issued to the site, that gets marked too. Every request carries who asked, who approved, and when it was actually issued — a real record, not a scrollback search through old messages.
A shared material library matters more than it sounds
The second piece, easy to underestimate, is a shared library of materials the studio actually uses — with consistent names, specs, and units — instead of re-typing "18mm MR grade plywood, 8x4 sheet" slightly differently every time. A shared library means requests are consistent, comparable across projects, and fast to create, since a site engineer picks from a list instead of typing a spec from memory.
What to look for
- 1A real request → approve → issue workflow, with a specific approver, not an implied yes in a chat thread.
- 2A shared material library so requests are consistent and fast to create, not retyped from scratch each time.
- 3Visibility across all requests for a project — not just the ones a given person happened to be copied on.
- 4A record of who requested, approved, and issued each material, kept indefinitely, not lost when a chat gets archived.
- 5Per-project material spend visible alongside the project's actual budget, not tracked in a separate system.
Nirmify's materials module is built around exactly this: a shared library, and a request → approve → issue workflow scoped to each project, with the same role-based approval model used across finance. See it in detail on the features page, or start a 7-day free trial and log a real material request against one of your own projects.