Tesuji日程調整サービスは、機能一覧だけでは差が見えにくい
日程調整サービスを説明すると、どうしても似た言葉が並びます。
- 候補日時を出せる
- 相手が選べる
- カレンダーと連携できる
- 複数人で調整できる
この説明だけだと、利用者から見ると「結局どれも同じ」に見えます。
ApoMentをTesuji上で扱う意味は、機能を増やして見せることではなく、どんな仕事の途中で必要になるサービスなのかを関係として見せることです。
サービスは単体で使われない
実際の仕事では、日程調整の前後に別の作業があります。
たとえば商談なら、
相談 → 相手選定 → 候補整理 → 日程調整 → Calendar確定 → 会議準備 → 会議 → フォロー
という流れです。
この中でApoMentが担当するのは、主に
候補整理 → 合意形成 → 確定
の部分です。
つまりApoMentの価値は、単体画面の便利さだけでなく、前後のサービスへ自然につながることで決まります。
Tesujiでは「何と組み合わせるか」がコンテンツになる
たとえば次の関係を作れます。
ApoMent × ChatGPT
曖昧な会話から、所要時間・希望曜日・除外条件を整理する。
ApoMent × Google Calendar
実際の予定と重複しない候補だけを出し、確定後に予定へ反映する。
ApoMent × Slack
社内で「この3候補ならどれが良い？」と共有し、外部調整前に内部都合をまとめる。
ApoMent × Tesuji
これらの使い方を単なるリンクではなく、関係グラフと記事で説明する。
この構造なら、ApoMentを知らない人でも「ChatGPTで日程調整したい」「Google Calendarと組み合わせたい」という別の入口から見つけられます。
機能ページではなく「ユースケースページ」が増える
普通のサービスサイトでは、1サービスにつき数ページしか作れません。
- トップ
- 機能
- 料金
- FAQ
一方Tesujiでは、関係を軸にするとコンテンツの単位が変わります。
たとえばApoMentだけでも、
- ApoMent × ChatGPT：曖昧な予定条件を整理する
- ApoMent × Google Calendar：空き時間を実予定と照合する
- ApoMent × Slack：社内候補を先にまとめる
- ApoMent × 竹村也哉：実際の使い方を説明する
- ApoMent × CaseFlow：日程調整上の問い合わせを改善へ回す
のように、利用文脈ごとのページが作れます。
これは単なるSEO量産ではありません。
各ページが別の「仕事の入口」を持つことになります。
Tesuji側で持つべき関係の粒度
ただし、何でも線でつなぐと意味が薄くなります。
ApoMentから見て価値のある関係は、最低でも次のどれかに当てはまるべきです。
- 前工程を担当する
- 後工程を担当する
- データを渡す
- 状態を同期する
- 利用者が同じ
- 実際のユースケースで組み合わせる
たとえば「ApoMentとBlender」は、関係を作れないわけではありませんが、通常の利用文脈では弱い。
一方「ApoMentとGoogle Calendar」は、予定データという明確な接点があります。
関係の数より、関係の理由が説明できることの方が重要です。
1本の記事で説明すべきこと
Tesuji上の記事は、単に「AとBは相性が良いです」で終わると弱いです。
最低でも、
- どんな課題があるか
- Aは何を担当するか
- Bは何を担当するか
- データや状態はどう流れるか
- どんな場面なら使う価値があるか
- 逆に、どんな場面では過剰か
- 実際に試す最小手順
まで書くと、読んだ人が使い方を想像できます。
例：社外3人との打ち合わせ
たとえば、社外2人を含む3人で60分の打ち合わせを決めるとします。
- ChatGPTで条件を整理
- Google Calendarで自分側の重複を除外
- ApoMentで候補を3つ提示
- 相手が回答
- 確定日時をCalendarへ反映
- Slackへ確定通知
この流れを書けば、ApoMentは「日程調整サービス」ではなく、仕事を前へ進める合意レイヤーとして見えてきます。
Tesujiにとっても重要な理由
Tesujiが単なるサービス一覧なら、検索サイトと差がありません。
価値が出るのは、
- 何と何を組み合わせるか
- その組み合わせで何ができるか
- どの順番で使うか
- 誰が実際に使っているか
が分かるときです。
ApoMentのような具体的なサービスは、その構造を見せる良い例になります。
KPIは「記事数」だけではない
Tesuji上でApoMentのコンテンツを増やすなら、単にページ数を見るより、
- 1記事あたりの関連ノード数
- 記事からApoMentノードへの遷移率
- ApoMentノードから他サービスへの遷移率
- どの組み合わせ記事から流入したか
- 同じ人が複数ノードをたどった割合
を見る方がTesujiらしいです。
これは普通のブログPVとは違います。
「読まれたか」だけでなく、「関係をたどられたか」を見るわけです。
次の一手
ApoMentについて、まず5つの実利用シーンを決めます。
例：
- 社外商談
- 3人以上の社内会議
- 曖昧な「この3日なら大丈夫」調整
- Calendar重複回避
- AIアシスタントからの日程確定
その5つを、それぞれ関係ノードと結びつけて記事化する。
これを続けると、ApoMentは「日程調整カテゴリの1サービス」ではなく、複数の仕事の流れから発見されるノードになります。