Can supplier onboarding run without a person in the middle?
The routine part can, and that turns out to be most of it. Onboarding a supplier is a sequence of the same few things every time: send the requirements, collect what comes back, notice what didn’t, ask again, and only then hand it to somebody who has to make a judgement. Four of those five steps are bookkeeping, and bookkeeping is what software is for. The fifth isn’t, and shouldn’t be.
This is a build we did on Monday.com for an event that runs on a cycle, with a fresh set of suppliers to bring through each time. It took two weeks. What follows is how the sequence was modelled, which parts run unattended, and where a person still has to look at something and decide.
Key takeaways
- Supplier onboarding is mostly bookkeeping: send requirements, collect responses, notice what’s missing, chase it. Those steps run without anyone watching them.
- The step that needs a person is the judgement one, where something came back wrong or unusual and somebody has to decide what it means.
- The build tracks the whole multi-step sequence end to end in one place, so the state of every supplier is a thing you look at rather than a thing you reconstruct.
- Follow-ups are automatic, and the dashboard is built to surface what needs action now rather than everything that exists.
- Two weeks to build, and it holds any number of events and any number of vendors.
What does onboarding a supplier actually involve?
The same sequence, run once per supplier, per cycle. They need to be told what’s required of them. They need to send things back: documents, confirmations, details that other people downstream are waiting on. Somebody needs to check that what arrived is what was asked for. And somebody needs to know, at any moment, which suppliers are done and which are three days from being a problem.
None of that is complicated. What makes it heavy is that it repeats, and that it repeats in parallel. One supplier at one step is a two-minute email. Forty suppliers at eleven different steps is a spreadsheet that somebody has to keep truthful, and keeping it truthful is a job in itself. That’s usually the point at which someone starts asking whether this could run on its own.
Which parts of that can run on their own?
The sending, the tracking and the chasing. Monday’s native job is reflecting work: where each thing is, what’s waiting on what, what’s overdue. A supplier moving through onboarding is exactly that shape. Each supplier is an item, the steps are the progression, and the board is the answer to “where is everyone” without anybody having to assemble it.
On top of that sit the follow-ups. When something is due and hasn’t arrived, the reminder goes out without a person deciding to send it, which matters more than it sounds. Chasing is the task people quietly drop when they get busy, and it’s also the task with the sharpest consequence, because a supplier who was never chased is a supplier who shows up unready.
Then the dashboard, which is deliberately not a report of everything. It shows what needs action today. The difference between a dashboard that reflects the whole operation and one that surfaces only the things blocking progress is the difference between something people check and something people close.
Where does a person still have to decide?
At every point where the answer isn’t yes or no. A document arrives but it’s the wrong version. A supplier asks for an exception. Something comes back that technically satisfies the requirement and obviously doesn’t satisfy the intent. Automation is good at noticing that a thing is missing and bad at judging whether the thing that arrived is good enough, and pretending otherwise is how automated processes acquire a reputation for being confidently wrong.
So the build doesn’t try. Those cases surface on the dashboard as things needing attention, and a person handles them. What changed isn’t that the human left the process. It’s what the human is looking at: the exceptions, rather than the whole list with the exceptions hidden somewhere inside it.
How long did the build take, and what does it hold?
Two weeks, start to working system. That’s a real number and it’s the only number on this page, because the rest were never measured. No before-and-after on hours, no percentage on anything. If that measurement ever gets made it belongs here, and until then a made-up figure would be worth less than the two weeks.
On capacity: it was built to hold any number of events and any number of vendors, rather than sized to a particular cycle. That’s a design decision with a cost, and it’s worth being plain about why it was taken. A build fitted to this year’s event is faster to make and needs redoing when the event changes shape. A build that treats the event as one of many costs slightly more attention up front and then stops being a project.
When is chasing people cheaper than building this?
When the volume is low and stays low. Six suppliers, once a year, handled by the same person who’s done it for five years and enjoys it — there’s nothing here worth buying. The honest threshold isn’t the number of suppliers, it’s whether anybody is currently reconstructing the state of things from memory or from a spreadsheet they no longer trust. If nobody is, the spreadsheet is fine.
It’s also the wrong build when the process genuinely changes every cycle. Automation pays off on repetition, and a sequence that gets redesigned each time gives it nothing to repeat. What you’d be automating is last year’s process, which is the one you’ve already decided not to run again.
Frequently asked questions
Why is the client not named?
How much time did it save?
Could this have been built in Jira instead?
Does it work for more than one event at a time?
If your version of this is currently a spreadsheet somebody keeps truthful by hand, that’s the problem worth describing to us. Monday.com work is where most of these land, and hello@viter.io is the way in.