Wissensbasis/Konformität/Der Certifications Catalog: warum R2v3 und B Corp in derselben Liste leben
01Konformität3 Min. Lesezeit

Der Certifications Catalog: warum R2v3 und B Corp in derselben Liste leben

Wie der Certifications Catalog funktioniert, warum auch die Nischenstandards drin sind und was verified status wirklich bewirkt.

ITAD ist eine der wenigen Branchen, in denen der Unterschied zwischen zwei Companies vor allem darin besteht, welchen Audit sie zuletzt bestanden haben. R2v3, NAID AAA, ISO 14001, e-Stewards, B Corp, ADISA, RIOS, WEEELABEX — den Procurement Officer einer großen Bank interessiert, welche davon Sie halten, weil sein Compliance Team danach fragen wird und er nicht das Team sein will, das einen ITAD-Partner gewählt hat, der das Certificate nicht liefern konnte, als es zählte.

Der Certifications Catalog kommt mit den großen Standards eingebaut, jeder mit Category, Issuing Body, Scope, der typischen Renewal Period in Monaten und einer Website. Er deckt die Standards ab, die jeder ITAD kennt. Er deckt auch die Nischenstandards ab — denn wenn Ihr Warehouse eine regionale Certification hält, die nicht auf der globalen Liste steht, zählt sie trotzdem, wenn sie zählt.

Was in einem Certification Record steckt

Für jede Certification, die eine Company hält: der Standard (verlinkt auf die Catalog Row), die Certificate Number, das Issue Date, das Expiry Date, der Scope und das Certificate Document selbst, gespeichert als Evidence. Die Catalog Row sagt, was der Standard ist; der Company Record sagt, dass diese Company ihn hält, bis wann und wo der Nachweis liegt.

Verified status

Ein Certification Record kann von Platform Staff als verified markiert werden — von jemandem, der das Certificate Document tatsächlich angesehen und bestätigt hat, dass es zum Catalog Standard passt; die Review Queue liegt unter /admin/certifications/pending. Verified Certifications tragen Gewicht im Trust Score (bis zu 10 Bonuspunkte, gewichtet nach Catalog Category). Unverified Certifications erscheinen auf dem Company Profile, tragen aber nicht zum Score bei — denn behaupten kann jeder eine Certification, und der Unterschied zwischen „behauptet“ und „verified“ ist der ganze Sinn eines Catalogs.

Wird eine Verification erteilt oder läuft ein verified Certificate ab, rechnet ein Database Trigger den Trust Score neu. Ein Seller, der R2v3 verfallen lässt, fällt also in derselben Woche im Ranking, in der das Cert abläuft, und nicht erst, wenn jemand den Score von Hand anstupst.

Der Catalog und die Pickup Request

Der Trade-in Request Wizard fragt den Kunden, welche Certifications der bietende ITAD halten muss, aus einer kurzen festen Liste: R2v3, e-Stewards, NAID AAA, ISO 14001, ISO 27001 und WEEELABEX. Diese Codes spiegeln die Certification Tags, die ein ITAD auf seiner Sourcing Coverage setzt, und eine Request erreicht nur die Inboxes, in denen jeder geforderte Tag vorhanden ist. Der Catalog ist die lange Liste für Profile und Ausschreibungen; die Wizard-Liste ist die kurze Liste, die das Matching gatet. Sechs Codes reichen, um einen Pickup zu routen. Hundert würden nur längere Formulare erzeugen und dieselben sechs Antworten.

Die Nischenstandards

Catalog Rows gehören dem Tenant, eine Organisation kann also neben den System Rows eigene Einträge für Standards anlegen, von denen sonst niemand gehört hat — ein nationales E-Waste-Scheme, ISO 27001 mit einem bestimmten Annex-A-Scope. Sie erscheinen auf dem Profil und in Tender-Antworten. Weil Procurement Teams danach fragen, und „wir haben das, aber es steht nicht in der Plattform“ eine schlechtere Antwort ist als „ja, hier ist es“.