本文へスキップ
lurno
記事一覧
ブログ

ホワイトラベルのチェックリスト:ロゴをアップロードしたあと、ベンダーに尋ねること

ホワイトラベルはロゴのアップロードではありません。ドメイン、送信ドメイン、リセットリンク、継承、そしてページのソースが明かすものへの問い。

The Lurno teamAugmental1 分で読めます

ホワイトラベルが失敗するのは、誰もデモしない場所です。ロゴのアップロードは必ず動きます。クライアントの従業員が、ベンダーの名前に出会わないまま1年間そのプラットフォームを使えるかどうかを決めるのは、パスワードリセットのリンクの中にあるホスト、通知メールに署名したドメイン、ブラウザのタブに出る文字、そしてセッションがまだ存在しない朝8時に、誰かが何の前触れもなく開くログインページです。色の話をする前に、この四つを尋ねてください。

「ホワイトラベルに対応していますか」には、どのベンダーもはいと答えます。この言葉は、16 進数のカラーコードから、本当の意味で自分のものであるテナントまでを覆っており、どちらの答えも同じ自信ありげな調子で返ってきます。以下は商談用のチェックリストで、機能ではなく質問の形で書いてあります。機能の一覧ははいを誘い、質問は実演を誘うからです。

ロゴの先にあるホワイトラベルの意味

ホワイトラベル

自社の名前、ドメイン、デザインでプラットフォームを提供し、使う人が、誰がそれを作ったのかを知る理由を特に持たない状態にすること。テーマ設定はその一部です。ログイン済みのユーザーが見るページの色、フォント、ロゴ。ホワイトラベルは表面のすべてです — アドレスバー、メールのヘッダー、ログインページ、ブラウザのタブ、ページのソース。テーマ設定は設定作業ですが、ホワイトラベルの大半はアーキテクチャです。

役に立つ判定基準は、クライアントのロゴが出るかどうかではありません。普通の一週間のどこかの瞬間に — サインイン、パスワードのリセット、メールを開く、チケットにリンクを貼る — ベンダーの名前が現れるかどうかです。商談の場で、その一週間を声に出してたどってみてください。

Lurno

クライアントの従業員が、自社のドメインでサインインし、自社のドメインで署名されたメールを受け取り、自社の名前が入ったサポートのリンクを貼ります。

Not this

ロゴと 16 進数のカラーコードだけがあって、製品そのものは相変わらず yourcompany.vendor.com にあり、no-reply@vendor.com からメールを送っている、ということではありません。

ドメインと、そこから外へ出るセッションの部品

カスタムドメインが荷重を支える部分で、それ以外はその上に載る装飾です。五つの質問で、ほとんどのところまで行けます。

  • カスタムドメインは、見積もられているプランに含まれますか。それとも追加オプションですか。 明細の行を求めてください。ドメインはよくあるアップセルですし、古いプラットフォームでは、設定項目ではなくプロフェッショナルサービスの作業です。
  • TLS 証明書を発行するのは誰で、更新のときに何が起きますか。 自動発行と自動更新か、数か月ごとのチケットか。更新が失敗した朝、学習者に何が見えるのかを尋ねてください。
  • ドメインはアカウントに一つですか、組織ごとに一つですか。 クライアントのアカデミーやキャンパスを複数運営するなら、どの深さで別々のホスト名が使えなくなるのかを尋ねてください。
  • 自分たちで設定できますか。 良い答えは、自社のレジストラに入れるべき DNS レコードをそのまま表示する画面と、証明書の発行中の状態がその場で分かる表示です。まずい兆候は、サポート窓口とのメールのやり取りです。
  • セッションのどの部分が自社のドメインから外へ出ますか。 ダウンロード、動画、試験のプレイヤー、証明書の検証、埋め込みのヘルプウィジェット、サインオンの受け渡し。稼働中のテナントでネットワークタブを開き、ホスト名を読み上げてもらってください。

カスタムドメインを使っていても、学習者がベンダーのドメインを目にすることはありますか

