Vai al contenuto
lurno
Tutti gli articoli
Blog

La checklist white-label: che cosa chiedere a un fornitore dopo il caricamento del logo

Il white-label non è il caricamento di un logo. Le domande da fare su domini, domini di invio, link di reimpostazione, ereditarietà e ciò che rivela il codice sorgente delle sue pagine.

The Lurno teamAugmental13 min di lettura

Il white-label fallisce nei punti che nessuno mostra in demo. Il caricamento del logo funziona sempre. Ciò che decide se il personale di un cliente potrà usare una piattaforma per un anno senza mai incontrare il nome del suo fornitore è l'host dentro il link di reimpostazione della password, il dominio che ha firmato l'email di notifica, il testo nella scheda del browser e la pagina di accesso su cui qualcuno atterra a freddo alle 8 del mattino, prima che esista una sessione. Chieda di questi quattro punti prima di chiedere dei colori.

Ogni fornitore risponde di sì alla domanda "supportate il white-label?". La parola copre tutto, da un codice esadecimale a un tenant che è davvero suo, e le due risposte arrivano con lo stesso tono sicuro. Quella che segue è una checklist per la call, scritta come domande e non come funzionalità: un elenco di funzionalità invita a un sì, una domanda invita a una dimostrazione.

White-label

Erogare una piattaforma sotto il proprio nome, il proprio dominio e il proprio design, in modo che chi la usa non abbia particolari motivi di sapere chi l'ha costruita. Il theming è un sottoinsieme: colori, font e un logo sulle pagine che vede un utente autenticato. Il white-label è tutta la superficie — barra degli indirizzi, intestazioni delle email, pagina di accesso, scheda del browser, codice sorgente della pagina. Il theming è configurazione; il white-label è in gran parte architettura.

La prova utile non è se compare il logo del cliente. È se un qualsiasi momento di una settimana ordinaria — accedere, reimpostare una password, aprire un'email, incollare un link dentro un ticket — fa emergere il nome del fornitore. Percorra quella settimana ad alta voce durante la call.

Lurno

Il dipendente di un cliente accede sul dominio del proprio datore di lavoro, riceve email firmate dal dominio del proprio datore di lavoro e incolla un link di assistenza che porta il nome del proprio datore di lavoro.

Not this

Un logo e un codice esadecimale su un prodotto che continua a stare su yourcompany.vendor.com e a scrivere da no-reply@vendor.com.

Il dominio, e le parti di una sessione che ne escono

Il dominio personalizzato è l'elemento portante; tutto il resto è decorazione che ci sta sopra. Cinque domande portano quasi a destinazione.

  • Il dominio personalizzato è incluso nel piano che ci state quotando, oppure è un modulo aggiuntivo? Chieda la voce di listino. I domini sono un upsell frequente e, sulle piattaforme più datate, un'attività di servizi professionali anziché un'impostazione.
  • Chi emette il certificato TLS, e che cosa succede quando si rinnova? Emissione e rinnovo automatici, oppure un ticket ogni pochi mesi. Chieda che cosa vede un discente la mattina in cui un rinnovo fallisce.
  • Un dominio per l'account, oppure uno per organizzazione? Se gestisce più academy clienti o più sedi, chieda a quale profondità un hostname separato smette di essere possibile.
  • Possiamo configurarlo da soli? La risposta buona è una schermata che mostra i record DNS esatti per il suo registrar e uno stato in tempo reale mentre il certificato viene emesso. Il segnale opposto è uno scambio di email con un servizio di assistenza.
  • Quali parti di una sessione escono dal nostro dominio? I download, i video, il player delle valutazioni, la verifica dei certificati, un widget di assistenza incorporato, il passaggio di consegne dell'autenticazione. Chieda loro di aprire la scheda di rete su un tenant reale e di leggere ad alta voce gli hostname.

I discenti vedranno mai il dominio del fornitore, se abbiamo un dominio personalizzato?

