Wiki/Core Operations/Collections: Schedule → Confirm → Drive → Deliver → Inbound
14Core Operations4 min read

Collections: Schedule → Confirm → Drive → Deliver → Inbound

The pickup workflow that ends with an inbound order creating itself, with the client and contract already filled in.

A collection in ITAD is the act of going to the client’s site and picking up the equipment. It’s also the part of the workflow where, in most operations, the most retyping happens — client name, contract reference, contact info, all entered three times into three systems. The platform records the pickup once and hands it to receiving with the context intact.

The status flow

A collection starts as requested, created by your team from the collections list, from a company page or from a contract. It moves to confirmed when the slot is locked, to scheduled when a driver and vehicle are assigned, to in progress when the driver is on site, to collected when the equipment is loaded, and to delivered when it arrives at your warehouse — and at that moment the inbound order creates itself with the client, the contract, the contact and the vehicle reference already filled in. A collection that will not happen goes to cancelled. Every collection carries a number in the form COL-2026-00017, assigned per tenant per year by the database, never computed in the browser.

When the handoff hiccups

If the inbound order cannot be created at the moment of delivery, the collection stays delivered, the operator sees an error rather than a false success, and a Create inbound order button appears on the detail page until an inbound is linked. It uses the same creation path, so the retry produces the same order the automatic step would have. On the other side, an inbound order that came from a collection shows that collection in its header, so receiving can check where the goods were promised, planned and delivered before the first scan.

Driver and fleet

Choose a driver from the directory when adding or editing a visit to assign it to that person. Their linked user account sees the visit in the mobile route on its planned day, or among unscheduled stops when no date is set. A manually entered name and phone number are contact details only. The fleet choice on a new collection currently copies a vehicle type; it does not reserve a vehicle or check time and capacity conflicts.

Tracking and revert

The collection detail page (/core/collections/[slug]) shows the client, contact and address, the requested date and time window, priority, vehicle, carrier, driver and tracking, and the linked inbound order once delivery has created one. If a status needs to go back — the driver was assigned to the wrong slot, the pickup did not actually happen — the revert preview shows the side effects before the change is committed, and every step back requires a reason. Delivered is no exception: it can step back to collected, and an inbound order that was already created stays in place; the preview says so. Force completion exists for the day the paperwork lags the truck.

Which contracts a collection can use

The contract picker on a new collection shows active contracts and draft contracts marked “Draft”. Terminated, expired and superseded contracts do not appear. An ITAD often plans the first pickup while the signature is still in the post; a draft is allowed to carry that work. A contract that has ended is not allowed to start new work, ever.

The public request form

/request-collection on the marketing site is the customer-facing entrance: a seven-step form — contact, items, compliance, security, logistics, schedule, review — for an organization that wants its equipment picked up. The submission is saved as a pending trade-in pickup draft and the visitor is handed to signup as a trade-in customer. It is the start of a trade-in request that ITADs bid on, not a draft collection inside any one ITAD’s Core. Two doors, one warehouse. Predictable Wednesday.