たいていはどこかにあります。問題はどこか、です。よくある漏れは、サインイン中のリダイレクト、共有 CDN から配信されるメディア、証明書の検証リンクが解決する先のページ、そして埋め込みのチャットウィジェットです。どれもプラットフォームの作りから来るもので、どれも学習者から見えます。名指しで尋ねてください。

メールと、仮面がずれるリンク

メールは、ホワイトラベルのうち、静かにベンダー側に残り続ける半分です。From アドレスは表示用の文字列で、誰でも設定できます。メールソフトがその下で読んでいるのは、実際にメッセージに署名したドメインです。

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

署名したドメインが From のドメインと一致しないとき、Gmail は送信者の横に小さく「via vendor-lms.com」と表示します。クライアントの情報システム部門は、それが何を意味するか知っています。だから、こう尋ねてください。

  • どのメッセージが自社のドメインから送られ、どれが御社から送られますか。 全部の一覧を求めてください — 招待、ようこそ、パスワードリセット、受講登録、リマインダー、成績の公開、証明書の発行、ダイジェスト、管理者向けの通知 — そのうえで、どれが自社の送信者を名乗れるのかを。
  • From の行だけですか、署名するドメインもですか。 続けて尋ねるのは、どの DNS レコードを自分たちが公開するのか、です。自社のレジストラに何も入れないのであれば、そのメールは本当の意味で自社のドメインから出てはいません。
  • 自社の送信アカウントとキーですか、それとも御社の共有プールですか。 共有プールでは、別のテナントのバウンス率が、見えないところで自社の到達率の問題になります。
  • 組織ごとですか、それとも最上位で一度だけですか。 アカウント全体で送信者が一つなら、最初のメールで独立性は崩れます。
  • メールはどのロゴを使い、それはどこでホストされていますか。 ベンダーがホストしている画像は、メールのゲートウェイが外部画像をブロックするたびに、代替テキストの位置にその URL を晒します。

次に、メッセージの中のリンク。多くの評価が真相を知るのはここです。本文には自社のロゴ、色、送信者を載せられますが、その真ん中にあるボタンは、依然としてベンダーのホストを指していることがあります — 招待とリセットのリンクは、たいてい認証の層が発行するもので、一つのサイト URL を使って、全体に対して一度だけ設定されているからです。

パスワードリセットと招待のメールは、自社のドメインを使いますか

他の部分のブランディングがうまくできているプラットフォームでも、使わないことがよくあります。仮面がずれる場所としては、これがいちばん多いのです。これらのリンクは、たいてい全体で一つ設定されたサイト URL から生成されるため、メッセージは完全に自社のものに見えるのに、中のリンクはベンダーのホストに解決される、ということが起こります。この項目は尋ねないでください — 試してください。リンクの飛び先とヘッダーを、自分の目で読んでください。

ログインページ、タブ、そして二つのロゴ

ログインページは、ブランディングがいちばん難しいページであり、すべての学習者が最初に見るページです。誰かが認証を通るまで、プラットフォームが訪問者について知っているのは、どのホスト名で来たかということだけです。ブランディングをログイン済みユーザーの組織から読み込む作りなら、いきなり訪れた人にはベンダーの既定が出ます。この言葉のまま尋ねてください。ブランディングは、セッションが存在する前に、ホスト名だけから解決されますか。

  • セッションを持たない訪問者に対して、自社のドメインでは何が描画されますか。 ロゴ、製品名、色、背景、サインインボタンの文言。
  • 「powered by」の行はありますか。それを消すには何が要りますか。 切り替えスイッチか、上位プランか、契約の条項か。三つとも実在し、それぞれ値段が違います。
  • エラー時の表示はどうなりますか。 パスワードの誤り、期限切れの招待、ロックされたアカウント — ベンダーの既定テンプレートである可能性がもっとも高いページであり、苛立ったユーザーがもっとも注意深く読むページです。
  • ブラウザのタブには何が入りますか。 すべての画面のページタイトルと、ファビコン。ファビコンは組織ごとなのか、プラットフォーム全体で一つのファイルなのかを尋ねてください。単一の静的パスから配信するのは、よくある手抜きです。
  • ロゴは二つありますか。 ライトモード用のロゴ、ダークモード用のロゴ、たいていは正方形のマークも。片方だけをアップロードした状態でユーザーがダークモードに切り替えたら何が起きるのかを尋ねてください。
  • プラットフォームの外へ出る文書には何が入りますか。 証明書の PDF、エクスポートしたレポート、成績証明書。フッターを確認し、それからファイルのメタデータを確認してください。ベンダー名がいちばん長く生き残る場所です。

