Can I type in a work order and have the machine give me every part I need for the job?

Yes, as a project-scoped integration rather than a feature that is switched on. The machine can accept a work order, job or ticket reference and release the item list associated with it, recording each dispense against that reference, but the item list has to come from somewhere — either your ERP, CMMS or maintenance system answers a lookup for that work order, or the kit definitions are loaded onto the platform in advance and the reference selects one. Both are built against the system you run and the way your work orders are written, which is why the integration is scoped at quotation and not shipped as a preconfigured module. Integration methods supported through the VoT cloud platform are REST API, CSV export and import, and a direct database connector. The honest constraint is on your side of the interface: if your work orders do not already carry a reliable parts list, the machine cannot invent one, and the first phase of the project is usually cleaning up kit definitions rather than anything to do with hardware.

What does the integration need from our ERP or CMMS?

Five things, and none of them are unusual. First, a way to identify a work order — the reference format your technicians actually quote, including any prefixes or site codes. Second, a parts list per work order, with a part number and a quantity per line. Third, a mapping between your part numbers and the items loaded in the machine, which is the single most under-estimated task in the whole project. Fourth, an interface the machine can reach: a REST endpoint, a scheduled file exchange, or a database connection, with credentials and a network path that your IT team is willing to approve. Fifth, a decision about direction — whether the machine only reads work orders, or also writes the issued lines back so that the job record shows what was consumed. Send us the system name, the interface it exposes and a sample work order with its parts list, and the assessment is specific rather than general.

What happens if the machine does not hold everything on the work order?

It dispenses what it holds, records what it dispensed, and tells the technician what is outstanding — which is the behaviour to specify explicitly, because the alternative designs are worse. A machine that refuses to release a partial kit sends a technician to the job with nothing; a machine that silently drops the missing lines sends them to the job believing they have a complete kit. The partial-issue rule, what the screen says, and whether the shortfall raises an alert or a ticket in your system are decisions made during the integration design, not defaults you should assume. The same applies to items that are deliberately not in the machine: large, heavy or slow-moving parts usually stay in the store, so a realistic kit is the fast-moving consumable portion of the job plus a printed or on-screen list of what to collect elsewhere.

Does the work order reference show up in reporting afterwards?

Yes. The transaction record written to the cloud dashboard carries the employee name, key card number, transaction time, product, machine name, location and job ID, so consumption can be attributed to the job, work order or cost centre that consumed it rather than to a single unallocated overhead line. Every order also generates a unique receipt ID, which gives traceability back to the specific order, its items and its payment events if a query comes up later. Where a write-back integration is built, the same lines can be posted into the work order record in your own system so that the job history and the vending history do not have to be reconciled by hand. Without a write-back, the data still exists in the dashboard and can be exported, which is a reasonable first phase for sites that want the reporting before they want the coupling.

What happens to kitting when the network goes down?

The machine keeps dispensing and the lookup stops. Industrial machines continue operating during a network outage and sync transactions when connectivity returns, so authenticated workers can still draw items and every transaction is still recorded, but a work-order lookup is by definition a live question to a system that is currently unreachable. The fallback behaviour has to be chosen deliberately: allow normal item-by-item issue against a manually entered job reference, allow kits from a locally cached definition, or block kit issue until the link is back. Most sites choose the first, because a technician standing at a machine during a network fault still has a job to finish. One related setting to know about: automatic server synchronisation can be turned off in the admin interface, and if it is off, data does not flow until someone triggers a manual sync — worth checking before anyone concludes an integration is broken.

Is this the same thing as your ServiceNow integration?

It is the same pattern applied to a different system of record. The ServiceNow integration connects the machine to an ITSM platform over an API so that a dispense can create an incident, assign an asset to a user in the CMDB, deduct inventory, trigger replenishment when stock falls below a threshold, and write an audit entry — with the workflows configured to match the customer's existing processes. Work-order kitting connects the machine to whatever holds the work orders instead: an ERP, a CMMS, a maintenance or job management system. The connection, the field mapping and the workflows are scoped the same way and configured during deployment. If you already run ServiceNow and your work is managed there, the ServiceNow integration is the starting point rather than a separate project.

Work-Order Kitting and BOM Dispensing

