VMS

Why do timesheets cause more disputes than rates?

Rates are agreed once and written down. Time is submitted every week by a person, approved by a manager who has other work, and translated into an invoice by rules covering overtime, shift differentials, public holidays, and expenses that nobody reads until they are wrong. A missing approval stops an invoice regardless of whether the work happened, which is why suppliers chase approvals rather than payments. Agreeing at assignment start exactly how each of those categories is treated removes most of the argument before it starts.

Who should own the system relationship inside a supplier?

One named person, not each recruiter individually. Panels have their own conventions for how requests are worded, how quickly they close, and what the programme expects in a submission, and that knowledge does not spread by itself. A single owner who maintains the account, watches for rate and term changes, and briefs the desk keeps the supplier from learning each rule by breaching it.

Is a VMS useful for permanent hiring?

Occasionally, where an employer wants agency submissions for permanent roles routed and tracked centrally rather than arriving by email. But the parts of the system that create most of its value, assignments, time capture, and invoicing against approved hours, have no equivalent in a permanent hire, and the parts a permanent process needs, such as structured interview records and scorecards, sit in the applicant tracking system. Most organisations keep the two separate and connect them only where reporting requires it.

What objects does a VMS actually hold?

Underneath the screens there is a chain of linked records, and understanding the chain explains most of the behaviour suppliers find puzzling. A request describes work someone wants covered. A submission attaches a worker to that request at a proposed rate. When a submission is selected it becomes an assignment with dates, an approver, and a rate that is now fixed. Time entries attach to the assignment, approvals attach to time entries, and invoices are generated from approved time.

Because each object inherits from the one above it, an error early in the chain is expensive to correct late. A rate entered wrongly on a submission propagates into the assignment and then into every invoice generated from it, and unwinding that usually means credit notes rather than an edit. Suppliers that treat the submission screen as a form to get through quickly pay for it at month end.

Which configuration choices change supplier behaviour most?

Three settings do most of the work. Release timing decides whether every supplier sees a request simultaneously or a tier at a time, which sets how much duplicated effort the panel as a whole expends. Submission caps decide whether a supplier sends its two strongest profiles or fifteen hopeful ones. Rate enforcement decides whether an out-of-band rate is blocked at entry or negotiated later.

The fourth, and the one most often left loose, is what the system requires before a submission can be saved. Mandatory fields for availability, current compliance documents, and confirmed rate expectation push a real conversation with the worker earlier, before anyone's time is spent. A programme that asks for nothing gets submissions built on assumptions, and the cost surfaces at offer stage when the worker turns out to be unavailable on the start date.

What does the supplier see, and what does it not?

Supplier visibility is deliberately partial. A supplier generally sees its own submissions, its own assignments, and its own invoices, along with whatever status the programme chooses to expose on a request. It does not see competing submissions, other suppliers' rates, or the internal discussion behind a rejection. That asymmetry is intentional, since the buyer is trying to preserve competitive tension.

The practical consequence is that a supplier cannot diagnose its own performance from the system alone. Knowing that a submission was not selected says nothing about whether the rate was wrong, the profile was weak, or someone simply got there first. Suppliers that get value from a panel establish a separate feedback route with the programme rather than trying to read the outcome from status changes.

How should a supplier connect its own systems to a client's VMS?

The default state is dual entry. The supplier runs its own applicant tracking and payroll records, the client's programme runs the assignment, and the same facts are typed into both. Every re-keyed field is a chance for the two records to disagree about a rate, an end date, or an approver, and reconciliation at month end is where that disagreement is discovered.

Where volume through a single programme is high enough, an integration is worth building: requests pulled into the supplier's system, submissions pushed back, and assignment data synchronised so rates and dates are entered once. Where volume is low, a documented manual routine with one owner is usually more reliable than a partial integration nobody maintains. The decision should follow the volume, not the enthusiasm for automation.

What a VMS does not decide

It records the terms the parties agreed and the events that occurred. It does not determine whether a worker is correctly classified, whether an engagement structure is lawful in a given territory, or which party carries liability if either is later challenged. Those questions turn on local law and on how the working relationship actually operates, and both differ by country and often by state, so they belong with counsel rather than with a configuration setting.

It also does not judge quality. The system can hold a scorecard, a rating, or an assessment result, but it has no view on whether the shortlist was good. Programmes that mistake a complete audit trail for a well-run supply base end up with immaculate records of a mediocre outcome.