Di solito da qualche parte sì, e la domanda è dove. Le fughe più comuni sono il redirect durante l'accesso, i media serviti da una CDN condivisa, la pagina a cui porta il link di verifica di un certificato e qualunque widget di chat incorporato. Ciascuna discende da come è stata costruita la piattaforma, e ciascuna è visibile a un discente: le chieda quindi una per una, per nome.

L'email è la metà del white-label che, silenziosamente, resta al fornitore. L'indirizzo nel campo From è una stringa di visualizzazione e chiunque può impostarla. Quello che un client di posta legge sotto è il dominio che ha davvero firmato il messaggio.

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 mette un piccolo "via vendor-lms.com" accanto al mittente quando il dominio che firma non coincide con quello del campo From. L'ufficio IT del suo cliente sa che cosa significa. Quindi chieda:

  • Quali messaggi partono dal nostro dominio e quali dal vostro? Chieda l'elenco completo — invito, benvenuto, reimpostazione della password, iscrizione, promemoria, voto pubblicato, certificato emesso, riepilogo, avviso agli amministratori — e poi quali di questi possono portare il nostro mittente.
  • Solo la riga del From, oppure anche il dominio che firma? La domanda successiva è quali record DNS deve pubblicare lei. Se nessuno di questi va sul suo registrar, la posta non sta davvero uscendo dal suo dominio.
  • Un nostro account di invio e una nostra chiave, oppure il vostro pool condiviso? Su un pool condiviso il tasso di rimbalzo di un altro tenant diventa, senza che si veda, un suo problema di recapito.
  • Per organizzazione, oppure una volta sola in cima? Un unico mittente per l'intero account disfa l'indipendenza già alla prima email.
  • Quale logo usa l'email, e dove è ospitato? Un'immagine ospitata dal fornitore mostra il proprio URL nel testo alternativo ogni volta che un gateway di posta blocca le immagini remote.

Poi c'è il link dentro il messaggio, dove la maggior parte delle valutazioni scopre come stanno le cose. Il corpo dell'email può portare il suo logo, i suoi colori e il suo mittente, e il pulsante al centro può comunque puntare all'host del fornitore, perché i link di invito e di reimpostazione vengono di solito generati dal livello di autenticazione, configurato una volta sola, a livello globale, con un unico URL del sito.

Le email di reimpostazione della password e di invito usano il mio dominio?

Spesso no, anche su piattaforme che brandizzano bene tutto il resto, ed è il punto in cui la maschera cade più di frequente. Quei link vengono di solito generati a partire da un unico URL del sito configurato globalmente, quindi un messaggio può sembrare interamente suo mentre il link al suo interno porta all'host del fornitore. Questa non la chieda: la verifichi, leggendo di persona la destinazione del link e le intestazioni.

La pagina di accesso è la più difficile da brandizzare ed è la prima che ogni discente vede. Prima che qualcuno si autentichi, la piattaforma non sa nulla del visitatore tranne l'hostname da cui è arrivato. Se il brand viene caricato a partire dall'organizzazione di un utente autenticato, un visitatore a freddo ottiene il default del fornitore. Lo chieda con queste parole esatte: il brand si risolve dal solo hostname, prima che esista una sessione?

  • Che cosa viene mostrato sul nostro dominio a un visitatore senza sessione? Logo, nome del prodotto, colori, sfondo, il testo sul pulsante di accesso.
  • C'è una riga "powered by", e che cosa la toglie? Un'opzione da disattivare, un piano superiore o una clausola nel contratto. Esistono tutte e tre, e costano cifre diverse.
  • Che aspetto hanno gli stati di errore? Password sbagliata, invito scaduto, account bloccato: sono le pagine che con più probabilità restano i template di default del fornitore, e quelle che un utente esasperato legge con più attenzione.
  • Che cosa c'è nella scheda del browser? Il titolo della pagina su ogni percorso, e la favicon. Chieda se la favicon è per organizzazione o se è un unico file per l'intera piattaforma; servirla da un solo percorso statico è una scorciatoia frequente.
  • Ci sono due logo? Uno per il tema chiaro, uno per il tema scuro, di solito anche un marchio quadrato. Chieda che cosa succede se ne carica uno solo e un utente passa al tema scuro.
  • Che cosa c'è nei documenti che escono dalla piattaforma? I PDF dei certificati, i report esportati, i registri delle carriere. Controlli il piè di pagina e poi i metadati del file, dove il nome di un fornitore sopravvive più a lungo.

