Concept |
Enterprise Web2.0 |
Enterprise オープンソース |
「JIRO」と従来のシステムとの違い |
Function |
3分でWeb2.0で情報共有が可能に |
メーラー形式UIによるROI向上 |
ESP(全文検索機能) |
URI/RSS/XMLによる情報一元管理 |
Demo |
3分で作るWeb2.0情報共有アプリ |
開発フレームワークの技術解説 |
Application |
お客様情報管理 |
社内メール情報の共有化 |
クレーム管理 |
商品情報統合情報 |
マニュアルのデジタル化 |
プロジェクト内の情報共有 |
基幹データの参照 |
Framework |
開発フレームワークとして |
「タグ付きデータモデル」について |
開発フレームワーク適用例 |
Document |
ドキュメント |
Service |
弊社のサービス内容 |
動作・利用環境 |
FAQ |
お問い合わせ |
Company |
開発blog |
会社概要 |
クレームは、起こった現象そのものよりも、対応方法の「まずさ」が引き金となり大きくなってしまいます。「まずい」対応となってしまう理由の一つは、クレーム対応のプロではないにもかかわらず、個人の対応に任せたりすることに原因があります。
クレーム対応に必要な知識を持たないのに、日々忙しい業務の中でクレームが割り込んで入ってくれば、拙い対応になってしまうのも無理はありません。また、クレームはたまたま表面に出て来たもので、その背後に同様の不満を感じている人が一定の割合いるケースも少なからずあります。
その人達は無言のまま去っていきます。ある学者の説によれば、1年後には50%の顧客が去っていくと言われています。例えば一つのクレームを契機に「同様のクレームが起こっていないかどうか、既存のお客様に確認する」というようなフォローが考えられますが、そうした情報に活用されれば、本来得られたであろう利益を失うことなく、確実にプラスにつなげることができます。
クレーム対応は、個人任せではなく組織として対応することが必要です。そうした体制をつくり運用を定着させるためには、システム導入することにより、システムに合わせた仕事の仕組み(ワークフロー)に変える必要があります。
「JIRO」なら、まずはクレーム情報とその対応を全社員で共有することから始められます。最初は個々人の判断による対応だったものが、情報が蓄積され共有されることにより、自然にルールらしきものが形成され、ボトムアップの形で対応スキームが出来上がるようになります。こうなれば、マネジメント側から後押しする形で最適な対応マニュアル作りに向かって進むことができ、必要に応じて機能追加や修正などを行うことができるようになります。