A work-order kit is a single transaction in which the machine is given a job reference, looks up the item list that belongs to it, and releases the whole kit against that reference instead of making the technician select each part by hand. Two halves make it work, and they are usually bought as one thing by mistake. The first half is already standard on an industrial machine: the worker authenticates, a job, work order or cost centre is captured at issue, and every dispense is written to the transaction record with that reference attached. The second half is the lookup — the machine asking your ERP, CMMS or maintenance system what that work order actually needs — and that is a project-scoped integration built against the system you run, not an off-the-shelf module. It uses the same pattern as the ServiceNow connection: a documented interface, agreed fields, and a mapping between your part numbers and the machine’s positions. What decides whether it succeeds is almost never the machine. It is whether your work orders carry a complete, accurate parts list, and whether your part numbers match the items in the machine.

The request, in the buyer’s own words

The clearest statement of this requirement comes from a maintenance team, not from a vending brochure: a machine that holds fasteners, small parts and larger parts, and — the part nobody was offering — if we type in a work order, it will gather everything we need to complete it, every bolt and every wire.

That is a reasonable thing to want and a specific thing to buy. It is also routinely mis-sold, because the demonstration is easy and the delivery is not. This page sets out what the machine already does, what has to be built, what your side of the interface has to provide, and where kitting stops being the right answer.

Two halves of the same requirement

Buyers usually ask one question. There are two, and they have different answers.

Half	What it does	Status
Capture — the job reference is recorded at issue	The worker authenticates, selects or enters the job, work order or cost centre, draws items, and every line is written to the transaction record with that reference attached	Standard behaviour on an industrial machine. No integration required
Lookup — the machine is told what the job needs	The machine takes the work order reference, obtains the item list that belongs to it, and presents or releases that list as one kit	Project-scoped integration, built against your system

Capture alone already answers most of the reporting problem: it turns tooling and consumables from one monthly overhead figure into a cost attributable to the job that consumed it. That is described on the tool crib modernisation page and is part of how tool and parts vending differs from PPE vending.

Lookup is what the r/Automate request is actually asking for, and it is the half that requires your system to be able to answer the question.

What “kitting” means at the machine

A kit issue is one transaction containing several lines, rather than several transactions containing one line each. In practice the sequence is:

The technician authenticates — RFID card, PIN or biometric, depending on how the site is configured.
The work order reference is entered or scanned — typed on the touchscreen, scanned from a printed job sheet, or passed from a handheld.
The item list is resolved — either by a live lookup into your system, or by matching the reference to a kit definition already loaded on the platform.
The kit is filtered against what the machine holds — lines the machine stocks are dispensed; lines it does not stock are reported as outstanding.
The items are released — where the machine runs a multi-select order, the whole kit is taken as one order; elevator builds run one selection at a time, which changes the interaction and should be settled at design time.
The transaction is written — each line recorded with employee, item, quantity, machine, location, time and the job reference, and the order carries a receipt ID for later traceability.

Step 5 is worth reading twice. On machines running with the elevator, the multi-select shopping cart is disabled so that the drop sensor functions correctly, and the machine works in instant-purchase mode — one selection at a time. That is a real constraint on how a kit is presented, and it is the kind of detail that separates a specification from a demonstration. The mechanical background is on dispense reliability.

What the integration needs from your system

This is the section to take into the meeting with your IT and maintenance leads. Nothing here is exotic; all of it has to be decided.

Requirement	What we need to know	Why it decides the design
Work order identifier	The reference format technicians actually quote, including prefixes, site codes and any leading zeros	It is what the technician will type or scan at the machine; the format has to be validated on screen
Parts list per work order	Whether a work order carries a structured parts list with part number and quantity per line, or free text	Free-text parts lists cannot be resolved automatically; they need kit definitions instead
Part number mapping	Your part numbers against the items loaded in the machine	The most under-estimated task in the project — see below
Interface	REST endpoint, scheduled file exchange, or direct database connection, plus credentials and network path	Determines whether the lookup is live or based on a periodic refresh
Direction	Read-only lookup, or read plus write-back of issued lines to the job record	Write-back removes the reconciliation step but needs a permission and a field mapping on your side
Authorisation rules	Whether the work order itself grants entitlement, or the worker’s role does, or both	Decides whether a technician can draw a kit for a job that is not assigned to them
Failure behaviour	What happens when the lookup fails, times out, or returns nothing	Never leave this to a default; it is the case your technicians will meet first