L'ereditarietà, e con quale granularità

Se gestisce più di un'organizzazione — aziende clienti, scuole di un gruppo, filiali nazionali — la domanda "il brand si eredita?" è una domanda di granularità e non da sì o no, ed è nella granularità che il lavoro sparisce oppure si moltiplica.

  • Se un'organizzazione figlia non imposta nulla, che cosa ottiene? Il brand del padre, oppure il default del fornitore. Per un gruppo la seconda risposta è sbagliata: ogni nuova scuola comincia la propria vita con l'aspetto del fornitore.
  • Tutto o niente, oppure campo per campo? Una scuola che vuole la palette del gruppo e il proprio stemma ha bisogno di un fallback a livello di campo. L'ereditarietà a blocchi obbliga ogni figlio a ridichiarare quattordici colori per cambiare un logo.
  • Il logo chiaro e quello scuro ricadono sul default come coppia? Se ricadono in modo indipendente, un figlio che carica solo il logo chiaro lascia il logo scuro del padre appeso contro la propria nuova palette. Una piccola domanda che produce una pausa istruttiva.
  • Chi è autorizzato a modificarlo? L'amministratore del figlio stesso, oppure ogni modifica passa dal suo team centrale. La seconda è una coda di assistenza che starà ancora gestendo fra un anno.
  • Fin dove scende in profondità? Due livelli è la norma. Un editore con scuole che hanno più sedi ha bisogno di più.
  • Si eredita anche la terminologia, oltre al design? Se può rinominare "studente" in "partecipante", chieda se la modifica scende a cascata e se va impostata separatamente per ogni lingua.

Ogni sotto-organizzazione può avere brand e dominio propri, oppure solo l'account principale?

Su questo punto le differenze sono più marcate che su qualsiasi altra voce dell'elenco, ed è ciò che separa una piattaforma davvero multi-tenant da una single-tenant con un tema sopra. Molti prodotti brandizzano l'account e danno agli account figli una vista filtrata del brand del padre: va bene per i dipartimenti, è sbagliato per i clienti. Chieda se un figlio può avere un proprio hostname, un proprio certificato, una propria coppia di logo, una propria palette e un proprio mittente, e a quale profondità queste cose si fermano.

Prove da fare di persona

L'esperienza da mobile

Per prima cosa stabilisca che cosa le stanno vendendo, perché "abbiamo il mobile" copre due prodotti con storie di branding diverse. Se si tratta di un'app nativa, le domande sono commerciali più che estetiche. Di chi è il nome sulla scheda dello store? Chi è il titolare dell'account sviluppatore e chi invia le release? C'è una build separata per ogni cliente, e con essa un ciclo di revisione separato?

Se si tratta di un'applicazione web responsive, il brand passa dallo stesso percorso di codice del sito desktop, che qui di solito è la risposta migliore. Chieda di vederla alla larghezza di un telefono sul suo dominio, e poi chieda quale nome e quale icona compaiono quando un discente la aggiunge alla schermata iniziale.

Il codice sorgente della pagina

Prima o poi qualcuno aprirà il codice sorgente: l'ufficio IT di un cliente, un discente curioso. Non sta nascondendo nulla; sta verificando se la piattaforma è stata costruita per essere servita sotto il nome di qualcun altro. Due comandi rispondono a quasi tutto.

# Di chi è il nome sul certificato servito sul suo dominio?
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'

# Che cosa dicono l'HTML e le intestazioni della risposta?
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'