継承と、その粒度

組織を複数運営しているなら — クライアント企業、グループ内の学校、国ごとの子会社 — 「ブランディングは継承されますか」は、はいかいいえの問いではなく、粒度の問いです。そして手間が消えるか何倍にもなるかは、その粒度で決まります。

  • 子組織が何も設定しなかった場合、何が適用されますか。 親のブランドか、ベンダーの既定か。グループにとって後者は誤りです。新しい学校はどれも、ベンダーの見た目で生まれることになります。
  • 全部か無かですか、それとも項目ごとですか。 グループの配色と自校の校章を使いたい学校には、項目単位のフォールバックが要ります。ひとかたまりでの継承では、ロゴを一つ変えるために、どの子組織も 14 の色を書き直すことになります。
  • ライトとダークのロゴは、対としてフォールバックしますか。 それぞれ独立にフォールバックする作りだと、ライトのロゴだけをアップロードした子組織は、新しい配色の上に親のダークのロゴを取り残すことになります。小さな質問ですが、示唆に富む沈黙を生みます。
  • 変更できるのは誰ですか。 子組織自身の管理者か、それともすべての変更が自社の中央チームを通るのか。後者は、1年後もまだ回し続けているサポートの待ち行列です。
  • どこまで深く行けますか。 2階層はよくある答えです。キャンパスを持つ学校を抱えた出版社には、それ以上が必要です。
  • 継承されるのはデザインだけですか、用語もですか。 「student」を「trainee」に改名できるなら、それが下へ継承されるのか、言語ごとに別々に設定するのかを尋ねてください。

サブ組織ごとに独自のブランディングとドメインを持てますか。それとも最上位のアカウントだけですか

この項目は、この一覧の中でもっともばらつきが大きく、マルチテナントのプラットフォームと、テーマを当てただけのシングルテナントのプラットフォームを分けます。多くの製品はアカウント単位でブランディングし、子アカウントには親のブランドを絞り込んだビューを与えます — 部門にはそれで十分ですが、クライアントには誤りです。子組織が独自のホスト名、証明書、ロゴの対、配色、送信者を持てるのか、そしてそれがどの深さで止まるのかを尋ねてください。

自分で走らせるテスト

モバイルでの体験

まず、売られているのがどちらなのかをはっきりさせてください。「モバイルに対応しています」は、ブランディングの事情が異なる二つの製品を覆っているからです。ネイティブアプリなら、問いは見た目ではなく商業上のものになります。ストアの掲載名は誰の名前ですか。開発者アカウントを所有しているのは誰で、リリースを提出するのは誰ですか。クライアントごとに別のビルドがあり、それに伴う別の審査サイクルがありますか。

レスポンシブなウェブアプリケーションなら、ブランディングはデスクトップのサイトと同じコードの経路を通ります。この場面では、たいていそちらのほうが良い答えです。自社のドメインで、スマートフォンの幅で見せてもらってください。そのうえで、学習者がホーム画面に追加したときに、どんな名前とアイコンが出るのかを尋ねてください。

ページのソース

いつか誰かがソースを表示します。クライアントの情報システム部門、好奇心のある学習者。何かを隠したいわけではありません。そのプラットフォームが、他社の名前で提供されることを前提に作られているかどうかを確かめているのです。二つのコマンドで、ほとんどのことが分かります。

# 自社のドメインで提供されている証明書には、誰の名前が入っているか
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'

# HTML とレスポンスヘッダーは何と言っているか
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'

