The supplier ingredient request is where product development actually stalls
Ask a product development team where their launches lose time and you will hear about suppliers. Ask a supplier and you will hear about the brand. Both are right, and the thing sitting between them is usually an ingredient or material request that nobody owns.
It starts as an email. A spec sheet comes back as a PDF. Somebody retypes it. A question about an allergen goes out and waits four days. Regulatory wants a document that was attached to a different thread. Two weeks later the request is approved, and nobody can say where the two weeks went.
The request has to be a record
The single change that does the most is making the request an object with a status, not a thread with attachments. A record has a version. It has a current owner. It can be reported on. A thread has none of those things, which is why nobody can answer how many requests are open right now.
Once it is a record, the questions that were unanswerable become a list view. How many requests are waiting on a supplier. How many are waiting on us. Which ones have been sitting more than ten days. Which launches are blocked by which requests. Teams that have never had that view are usually surprised by what it shows, and it is rarely the supplier.
Suppliers should type into the record, not into a form you retype
Every retyping step is a data quality event. Someone transcribes a basis weight, drops a decimal, and the error is now in your spec library with no trace of where it came from.
Giving suppliers a place to enter their own values against your fields removes the transcription entirely and puts the attribution where it belongs. It also changes the conversation when a value is wrong, because the record shows who entered it and when.
The practical objection is that suppliers will not use another portal. Some will not. The answer is to keep the ask small: the fields you actually need to approve, not the full spec template. A request that takes a supplier four minutes gets returned. One that takes forty does not.
Status has to drive the approvals, not the other way around
Approval routing built as a chain of individual assignments breaks the first time someone is on leave. Routing driven by a status field, with approvers resolved from a field on the layout, survives reorganizations and lets a coordinator reassign without an administrator.
Three things are worth building in from the start: the ability to reject with a stated reason, the ability to reassign an approver, and a record of both. The reason field is the one that pays off later, because a rejection without a reason just becomes the same request resubmitted next week.
Capture allergens and contaminants at request time
The temptation is to approve the ingredient first and chase the regulatory detail before launch. It never gets cheaper. Allergen declarations, contaminant limits, country of origin and certification expiry are all easier to collect while the supplier is already in the record than three months later when the product is being commercialized and the buyer has moved on.
Make the fields required to advance the status rather than required to save. That gets you a draft you can collaborate on without letting an incomplete record slip through to approval.
Watch for approvals that fail silently
This one is unglamorous and it costs real weeks. Automated notification and approval processes fail. A validation rule changes, a required field gets added, a user is deactivated, and the automation starts erroring on every run. The error goes to an administrator’s inbox, or to nobody, and the requests just stop moving.
Nobody notices immediately, because a request that is stuck looks exactly like a request that is waiting. We have seen the same automation fail quietly for weeks against a sandbox before anyone connected it to the launches slipping.
Two safeguards are enough. Route automation failures somewhere a human reads daily, and build an aging report on request status so anything sitting past a threshold surfaces on its own. Neither takes long to set up, and together they turn a silent failure into a visible one.
What changes when it works
The measurable outcome is not approvals per week. It is the gap between when a request is raised and when it is approved for commercialization, and whether you can see that number at all. Teams that instrument it usually find the elapsed time is dominated by waiting rather than working, and waiting is the part you can fix without hiring anyone.
We build and repair these flows inside Specright, including supplier-facing request records, approval routing, aging reports and the monitoring that catches automations when they break. The Specright practice page has the detail, and our managed services page covers the ongoing side, which is where most of these failures get caught.