Il controllo sul certificato è quello interessante. Alcune piattaforme emettono un certificato per ogni hostname cliente; altre mettono molti clienti su un unico certificato multi-nome. Se l'elenco dei nomi alternativi sul dominio del suo cliente nomina altri clienti, quella è un'informazione pubblica su chi altro serve il fornitore, e una verifica di sicurezza la troverà.

Nell'HTML, legga il titolo della pagina, il tag `og:site_name`, il web manifest, gli hostname da cui vengono caricati script e immagini, e gli endpoint di analytics e di segnalazione degli errori nell'intestazione della content security policy. Quegli endpoint sono la spia più frequente, perché nessuno li considera parte del branding.

Come condurre la call

  1. Chieda un tenant reale su un dominio che controlla lei, non una demo registrata. Un giorno di lavoro sul DNS è una prova più economica di un anno di contratto.
  2. Si faccia inviare un invito vero e una vera reimpostazione della password a un indirizzo che controlla lei. Legga la destinazione del link e le intestazioni.
  3. Apra la pagina di accesso a freddo, in una finestra privata, in tema scuro, da telefono.
  4. Esegua i due comandi qui sopra sul suo hostname.
  5. Raccolga le risposte in un documento condiviso, con la data. "In sviluppo" è una buona risposta se è messa per iscritto e una pessima se la si scopre al quarto mese.

Insista sulle domande che producono la dimostrazione di una schermata invece di una risposta. Quella reazione è raramente una manovra evasiva: di solito significa che nessuno l'aveva chiesto prima.

Dove si colloca Lurno

Le nostre risposte, comprese le parti non finite. I domini sono per organizzazione a qualsiasi profondità dell'albero e si configurano dalle impostazioni di quella stessa organizzazione: si digita l'hostname, si pubblicano i record DNS che la schermata mostra, si osserva lo stato finché il certificato non risulta attivo, poi lo si contrassegna come primario. Gli hostname passano da Cloudflare; il TLS viene emesso e rinnovato automaticamente. La pagina di accesso risolve logo, titolo, slogan, tema e sfondo dal solo hostname, prima che qualcuno si autentichi. Una volta che un dominio è primario, i link di invito di quell'organizzazione vengono costruiti su di esso.

Il brand è fatto di diciassette campi — quattordici token di colore, il font display, il font del testo, il raggio degli angoli — più un logo chiaro, un logo scuro, una favicon, un titolo e uno slogan. L'ereditarietà risponde alla domanda sulla granularità di poco fa: una sotto-organizzazione senza tema prende l'intero tema del padre, la coppia di logo si eredita come unità, così non si può lasciare un logo scuro appeso su uno sfondo chiaro, e titolo, slogan e favicon ricadono sul default campo per campo. La terminologia è rinominabile per ogni lingua, e le email di notifica partono dal sottodominio dell'organizzazione stessa. Il modello completo è nella pagina white-label; chi invia la posta è nell'elenco dei sub-responsabili nella pagina sicurezza.

Le lacune, dette chiaramente. Non ci sono app mobili native — Lurno è un'applicazione web responsive, quindi il mobile porta lo stesso brand di tutto il resto, ma non c'è un'app a suo nome in uno store, e le app native sono in roadmap, non rilasciate. Anche il single sign-on SAML e OIDC è in roadmap; quello che esiste oggi è l'accesso partner, in cui il suo backend consegna un'assertion firmata per un discente che ha già autenticato. I pagamenti e il checkout sono in sviluppo.

Il white-label non è una funzionalità che si attiva alla registrazione. È una proprietà di dove un fornitore ha tracciato i propri confini anni prima della sua telefonata, e quei confini si leggono nella barra degli indirizzi, nelle intestazioni delle email e nel codice sorgente di un tenant reale. Mezz'ora con un dominio vero risolve più voci di questo elenco di un pomeriggio di call — le nostre comprese, ed è a questo che serve una demo.