面白いのは証明書の確認です。顧客のホスト名ごとに証明書を発行するプラットフォームもあれば、多数の顧客を一つのマルチネーム証明書に載せるプラットフォームもあります。クライアントのドメインの代替名の一覧に他の顧客が並んでいるなら、それは、そのベンダーが他に誰にサービスを提供しているかについての公開情報であり、セキュリティ審査はそれを見つけます。

HTML では、ページタイトル、`og:site_name` タグ、ウェブマニフェスト、スクリプトと画像の読み込み元のホスト名、そして content security policy ヘッダーに書かれた解析とエラー報告のエンドポイントを読んでください。このエンドポイントがもっともよくある手がかりです。誰もそれをブランディングだと思っていないからです。

商談の進め方

  1. 録画されたデモではなく、自社が管理するドメイン上の、稼働中のテナントを求めてください。1日分の DNS 作業は、1年分の契約より安いテストです。
  2. 自社が管理するアドレス宛てに、本物の招待と本物のパスワードリセットを送ってもらってください。リンクの飛び先とヘッダーを読んでください。
  3. ログインページを、何の前提もない状態で、プライベートウィンドウで、ダークモードで、スマートフォンで開いてください。
  4. 上の二つのコマンドを、自社のホスト名に対して実行してください。
  5. 答えを、日付を入れて共有ドキュメントに集めてください。「開発中」は、書き留められていれば良い答えですが、4か月目に発覚するとまずい答えです。

答えの代わりに画面の実演が返ってくる質問を、突き詰めてください。その反応は、はぐらかしであることはめったにありません。たいていは、これまで誰も尋ねなかったという意味です。

Lurno の立ち位置

私たち自身の答えを、できていない部分も含めて書きます。ドメインはツリーの任意の深さで組織ごとに持て、その組織自身の設定画面から用意します。ホスト名を入力し、画面が示す DNS レコードを公開し、証明書が有効になるまで状態を見守り、それを主ドメインに指定する。ホスト名は Cloudflare を通ります。TLS は自動で発行され、自動で更新されます。ログインページは、誰かが認証を通る前に、ホスト名だけからロゴ、タイトル、スローガン、テーマ、背景を解決します。あるドメインが主ドメインになれば、その組織の招待リンクはその上に作られます。

ブランディングは 17 の項目です — 14 のカラートークン、見出しのフォント、本文のフォント、角の丸み — これにライトのロゴ、ダークのロゴ、ファビコン、タイトル、スローガンが加わります。継承は、上の粒度の問いにこう答えます。テーマを持たないサブ組織は親のテーマを丸ごと引き継ぎ、ロゴの対は一つの単位として継承されるので、ダークのロゴを明るい背景の上に取り残すことはできず、タイトル、スローガン、ファビコンは項目ごとにフォールバックします。用語は言語ごとに改名でき、通知メールはその組織自身のサブドメインから送信されます。モデルの全体はホワイトラベルのページに、誰がメールを送るのかはセキュリティのサブプロセッサ一覧にあります。

足りない部分を率直に書きます。ネイティブのモバイルアプリはありません — Lurno はレスポンシブなウェブアプリケーションなので、モバイルでも他と同じブランディングが適用されますが、自社の名前でストアに並ぶアプリはなく、ネイティブアプリは提供済みではなくロードマップ上にあります。SAML と OIDC のシングルサインオンもロードマップです。現在あるのはパートナーサインオンで、自社のバックエンドが、すでに認証済みの学習者について署名済みのアサーションを引き渡す方式です。決済とチェックアウトは開発中です。

ホワイトラベルは、契約時にスイッチを入れる機能ではありません。ベンダーが、あなたが連絡するより何年も前に、どこへ境界を引いたかという性質です。そしてその境界は、稼働中のテナントのアドレスバー、メールのヘッダー、ページのソースから読み取れます。本物のドメインを使った30分は、午後いっぱいの商談よりも、この一覧の多くを片づけます — 私たちとの商談も含めてです。デモはそのためにあります。