MoTLab -Mobility Technologies Engineering Blog-MoTLab -Mobility Technologies Engineering Blog-

汎用お問い合わせ機能ライブラリをつくることでサポートコスト削減してみた

行灯Labo
December 06, 2019

💁🏻
※本記事は Mobility Technologies の前身である JapanTaxi 時代に公開していたもので、記事中での会社やサービスに関する記述は公開当時のものです。
An image from Notion

はじめに

JapanTaxi のサポート部門では、より良いユーザー体験の実現を目指して、配車サービスにおける様々なトラブルをタクシー会社様と連携しながら解決しています。

この記事では、サポート部門とタクシー会社様で連携する業務をどのように技術的に改善してきたかを紹介します。

従来までのお問い合わせの流れと課題

弊社サービスについての様々なお問い合わせは、メールや電話などを通してサポート部門かタクシー会社様に連絡が入ります。それらのお問い合わせの中でも特に二者の連携が必要になるのは、タクシー会社様による対応が困難なもの(システムエラーや想定外の業務に関するもの)です。 今まではそのための窓口が、電話やメール、コーポレートサイトのフォーム経由など別個に管理されており、サポート部門の対応に大きな手間が生じていました。

技術的解決を考えてみる

JapanTaxi では配車や決済といったサービスを提供していますが、今回の問題を解決するために、その管理画面にお問い合わせ窓口を設置することにしました。また、元々サポート部門ではチケット駆動管理の Zendesk ( https://www.zendesk.co.jp/ ) を導入しているため、この API を利用することでお問い合わせ内容の一元管理が可能になります。

管理画面からZendeskのサービスを通して、カスタマーサポートへお問い合わせを届け、散り散りになっていた連絡系統を一つにまとめる様に考えました。

これを踏まえると技術的には以下のような要件になります。

  • タクシー会社様へ提供している管理画面に様々な業務に対応できるお問い合わせ機能を設置できるようにする。
  • サポート部門が利用しているZendeskにZendesk APIを用いてお問い合わせ内容を起票できるようにする
  • 各管理画面にサードパーティ依存のコードが散らばらないように、Zendesk API が薄くラップされたライブラリを設けることで、将来のツール変更にも強い設計を実現する。
  • 作成するライブラリのモデル(お問い合わせ内容)は汎用的な項目を管理できるようにして、ライブラリ利用者のドメインに合わせてカスタムできる余地を残す

これらをどのように実現したかを説明していきます。

汎用的なお問い合わせ管理用のライブラリを設計してみる

チケットの型を提供する

まずAPIのモデルを用意します。基底となるチケットモデルを提供し、どのようなものを送るのかを定義します。チケットモデルにはお問い合せ依頼者、タイトルと本文を用意します。これが最低限のチケットの型を表現することになります。

APIクライアントを用意する

APIクライアントには、実際に送信させるgetメソッドやpostメソッド等を用意します。あらかじめAPI送信に関わる情報(エンドポイントや認証周り等)をSettingsクラスの中に用意させ、APIクライアント内で使用するようにしました。このようにラップすることでライブラリ利用者はZendeskの事情を知らずともチケットを作成できるようになります。

チケット作成用のクラスを提供する

ライブラリ利用者は、自身のサービスにチケット型のサブクラスを定義し、チケット作成クラスを通してお問い合わせを送ることが可能となります。

具体的なクラス図の例

An image from Notion

おわりに

サポート部門が抱えるコスト削減を図ることが出来ました。

  • タクシー会社様からのお問い合わせ先の窓口を一元化
  • 将来のツール変更にも強い汎用的なクラス設計

これからもより良いサービスを迅速に提供出来るよう努めていきます!

💁🏻
※本記事は Mobility Technologies の前身である JapanTaxi 時代に公開していたもので、記事中での会社やサービスに関する記述は公開当時のものです。

Mobility Technologies では共に日本のモビリティを進化させていくエンジニアを募集しています。話を聞いてみたいという方は、是非 募集ページ からご相談ください!