Integration through the VoT cloud platform is supported by REST API, CSV export and import, and a direct database connector. Which of the three suits you depends on what your system exposes and what your IT team will approve, so the practical next step is to send us the system name and a sample work order with its parts list, and take a specific assessment rather than a general assurance.

Part number mapping is the real project

Every kitting project is a data project wearing hardware. The machine holds positions; your work orders hold part numbers; something has to reconcile the two, including:

Unit of issue. The work order says four bolts. The machine holds a box of fifty. Which one is a line?
Supersessions. The part number on a five-year-old work order is not the part number you buy today.
Duplicates. The same physical item under two part numbers from two suppliers.
Variants that matter. A glove size, a thread pitch, an insert grade — items a description treats as one line and a technician does not.
Items that are not in the machine. Most work orders include parts that will never be vended. The mapping has to say so explicitly rather than leaving them to fall silently off the kit.

None of this is difficult. All of it takes longer than the connector does, and a project plan that does not allow for it will slip on the data, not on the integration.

What is recorded against the reference

Once the reference is on the transaction, the reporting follows without anyone typing it in twice. The record written to the cloud dashboard carries:

Field	What it lets you do
Employee name and key card number	Attribute the issue to a person, and see who is drawing kits they are not assigned
Transaction time	Reconstruct the sequence around a job, a shift or an incident
Product and quantity	See real consumption per line rather than an estimate
Machine name and location	Compare consumption between bays, cells or sites
Job ID	Cost the issue to the job, work order or cost centre that consumed it
Receipt ID on the order	Trace a specific order, its items and its payment events after the fact

That is enough for job costing, for consumption analysis per job type, and for spotting the outlier jobs — the ones that consume two or three times what the same job number consumed last month. Where a write-back is built, the same lines are posted into your own job record so the vending history and the job history do not need reconciling.

Where they should end up depends on the system of record you already run. The ServiceNow integration is the worked example of this pattern: dispense events create tickets, assign assets in the CMDB, deduct inventory and trigger replenishment, with the workflows configured to match existing processes. An ERP, CMMS or maintenance system is connected the same way, as described for MRO vending and on the industrial vending hub.

The cases that decide whether people trust it

A kitting system is judged on its bad days. Decide each of these during design, and write the decision into the specification.

Partial kits. The machine holds eight of the eleven lines. It should dispense the eight, record them, and display the three that are outstanding. Refusing the whole kit sends a technician away empty-handed; silently dropping the three sends them to the job believing the kit is complete.
Substitutions. If the exact part is out of stock but an accepted alternative is in the machine, someone has to have decided in advance whether that substitution is permitted, and the substitution must appear in the record.
Over-draw. A technician needs more than the work order specified, because two bolts were damaged. Blocking that produces workarounds; allowing it silently destroys the costing. The usual answer is to allow it, record it against the same reference, and let the variance be visible.
Returnable items in the kit. Instruments, torque wrenches and calibrated tools belong in locker cells that dispense and accept returns, with the return recorded against the same job. That is the hybrid arrangement described on weight sensor cell tracking.
Cancelled and re-issued work orders. If a job is cancelled after the kit was drawn, the parts are already out. The record has to survive the cancellation, which is a question about your system’s behaviour more than ours.
Network outage. Machines continue operating and sync transactions when connectivity returns, but a live lookup cannot happen while the link is down. Choose the fallback deliberately — manual job entry, cached kit definitions, or no kit issue until the link returns.
Automatic server sync turned off. The admin interface allows automatic synchronisation with the backend to be disabled. If it is off, changes and transactions wait for a manual sync. Check this setting before anyone concludes an integration has failed.

Where work-order kitting is the wrong answer

It suits some work and not others, and a supplier who says otherwise has not run one.

Work orders without a reliable parts list. If the parts list is free text, out of date, or filled in after the job rather than before, the lookup has nothing to resolve. Fix the kit definitions first; the machine will not fix them for you.
Diagnostic and fault-finding work. A technician who does not yet know what is wrong cannot be issued the parts for the repair. Kitting suits planned maintenance, scheduled changeovers and repeatable jobs far better than breakdown response.
Large or heavy parts. Motors, pumps, panels and long stock stay in the store. Vending the consumable half of a kit is legitimate; pretending the machine can hold the whole bill of materials is not.
Very low job volume. If a job type runs twice a year, the mapping and maintenance effort outlives its value. Automate the jobs that repeat.
One-off fabrication and project work. Every job is different, so there is no kit to define.
Sites where the parts list is really the technician’s judgement. Some work is specified by the person doing it. A machine can record what they took; it should not pretend to have decided it.

