De white-labelchecklist: wat u een leverancier vraagt na het uploaden van het logo

White-labelling gaat mis op de plekken die niemand demonstreert. Het uploaden van het logo werkt altijd. Wat bepaalt of het personeel van een klant een jaar lang een platform kan gebruiken zonder de naam van uw leverancier tegen te komen, is de host in de link om een wachtwoord te resetten, het domein dat de notificatiemail heeft ondertekend, de tekst in het browsertabblad, en de inlogpagina waar iemand om acht uur 's ochtends koud op belandt, voordat er een sessie bestaat. Vraag naar die vier voordat u naar kleuren vraagt.

Elke leverancier zegt ja op "ondersteunt u white-labelling". Het woord dekt alles van een hexcode tot een tenant die werkelijk van u is, en beide antwoorden komen in dezelfde zelfverzekerde toon. Wat volgt is een checklist voor dat gesprek, geschreven als vragen in plaats van als functies: een functielijst nodigt uit tot een ja, een vraag nodigt uit tot een demonstratie.

Wat white-label betekent zodra u voorbij het logo bent

De bruikbare toets is niet of het logo van een klant verschijnt. Het is of enig moment in een gewone week — inloggen, een wachtwoord resetten, een e-mail openen, een link in een ticket plakken — de naam van de leverancier laat zien. Loop die week hardop door tijdens het gesprek.

Het domein, en de delen van een sessie die het verlaten

Een eigen domein is het dragende onderdeel; al het andere is versiering daarbovenop. Vijf vragen brengen u het grootste deel van de weg.

• Zit een eigen domein in het pakket dat ons wordt geoffreerd, of is het een meerprijs? Vraag om de regel op de offerte. Domeinen zijn een veelvoorkomende upsell, en op oudere platforms eerder een klus voor professional services dan een instelling.
• Wie geeft het TLS-certificaat uit, en wat gebeurt er bij verlenging? Automatische uitgifte en automatische verlenging, of elke paar maanden een ticket. Vraag wat een cursist ziet op de ochtend dat een verlenging mislukt.
• Eén domein voor het account, of één per organisatie? Draait u meerdere klantacademies of campussen, vraag dan op welke diepte een eigen hostnaam niet meer mogelijk is.
• Kunnen we het zelf inrichten? Het goede antwoord is een scherm dat de precieze DNS-records voor uw registrar toont, met een live status terwijl het certificaat wordt uitgegeven. Het verraderlijke antwoord is een mailwisseling met een supportafdeling.
• Welke delen van een sessie verlaten ons domein? Downloads, video, de toetsspeler, certificaatverificatie, een ingesloten helpwidget, de overdracht bij het inloggen. Vraag ze het netwerktabblad op een live tenant te openen en de hostnamen voor te lezen.

E-mail, en de link waar het masker afglijdt

E-mail is de helft van white-labelling die stilletjes bij de leverancier blijft. Een From-adres is een weergavetekst en iedereen kan er een instellen. Wat een mailprogramma daaronder leest, is het domein dat het bericht werkelijk heeft ondertekend.

From: Northbridge Academy <no-reply@learn.northbridge.edu>   <- the display line
Return-Path: bounces@mail.vendor-lms.com                     <- the envelope sender
DKIM-Signature: ... d=vendor-lms.com ...                     <- the signing domain

Gmail zet een klein "via vendor-lms.com" naast de afzender wanneer het ondertekenende domein niet overeenkomt met het From-domein. De IT-afdeling van uw klant weet wat dat betekent. Dus vraag:

• Welke berichten komen van ons domein, en welke van dat van u? Vraag om de volledige lijst — uitnodiging, welkom, wachtwoordreset, inschrijving, herinnering, cijfer vrijgegeven, certificaat uitgegeven, samenvatting, beheerdersmelding — en daarna welke daarvan onze afzender kunnen dragen.
• Alleen de From-regel, of ook het ondertekenende domein? De vervolgvraag is welke DNS-records u publiceert. Komt er geen enkele bij uw registrar te staan, dan vertrekt de post niet werkelijk vanaf uw domein.
• Een eigen verzendaccount en een eigen sleutel, of uw gedeelde pool? Op een gedeelde pool wordt het bouncepercentage van een andere tenant ongemerkt uw afleverprobleem.
• Per organisatie, of één keer bovenaan? Eén afzender voor het hele account maakt de zelfstandigheid bij de eerste e-mail ongedaan.
• Welk logo gebruikt de e-mail, en waar staat het? Een afbeelding die bij de leverancier staat, toont haar URL in de alt-tekst zodra een mailgateway externe afbeeldingen blokkeert.

