A crew arrives at the gate, ready to start work. The vendor had been told they were onboarded. They are turned away, because the system says otherwise.
Then the argument starts. The person who requested the vendor says the request was sent. The vendor management team says it never arrived. Both are telling the truth, and neither can prove it.
This happened at an operations company we worked with, and it came from how they handled a routine task: onboarding a new vendor.
How it worked before
Someone who wanted to use a new vendor sent an email to a shared mailbox, or, more often, to one person on the team. When that person was on vacation, the request waited.
The request itself was usually incomplete: a company name but no contact, a contact name but no phone number, and rarely a description of the work. That was the start of what the team called the hunt, a round of emails and calls to find what the request should have contained.
Once there was enough to go on, someone asked the requestor's supervisor to approve it, by email. After approval, the same person entered the vendor into a spreadsheet and sent the vendor a packet asking for a contract, a tax form and, if needed, a payment form. Those came back in pieces, on different days, and nobody could say at a glance which had arrived.
When everything was in, someone emailed accounting to set up the vendor. Sometimes that email was forgotten. Sometimes accounting finished and forgot to say so. The last step was telling the requestor the vendor was cleared, which happened when someone remembered.
Nothing in that process is unusual, and no one was careless. Email is simply a poor place to keep the state of a process. It records what was said, not what is done, and it depends on every person remembering every step.
What replaced it
We built a single onboarding workflow in the company's own portal. The sequence is the same as before. What changed is that each step has an owner, a record and a next step.
The requestor fills in one form. It will not submit without the supervisor, the company name and a way to reach the vendor, so the hunt is gone. The requestor gets an acknowledgement, and the supervisor gets an email with the vendor's details and two buttons, approve or reject. A rejection asks for a reason and closes the request, and the requestor is told why.
After approval, the request moves step by step: management review, the document packet, the contract, the tax form, the payment form, vendor setup, and accounting setup. Each step has a named owner, who is emailed when it is theirs and reminded daily until it is done. If the owner is out, an administrator can complete the step. If a step was done wrong, an administrator can roll it back, and the owner is notified again.
During vendor setup, the system checks whether a vendor with the same tax ID already exists. If one does, the person chooses between linking to the existing vendor and creating a new one. That check prevents duplicates, and it means a returning vendor can be reactivated without repeating the whole process.
When the last step closes, the requestor and the supervisor are told that the vendor is ready to use.
What the team noticed
We do not have before-and-after numbers to share, and we would rather not invent any. What the people using it told us is more specific than a statistic.
The vendor management team can now see where every vendor stands, go back in time to see what happened and when, and answer a requestor's question with dates, not guesses. They no longer send status emails, because the system does. Accounting no longer chases anyone: everything it needs is in the request itself.
What to do before building anything
The software was the smaller part of the work. Most of the value came from questions that any team can answer without it.
Write down the process. Ask the people who do the work for the concrete steps, in order, from the first request to the vendor being cleared. If the team cannot agree on them, that is the finding.
Give every step an owner. A named person, with a named backup. Most stalled requests we see are steps that belong to everyone, which means no one.
Keep one source of truth. Every request, its status and its documents belong in one structured place, not in an inbox, a spreadsheet and a shared folder. A standard place for documents saves more time than it sounds.
Let the right people see it. Requestors, supervisors, vendor management and accounting should all be able to see the status and the documents, and only those people. Sharing is what ends the argument about who dropped the ball.
If you can do those four things in a spreadsheet and a shared folder, do. If you find the process keeps falling back to email, that is the point where a purpose-built workflow starts to pay for itself.
A question to ask your own team
If an auditor asked you tomorrow how a specific vendor was approved, by whom and when, how long would it take to find out?
If the answer is "we would have to look through some emails," that is worth a conversation.