The realistic outcome on most sites is a machine holding the fast-moving fasteners, consumables and small parts that make up the bulk of the lines on a planned work order, with everything else collected from the store as it always was — and one job reference tying both together in the reporting.

Phasing a kitting project

Each phase is useful on its own, which is what makes it safe to stop after any of them.

Phase	What is delivered	What you learn
1 — Capture	Job, work order or cost centre selected at issue; every transaction carries the reference	Which jobs actually consume what, before any integration exists
2 — Kit definitions	The repeatable jobs written up as item lists and validated against real consumption from phase 1	Whether your kits are accurate; usually the phase that finds the data problems
3 — Lookup	The machine resolves a work order reference to its item list through the agreed interface	Whether the reference format, mapping and network path work in practice
4 — Write-back	Issued lines posted into the work order record in your system	Removes the reconciliation step and closes the loop on job costing
5 — Tuning	Stock levels, kit contents and par levels adjusted against measured demand	Which lines belong in the machine and which belong in the store

Phase 1 requires no integration work at all. If you are unsure whether the full project is worth it, run phase 1 for a quarter and let the transaction data answer the question.

Questions to send any supplier

Copy these into the enquiry. They are the questions that separate a working integration from a demonstration.

Is work-order kitting an off-the-shelf module or a project-scoped integration, and which parts are configuration rather than development?
Which integration methods do you support — REST API, file exchange, direct database connector — and which one do you propose for our system?
Does the machine read our work orders live, or does it work from kit definitions synchronised in advance?
How are our part numbers mapped to items in the machine, who does that work, and how are supersessions and unit-of-issue differences handled?
What happens when the machine holds only part of the kit, and what does the technician see?
Are substitutions permitted, and do they appear in the record?
Can a technician draw more than the work order specified, and is the variance visible afterwards?
What is written back into our system, and what is only available in your dashboard?
What happens to kit issue during a network outage, and what happens to the records afterwards?
Can returnable items be part of a kit, and is the return recorded against the same job reference?

How KioskForce answers each point

Point	Our answer
Off-the-shelf or project	Project-scoped integration. Job reference capture and the transaction record are standard; the work-order lookup is built against your system and scoped at quotation
Integration methods	REST API, CSV export and import, or a direct database connector through the VoT cloud platform. Send us the system you run for a specific assessment
Live lookup vs cached definitions	Both patterns are supported; which is appropriate depends on what your system exposes and how your network is arranged. Decided during integration design
Part number mapping	Worked through with your data before build. We will tell you plainly if the parts lists are not yet in a state that supports automated resolution
Partial kits	Dispense what is held, record it, display what is outstanding. The rule is written into the specification rather than assumed
Substitutions	A policy decision taken with you, and recorded on the transaction when permitted
Over-draw	Recorded against the same reference so the variance is visible rather than hidden
Write-back	Available as part of the integration scope; the ServiceNow connection is the worked example of dispense events posting into a system of record
Offline behaviour	The machine keeps dispensing and syncs when connectivity returns; live lookup requires the link, so the fallback is chosen deliberately
Returnable items	Locker cells dispense and accept returns, with the return recorded — optionally verified by per-cell weight sensing specified at order

ServiceNow integration — the worked example of dispense events posting into a system of record
Industrial vending — the PPE, tool and MRO hub, including the deployment and integration sequence
Tool and parts vending — job and work-order capture at the point of issue
Tool crib modernisation — inventorying items and defining entitlements before any integration
MRO vending — pushing consumption data to a procurement or ERP system
Dispense reliability — multi-select orders, elevator builds and why fit is checked before the build
Weight sensor cell tracking — verified dispense and return for returnable items in a kit
PPE cost control — quotas, entitlements and what the transaction record supports
Customization — how software and integration scope is agreed
How to vet a manufacturer — testing an integration claim before you commit
FAQ — short-form answers, including work-order kitting

Get started

Tell us which system holds your work orders, send a sample work order with its parts list, and say which lines you would want the machine to hold. We will come back with an assessment of the integration, the mapping work it implies, and an honest view of which parts of your kits belong in a machine and which belong in the store.

Contact Us for More Information