The Trade-In Module: How A Pickup Request Becomes A Pickup

The trade-in module is the customer-facing surface where corporate IT teams publish a pickup request, certified ITADs bid on it, the customer awards one, and the awarded work becomes real operations. It runs in its own app shell with its own auth, its own RLS, and its own UI - separate from the operator app where work is done, but wired into it through Coverage matching, the bid pipeline, and the notifications layer.

Customer-facing portal

A customer signs up through the trade-in flow. The portal has its own shell: dashboard, requests, pickups, invoices, certificates, a notification overview and settings. Each surface is scoped to the customer’s account. The customer sees their own request and proof, not somebody else’s clear-out from a different building. Portal users manage their own profile - name, phone, password and app language - while e-mail address and portal role stay read-only for the company admin or ReVend support to change. A viewer does not get a “New request” button; the portal says the role is read-only, and opening the wizard URL directly earns an explanation inside the portal instead of a 404.

Publishing a request

The wizard has five steps: items, compliance, security, logistics, review. Items is the per-device manifest. Compliance captures data treatment, required certifications and reporting needs. Security captures brand-protection, transport and site-access constraints. Logistics holds the address, floor and instructions, vehicle preference, priority and the earliest and latest pickup dates. Review is where the customer reads it all back before publishing. Submit, and the request lands in the matching pipeline.

The bid round

The matching engine finds ITAD tenants whose coverage matches the country, the required certifications and the required services. Each eligible ITAD sees the request in the Sourcing inbox with the requirements inline. They submit a structured bid: a price per requested item line, service quotes, a proposed pickup date, validity, payment terms and a customer note. Pre-award, the ITAD sees a city and a manifest but no company name, address or contact, and the customer sees anonymous bid cards. The bid round is about the work, not brand karaoke.

The award

The customer compares bids and awards one. The award is final. In the same operation the platform reveals the winning ITAD’s partner card to the customer, creates the customer as a company in the winning ITAD’s Core (or reuses one it already has), and creates the operational handoff: a collection plus an inbound order, ready for planning and receiving. No button to press afterwards. One award, three records.

Pickup, processing and proof

The awarded ITAD coordinates the pickup, receives the goods, tests, grades, erases where needed, and publishes certificates back to the customer portal as they become available. Pickup invoicing and operational finance belong to the ITAD’s Core records. ReVend tracks the handoff and proof; the ITAD team still does the physical work. Software remains bad at carrying pallets.

Smart relaxation

If a published request sits at zero bids, the request detail in the portal shows safe relaxation suggestions: drop one required certification or one required service, with how many extra partners that would unlock. Applying one edits the request in place and republishes it near the top of the Sourcing inbox. It only works while there are no bids and no award, and it never shows who those partners are. A customer who sees silence and gets no help leaves. A customer who sees “drop this one requirement and four ITADs can bid” has somewhere to go.