Awarded ITAD Identity Reveal & CRM Clone

During the bid round, the customer sees offers — price, services, certifications, trust tier — but not the bidder’s identity. The masking keeps the round honest: a customer who recognizes a familiar name shouldn’t favour them on the basis of recognition alone, and a bidder shouldn’t be able to game the round by exploiting a known relationship. At award, the mask comes off.

What the customer sees during the round

Each bid surfaces with: the net amount to the customer, the services included, the certifications the bidder claims to prove, the trust-score tier (platinum / gold / silver / bronze), the proposed pickup date, payment terms and the customer note. The bidder is shown as “ITAD #N” where N is a stable identifier across the customer’s session — so the customer can compare and discuss internally without ever needing the company name to track which bid is which. When a bidder revises its bid, the card says so.

What the customer sees at award

The moment the customer awards a bid, the winning ITAD’s partner card appears in the portal: the company name, its support e-mail, a phone number, the address and the website where those are filled in. It is a business card, not a dossier - enough to call the people who are coming to collect the hardware. The other bidders’ identities stay masked; the customer who awarded one ITAD doesn’t need the other bidders’ names. The award is final, and the portal says so before the button is pressed.

What happens on the ITAD’s side

The award itself does the clerical work. In one database operation the platform creates the customer as a company in the winning ITAD’s Core — or reuses the company it already has for that customer — and creates the inbound order and the collection that carry the pickup into planning and receiving. There is no “clone to CRM” button, because a button is a thing somebody forgets on a Friday. The won bid on /sourcing/won and the pickup calendar link straight to that collection. The relationship starts in the right database; the ITAD doesn’t have to retype anything.

Why a clone, not a join

Trade-in customer accounts and Core companies live in different scopes. The trade-in customer is a marketplace identity (they could have multiple ITADs working for them over time); the Core company is one ITAD’s view of one client. Cloning means each ITAD’s CRM has the customer as their own row, with their own contract and contact data, without any cross-tenant data leakage. Row Level Security would not allow the alternative anyway.

The trail

Accepting a bid writes an activity row: the bid was accepted in the trade-in portal, and the platform created the linked collection and inbound handoff. When a customer or a bidder later asks when this became known to whom, the answer is a row with a timestamp, not a memory of a phone call.