Dan de link in het bericht, waar de meeste evaluaties de waarheid ontdekken. De inhoud kan uw logo, uw kleuren en uw afzender dragen, en de knop in het midden kan nog altijd naar de host van de leverancier wijzen — want uitnodigings- en resetlinks worden meestal aangemaakt door de authenticatielaag, één keer ingesteld, globaal, met één enkele site-URL.

De inlogpagina, het tabblad en de twee logo's

De inlogpagina is de lastigste pagina om van een huisstijl te voorzien en de eerste die elke cursist ziet. Voordat er iemand is geauthenticeerd, weet het platform niets van de bezoeker behalve de hostnaam waarop hij binnenkwam. Wordt de huisstijl geladen vanuit de organisatie van een ingelogde gebruiker, dan krijgt een koude bezoeker de standaard van de leverancier. Stel de vraag in precies deze woorden: wordt de huisstijl uitsluitend uit de hostnaam bepaald, voordat er een sessie bestaat?

• Wat wordt er op ons domein getoond aan een bezoeker zonder sessie? Logo, productnaam, kleuren, achtergrond, de tekst op de inlogknop.
• Staat er een "powered by"-regel, en wat haalt die weg? Een schakelaar, een duurder pakket, of een clausule in het contract. Alle drie komen voor, en ze kosten verschillend.
• Hoe zien de foutmeldingen eruit? Verkeerd wachtwoord, verlopen uitnodiging, geblokkeerd account — de pagina's die het vaakst de standaardsjablonen van de leverancier zijn, en de pagina's die een gefrustreerde gebruiker het zorgvuldigst leest.
• Wat staat er in het browsertabblad? De paginatitel op elke route, en de favicon. Vraag of de favicon per organisatie is of één bestand voor het hele platform; hem vanaf één vast pad serveren is een veelgebruikte kortere weg.
• Zijn er twee logo's? Een logo voor lichte modus, een voor donkere modus, meestal ook een vierkant beeldmerk. Vraag wat er gebeurt als u er één uploadt en een gebruiker naar donkere modus overschakelt.
• Wat staat er in de documenten die het platform verlaten? Certificaat-pdf's, geëxporteerde rapportages, cijferlijsten. Controleer de voettekst, en daarna de bestandsmetadata, waar een leveranciersnaam het langst overleeft.

Overerving, en op welk detailniveau

Draait u meer dan één organisatie — klantbedrijven, scholen in een groep, dochterondernemingen per land — dan is "erft de huisstijl over?" eerder een vraag over detailniveau dan een ja-of-neevraag, en juist op dat detailniveau verdwijnt het werk of vermenigvuldigt het zich.

• Als een onderliggende organisatie niets instelt, wat krijgt zij dan? Het merk van de ouder, of de standaard van de leverancier. Voor een groep is het tweede fout: elke nieuwe school begint haar leven met het uiterlijk van de leverancier.
• Alles of niets, of veld voor veld? Een school die het palet van de groep wil met een eigen schoolwapen, heeft terugval op veldniveau nodig. Overerving op blokniveau dwingt elk kind veertien kleuren opnieuw op te geven om één logo te wijzigen.
• Vallen het lichte en het donkere logo als paar terug? Vallen ze onafhankelijk terug, dan laat een kind dat alleen een licht logo uploadt het donkere logo van de ouder stranden tegen zijn nieuwe palet. Een kleine vraag die een veelzeggende stilte oplevert.
• Wie mag het wijzigen? De eigen beheerder van het kind, of elke wijziging via uw centrale team. Het tweede is een supportwachtrij die u over een jaar nog steeds draait.
• Hoe diep gaat het? Twee niveaus is gebruikelijk. Een uitgever met scholen die campussen hebben, heeft er meer nodig.
• Erft terminologie net zo goed over als vormgeving? Kunt u "student" hernoemen naar "deelnemer", vraag dan of dat naar beneden doorwerkt, en of het per taal apart wordt ingesteld.

Tests die u zelf uitvoert

De mobiele ervaring

Stel eerst vast wat u verkocht wordt, want "wij hebben mobiel" dekt twee producten met verschillende verhalen over huisstijl. Gaat het om een native app, dan zijn de vragen commercieel in plaats van cosmetisch. Wiens naam staat op de vermelding in de store? Wie bezit het ontwikkelaarsaccount, en wie dient de releases in? Is er een aparte build per klant, en een aparte beoordelingsronde daarbij?

Gaat het om een responsieve webapplicatie, dan loopt de huisstijl via hetzelfde codepad als de desktopsite, wat hier meestal het betere antwoord is. Vraag of u het op telefoonbreedte op uw eigen domein mag zien, en vraag daarna welke naam en welk pictogram verschijnen wanneer een cursist het aan zijn beginscherm toevoegt.

De paginabron

