Poth Labs

Poth Labsは、自ら顧客ブレインと呼ぶものを作る。フィードバック、会話、アカウントデータを一つの場所に統合した検索可能な層だ。インポートされた通話・チケット・行はそれぞれ属する顧客に紐づけられ、これが後の問い合わせを信頼できるものにする。この対応づけがなければ、答えは集団についてのありそうな推測にすぎない。あれば、すべての主張が特定のアカウントを指せる。違いはそこにある。

答えは一続きの文章として届かない。Pothは優先度付きのインサイトを返し、それぞれに背後の根拠と根本原因の仮説が組み合わされる。この構造は、自信ありげな要約に痛い目を見てきたチームにとって重要だ。行動する前に、どのアカウントが主張を支え、どれが反証しているかを確認できる。弱いインサイトは弱く見える。結びついた根拠がたいていそれを明らかにする。

質問がつないだデータで答えられる範囲を超えるとき、Pothは結論をでっち上げない。決着をつけられる顧客に向けた質問を起草し、各回答は同じアカウントに戻って保管される。これで、一度きりの働きかけが、孤立したアンケートではなく、育つ根拠の集まりになる。ノイズは減り、シグナルは増える。名簿全員に質問票をばらまくのとは、まったく別のモデルだ。

ソースはガイド付きの設定でつなぎ、選んだアカウント、権限範囲、設定だけを認可する。ファイルは範囲を限ったバッチでインポートでき、始めるのにデータウェアハウス全体を引き渡す必要はない。この線引きは重要だ。コンプライアンス審査があるチームでは、試験導入と却下の分かれ目になることが多い。アクセスは明示的に承認した範囲にとどまる。

Pothは、すべてを一つの結論に畳むのではなく、競合する説明が現れるそばから見せる。デモでは、チャットが進むにつれて仮説が形成される様子がわかる。これは実際のリサーチの進み方を映している。混沌とした顧客の問題に、きれいな単一の原因が得られることはほとんどない。選択肢を並べて見ることで、どれを検証に回すべきかを決めやすくなる。それが役に立つ部分だ。

すべての回答は、あるアカウント上の根拠として戻り、次の質問に備える。この追跡可能性は、発見が、それが生まれた顧客から切り離されてスライド資料の中に生き続けることを防ぐ。戻って誰が何を言ったかを見て、次の質問をその上に組み立てられる。なぜ重要か。次の質問こそ、問題を実際に説明するものになることが多いからだ。複数のデータツールを掛け持ちするチームにとって、二重作業を最も減らす機能がこれだ。