Revelación de identidad del ITAD adjudicado y clon al CRM
Por qué la identidad de quien puja sigue enmascarada durante la ronda, qué ve el cliente al adjudicar y cómo la propia adjudicación planta al cliente en el Core del ITAD ganador.
Durante la ronda de ofertas, el cliente ve propuestas —precio, servicios, certificaciones, nivel de confianza— pero no la identidad de quien puja. El enmascaramiento mantiene la ronda honesta: un cliente que reconoce un nombre conocido no debería favorecerlo solo por reconocerlo, y quien puja no debería poder manipular la ronda explotando una relación previa. Al adjudicar, cae la máscara.
Qué ve el cliente durante la ronda
Cada oferta aparece con: el importe neto para el cliente, los servicios incluidos, las certificaciones que el postor dice poder demostrar, el nivel de la puntuación de confianza (platino / oro / plata / bronce), la fecha de recogida propuesta, las condiciones de pago y la nota para el cliente. El postor se muestra como “ITAD n.º N”, donde N es un identificador estable durante la sesión del cliente, de modo que el cliente puede comparar y discutir internamente sin necesitar el nombre de la empresa para saber cuál es cada oferta. Cuando alguien revisa su oferta, la tarjeta lo dice.
Qué ve el cliente al adjudicar
En el momento en que el cliente adjudica una oferta, la ficha de partner del ITAD ganador aparece en el portal: el nombre de la empresa, su correo de soporte, un teléfono, la dirección y la web, donde estén rellenos. Es una tarjeta de visita, no un dosier: lo justo para llamar a la gente que va a venir a llevarse el hardware. Las identidades de los demás postores siguen enmascaradas; el cliente que ha adjudicado a un ITAD no necesita los nombres de los otros. La adjudicación es definitiva, y el portal lo dice antes de que se pulse el botón.
Qué pasa del lado del ITAD
La adjudicación hace ella sola el trabajo administrativo. En una sola operación de base de datos, la plataforma crea al cliente como empresa en el Core del ITAD ganador —o reutiliza la empresa que ya tenía para ese cliente— y crea la orden entrante y la recogida que llevan el trabajo a planificación y recepción. No hay botón de “clonar al CRM”, porque un botón es algo que alguien se olvida un viernes. La oferta ganada en /sourcing/won y el calendario de recogidas enlazan directamente a esa recogida. La relación empieza en la base de datos correcta; el ITAD no tiene que reteclear nada.
Por qué un clon y no una unión
Las cuentas de cliente de Trade-in y las empresas de Core viven en ámbitos distintos. El cliente de Trade-in es una identidad de marketplace (puede tener varios ITADs trabajando para él a lo largo del tiempo); la empresa de Core es la visión que un ITAD tiene de un cliente. Clonar significa que el CRM de cada ITAD tiene al cliente como fila propia, con su propio contrato y sus propios datos de contacto, sin ninguna fuga de datos entre tenants. Row Level Security tampoco permitiría la alternativa.
El rastro
Aceptar una oferta escribe una fila de actividad: la oferta se aceptó en el portal de Trade-in, y la plataforma creó la recogida enlazada y el traspaso de entrada. Cuando un cliente o un postor pregunte más adelante cuándo supo quién qué, la respuesta es una fila con marca de tiempo, no el recuerdo de una llamada.