Uiteindelijk opent iemand de broncode — het IT-team van een klant, een nieuwsgierige cursist. U verbergt niets; u controleert of het platform gebouwd is om onder de naam van iemand anders te worden aangeboden. Twee commando's beantwoorden het grootste deel.

# Wiens naam staat op het certificaat dat op uw domein wordt aangeboden?
openssl s_client -connect learn.yourbrand.com:443 \
  -servername learn.yourbrand.com </dev/null 2>/dev/null \
  | openssl x509 -noout -text | grep -A1 'Subject Alternative Name'

# Wat zeggen de HTML en de responseheaders?
curl -sL https://learn.yourbrand.com | grep -io 'vendorname' | wc -l
curl -sI https://learn.yourbrand.com | grep -iE 'server|x-powered-by|content-security-policy'

De certificaatcontrole is de interessante. Sommige platforms geven een certificaat per klanthostnaam uit; andere zetten veel klanten op één certificaat met meerdere namen. Noemt de lijst met alternatieve namen op het domein van uw klant andere klanten, dan is dat publieke informatie over wie de leverancier nog meer bedient, en een securityreview vindt het.

Lees in de HTML de paginatitel, de `og:site_name`-tag, het webmanifest, de hostnamen waarvandaan de scripts en afbeeldingen laden, en de endpoints voor analytics en foutrapportage in de content-security-policy-header. Die endpoints verraden het het vaakst, omdat niemand ze als huisstijl beschouwt.

Hoe u het gesprek voert

1. Vraag om een live tenant op een domein dat u beheert, niet om een opgenomen demo. Een dag DNS-werk is een goedkopere test dan een jaar contract.
2. Laat ze een echte uitnodiging en een echte wachtwoordreset sturen naar een adres dat u beheert. Lees het linkdoel en de headers.
3. Open de inlogpagina koud, in een privévenster, in donkere modus, op een telefoon.
4. Draai de twee bovenstaande commando's tegen uw eigen hostnaam.
5. Verzamel de antwoorden in een gedeeld document, met datum. "In ontwikkeling" is een prima antwoord op papier en een slecht antwoord dat u in maand vier ontdekt.

Vraag door op de vragen die een demonstratie van een scherm opleveren in plaats van een antwoord. Die reactie is zelden ontwijking — meestal betekent het dat niemand het eerder heeft gevraagd.

Waar Lurno staat

Onze eigen antwoorden, de onafgemaakte onderdelen inbegrepen. Domeinen zijn per organisatie, op elke diepte van de boom, in te richten vanuit de eigen instellingen van die organisatie: typ de hostnaam, publiceer de DNS-records die het scherm u toont, volg de status tot het certificaat op actief staat, en markeer het domein daarna als primair. Hostnamen lopen via Cloudflare; TLS wordt automatisch uitgegeven en verlengd. De inlogpagina bepaalt logo, titel, slogan, thema en achtergrond uitsluitend uit de hostnaam, voordat er iemand is geauthenticeerd. Zodra een domein primair is, worden de uitnodigingslinks voor die organisatie erop gebouwd.

Huisstijl bestaat uit zeventien velden — veertien kleurtokens, het displaylettertype, het bodylettertype, de hoekafronding — plus een licht logo, een donker logo, een favicon, een titel en een slogan. De overerving beantwoordt de vraag over detailniveau hierboven: een suborganisatie zonder eigen thema neemt het hele thema van de ouder over, het logopaar erft als geheel over zodat u geen donker logo op een lichte achtergrond kunt laten stranden, en titel, slogan en favicon vallen veld voor veld terug. Terminologie is per taal te hernoemen, en notificatiemail vertrekt vanaf het eigen subdomein van de organisatie. Het volledige model staat op de white-labelpagina; wie de post verstuurt staat in de subverwerkerslijst op security.

De hiaten, ronduit. Er zijn geen native mobiele apps — Lurno is een responsieve webapplicatie, dus mobiel draagt dezelfde huisstijl als al het andere, maar er staat geen app op uw naam in een store, en native apps staan op de roadmap in plaats van dat ze geleverd zijn. Single sign-on met SAML en OIDC staat eveneens op de roadmap; wat er vandaag is, is partneraanmelding, waarbij uw eigen backend een ondertekende assertie overdraagt voor een cursist die hij al heeft geauthenticeerd. Betalingen en checkout zijn in ontwikkeling.

White-labelling is geen functie die bij aanmelding wordt aangezet. Het is een eigenschap van waar een leverancier zijn grenzen trok, jaren voordat u belde, en die grenzen zijn af te lezen in de adresbalk, de mailheaders en de paginabron van een live tenant. Een halfuur met een echt domein beslecht meer van deze lijst dan een middag bellen — ons gesprek inbegrepen, en daar is een demo voor.