問い合わせ用に用意したSlackワークフローで問い合わせのフィードバックも得られるようにしてみた

質問や相談用の窓口としてフォーム等を用意していると、受け付ける側で色々と知りたい事がでてきます。

• フォームの呼び出し方法はわかりやすいか
• フォームは書きやすいか

更に、特定ドメインに関する質問となる場合は以下のような要素もでてきます。

• 仕様確認は困難か

これらを解決するため、窓口用Slackチャンネルのワークフローでフィードバックプロセスを実際に試み、分かったことについて書いてみました。

今回設けたワークフロー構成

今回は、都合により既に設けていた問い合わせフォームに関するフィードバック手続きを追加しました。具体的には、フォームからチャンネルへポストされると同時に、問い合わせを行ったスタッフにSlackBotから個別通知を送信するようにしています。

元々は、問い合わせ解決後に表示される満足度フォームのようなものを想定していました。しかし、ワークフローの標準ステップでは問い合わせ解決後にフィードバックへの導線実現が難しいことが分かりました。そのため、問い合わせそのものに対するフィードバックへと切り替えることにしました。

ワークフロー構成を標準ステップに限定した理由としては、今後のCanvas機能アップデートを見越してのものです。カスタマイズしたステップを追加すれば融通が利くことは分かっていますが、作り込むのは尚早だと判断しました。

Slackワークフロー標準ステップで可能・不可能なこと

Slackワークフローのフォームを使った投稿は、ワークフロー完了までURLが確定しません。そして、ワークフローの標準ステップでは、ワークフロー完了後はワークフロー実行ユーザを取得できない仕組みとなっています。

つまり、標準ステップの組み合わせだけでは、問い合わせスレッドのURLを特定する場合は問い合わせ主を特定できず、問い合わせ主を特定する場合はURLを特定できないことになります。問い合わせ終了後に問い合わせ主へ該当スレッドへのフィードバックを求めたい場合には頭を抱えるポイントです。

フィードバックと問い合わせと直接結び付けない

フィードバックと、起因させた問い合わせの自動紐づけは見送りました。これは標準ステップでの制約に絡むものです。

フィードバックに用いたGoogle Formはクエリ経由で固定値を渡すことができます。ただ、Slackの標準ステップのメッセージ投稿内では、固定値のURLに変数扱いのフォームパラメータを引数として渡すことができません。それぞれURLと変数で個別の扱いとなるためです。ただ、フィードバックのタイミングから、ある程度起因した問い合わせは絞り込めます。

では何をフィードバックしてもらうかというと、問い合わせ手続きそのものです。問い合わせに必要な操作、特定のドメイン知識確認手段が主になります。これらに不満がある場合はそれらの導線や内容の改善が課題と言えます。

あとがき

年内に、Canvas機能内からワークフローを呼び出せるアップデートが予定されています。これにより、導線に再考の余地が生じ、フィードバックも変化する可能性があります。現在は過渡期であり、大きな手戻りが生じない範囲で改善を進めたいと考えています。