仕組みづくり
自分のブランドで顧客にアプリを渡すとき、独自ドメインは必要?作業の入口と公開ページのURLを分ける表
公開
約7分で読めます
しろくま先生

独自ドメインは顧客にアプリを渡す必須条件ではありません。顧客がログインして作業するURLは変わらず、独自ドメインが働くのは公開ページの側。屋号・色の表示とURLを分け、要るかを決める三つの問いにまとめます。
自分のブランドで顧客にアプリを渡そうとすると、「ドメインも自分のものを用意しないと、ちゃんとしたサービスに見えないのでは」と手が止まることがあります。ドメインを取って、DNS を設定して……と考えるだけで、渡す前の準備が一つ増えたように感じます。
同じ説明を顧客ごとに繰り返す、作業のたびに自分が手を動かす。そうした個別対応を減らすために、自分のやり方を入れたアプリを顧客に渡し、顧客が自分で作業できる場所として残しておく。その準備の途中で出てくるのが、このドメインの問いです。
先に答えを書きます。独自ドメインは、顧客にアプリを渡すための必須条件ではありません。 そして saas biz の現行の仕組みでは、独自ドメインを設定しても、顧客がログインして作業する画面の URL は変わりません。独自ドメインが使われるのは、見込み客や読者に見せる「公開ページ」の側です。
この記事では、「屋号・ロゴ・色の表示」と「URL」を分けて考え、さらに URL を「顧客が作業する入口」と「読者に見せる公開ページ」に分けます。最後に、自分に独自ドメインが要るかを決めるための確認点を置きます。
「自分のブランド」は一つの設定ではない
自分のブランドで届ける、と言うとき、実際には別々のものがいくつも混ざっています。商品の名前、契約の中身、顧客との関係、そしてロゴ・色・ドメイン。どれも「あなたのもの」として扱えますが、決める場所も、決める時期も同じではありません。
ここで混ざりやすいのが、次の二つです。
ブランドの見た目: 屋号(ブランド名)と色。顧客がアプリを使うときに目に入るもの
URL: 顧客や読者が、どの住所でページを開くか
saas biz のブランド設定の画面では、この二つは別の欄です。ブランド名・ロゴ・色は「編集」で整え、独自ドメインは「独自ドメイン (カスタムドメイン)」の欄で登録します。そして画面の「クライアントに渡すURL」の説明には、顧客がログインするとブランド名・色があなたのパートナーブランドで表示される、と書かれています。
つまり、ブランド名と色を整えるのに、独自ドメインは要りません。 ログイン後の画面にあなたのブランドを出すことと、URL を自分のドメインにすることは、別の作業です。
なお、ログインする前の画面にどこまであなたのブランドが出るかは、この記事では確かめていません。顧客に渡す前に、実際にログイン画面を開いて自分の目で見ておくのが確実です。
URL は「作業する入口」と「見せる公開ページ」に分かれる
URL の話も、一つにまとめると判断を誤ります。顧客や読者が開くページは、大きく二種類あります。
顧客がログインして作業する画面: 発信の下書きを作る、LP を編集する、配信を設定する、といった管理の画面
ログインせずに誰でも見られる公開ページ: 申込を受ける LP や、公開した記事など、見込み客や読者に見せるページ
現行の仕組みでは、独自ドメインが働くのは 2 の公開ページだけです。独自ドメインの住所でログインの画面や管理の画面を開こうとしても、既定のログイン用の住所へ案内し直される作りになっています。ログインした状態を出す画面は、既定の住所だけで出す、という線引きです。
この線引きのおかげで、顧客に渡す「作業の入口」は、独自ドメインの有無に関係なく一つに決まります。あとから独自ドメインを足しても、顧客に「ログインの URL が変わりました」と連絡し直す必要はありません。
何を変えて、どこで確かめるか
ここまでを、変えたいもの・対象の画面・確かめる URL の三つに並べると次のとおりです。
何を変えたいか | 対象の画面 | 確かめる URL |
|---|---|---|
屋号(ブランド名)と色 | 顧客がログインした後のアプリの画面 | URL は変わらない。ブランド設定の「編集」で整え、顧客と同じ URL でログインして表示を見る |
顧客が作業する入口 | ログインの画面と管理の画面 | ブランド設定の「クライアントに渡すURL」に出る既定の URL。独自ドメインを設定しても、この URL のまま |
申込を受ける LP の住所 | Funnels の公開 LP( | 独自ドメインが「検証済み」なら、その住所。無ければ既定の公開ドメイン。どちらになっているかは、LP を公開するときに表示される公開 URL で確かめる |
公開記事の住所 | WRITS の公開記事( | 独自ドメインの住所でも出してよいページに入っている。ただし記事ごとの URL がどちらで案内されるかは、ここでは約束しない。公開した記事を実際に開いて確かめる |
独自ドメインが関わるのは下の二行(公開ページ)だけで、上の二行は独自ドメインの有無で変わらない
公開ページの例として挙げたのは、Funnels の公開 LP と WRITS の公開記事の二つだけです。ほかのアプリの公開ページについては、この表に入れていません。
公開ページを自分の住所で見せたいときだけ確かめること
独自ドメインを使う理由があるとすれば、見込み客や読者に見せる公開ページを、自分の住所で出したいときです。たとえば、名刺やプロフィールに載せる申込ページの URL を、自分の屋号のドメインにそろえたい場合です。
その場合は、ブランド設定の「独自ドメイン (カスタムドメイン)」の欄で、自分で取得したドメインを登録します。登録すると、設定する DNS の内容が画面に出ます。DNS を設定したら「状態を更新」で、アプリ別の状態を確かめます。状態は「検証済み」「DNS 反映待ち」「エラー」のどれかで表示されます。
ここで確かめるのは次の三つです。
アプリ別の状態が「検証済み」になっているか
LP を公開するときに表示される公開 URL が、自分のドメインの住所になっているか
その公開 URL を、ログインしていないブラウザで開けるか
DNS の反映にかかる時間は環境によって違うので、ここでは目安を書きません。Funnels の公開 LP では、独自ドメインが「検証済み」になっていなければ、既定の公開ドメインの URL が選ばれます。WRITS の公開記事については、同じ動きをここでは確かめていません。公開ページの住所が決まるまで、顧客への案内を止める必要はありません。
逆に、公開ページを自分の住所で見せる予定がないなら、独自ドメインは後回しで構いません。すべてを最初にそろえる必要はなく、今の仕事に必要なものから置いていけば足ります。
顧客へ渡す前に、二つの URL を別々に控える
顧客にアプリを渡すときは、URL を一つにまとめず、用途ごとに分けて控えておくと案内がぶれません。
顧客が作業する URL: ブランド設定の「クライアントに渡すURL」に出るもの。顧客に「ここからログインしてください」と渡す
見込み客・読者に見せる URL: 公開した LP や記事の URL。名刺、プロフィール、SNS などに載せる
案内文も、この二つを混ぜないようにします。たとえば「作業はこちらの URL からログインしてください」と「申込ページはこちらです」を別の行に書く、という程度で十分です。顧客が作業の入口を探して公開ページを開いてしまう、あるいはその逆、という行き違いを防げます。
なお、自分の事業でアプリを使うだけで、顧客にはまだ渡さないなら、顧客向けの URL を用意する必要はありません。顧客への提供は、必要になったときに選べる別の使い方です。
まとめ:独自ドメインが要るかを決める三つの問い
最後に、判断の材料を三つの問いにまとめます。
顧客がログインした後の画面に、自分の屋号と色を出したいか → 独自ドメインは不要。ブランド設定の「編集」で整える
顧客に渡すログインの URL を、自分のドメインにしたいか → 現行の仕組みでは、独自ドメインを設定しても変わらない。既定の「クライアントに渡すURL」を渡す
申込ページや公開記事を、自分のドメインの住所で見せたいか → このときだけ独自ドメインを登録し、「検証済み」と公開 URL を確かめる
「自分のブランドで届ける」ことと「自分のドメインを持つ」ことは、同じではありません。屋号と色、作業の入口、公開ページの住所を分けて考えると、今やることと後でいいことが見えてきます。
自作・紹介・ホワイトラベルという届け方そのものの違いは、ホワイトラベルSaaSとは|自作・紹介との違いと個人事業主の選び方で整理しています。顧客に渡した後の問い合わせを誰が受けるかは、顧客に渡したアプリの問い合わせは誰が受ける?を参照してください。
自分のブランドで顧客にアプリを届ける仕組みと条件は、こちらにまとめています。



