タグ

2014年12月19日のブックマーク (7件)

  • チャットサポートを成功させる6つの秘訣

    顧客とチャットでやりとりをする場合、電話やメール、あるいは対面による応対と同様に事が運ばないことがあります。文字の短いメッセージは様々な解釈ができるため、意図したとおりに伝わらないことが出てくるかもしれません。だからといって、長々と時間をかけて慎重に一語一句、熟考して入力する必要はありません。この記事では、顧客に満足してもらえる体験を提供するための、チャットサポート時のマナーについて解説します。 チャットサポートのマナー: 6つの秘訣仕事のプロ意識を持って対応する 過度な期待を抱かせない 顧客個人に寄り添い傾聴する 状況を伝える 必要に応じて助けを求める 共感を示す 1.仕事のプロ意識を持って対応するカスタマーサービスのプロとして相応しく好印象を与える文章の書き方に徹する必要があります。 正しい日語の文法と漢字を使う。 インターネットでよく目にしていても、略語は使用しない。 冗談は書かな

    チャットサポートを成功させる6つの秘訣
  • Zendesk help

  • 日本IBMが"誰でも"Watson使えるクラウドサービス、無償版も用意

    IBMは2014年12月18日、同社の質問応答システム「Watson」を使ってデータを分析できるクラウド型サービス「Watson Analytics」の正式版の提供を開始すると発表した。利用者は分析したいデータをWebブラウザを通じてアップロードし、テキスト形式で質問を入力する。Watsonは質問の意味を理解してデータを分析、結果を図やグラフなどで表示する。

    日本IBMが"誰でも"Watson使えるクラウドサービス、無償版も用意
  • 購入したのに所有でない? 電子書籍・音楽に横たわる「永続性」問題

    米国に比べて普及の速度が遅い日電子書籍だが、最近は紙の新刊と同時に電子版を出版する例も増えており、牛歩ではあるがゆっくりと浸透しているように見える(写真)。筆者は紙と電子が併売されているタイトルは、基的に電子書籍をダウンロード購入することがほとんどだ。 電子書籍をダウンロード購入するたびにユーザーとして悩むことがある。お金を支払ってダウンロードした電子のは誰の「所有物」なのか、というテーマだ。これが紙のであれば明白だ。屋で購入したの所有権は基的に購入者のものだ。 電子書籍はその名が示す通り、紙ののメタファーを踏襲している。ダウンロードした電子書籍は端末内にある仮想の書架に並んでおり、実際の棚に並んだ紙のをイメージできる。さらに表紙があって目次があって、ページをめくるという行為ができることから、端末のスクリーンの中に紙のをイメージするのが普通の感覚だ。 それがお金を支

    購入したのに所有でない? 電子書籍・音楽に横たわる「永続性」問題
  • データの見方を変えよう、意識すべき三つのポイント

    ビッグデータを分析する際、企業システムで扱うデータを組み合わせて分析することが多い。最後に、企業システムのデータをビッグデータ分析システムの対象に加えるときの注意点をまとめる。従来とは異なる視点や考え方が求められるという。 従来の企業システムで扱うデータを組み合わせて、ビッグデータを分析することも多い。組み合わせる際には注意すべき点がある。三つのポイントを解説しよう。 ポイント1 業務プロセスの視点でデータを捉える エンジニアの皆さんは現在、主に顧客の業務を効率化することに重きを置いて、システムを開発しているのではないだろうか。そのような意識では、データは最新の状態だけ保持できればよいと考えがちになる。 例えば、ある受注データに対して数量に変更があった場合、システムでは受注データに記録された数量の値を上書きすればいいと考えるだろう。だが、こうした数量変更が頻発していると分かったとき、受注業

    データの見方を変えよう、意識すべき三つのポイント
  • 「OSSライセンス=契約」という誤解を解く

    「OSSライセンス=契約」という誤解を解く:OSSライセンスで条件を指定する権利はどこからくるのか?(1/2 ページ) オープンソースソフトウェアについて解説した記事の中には、「OSSライセンスは契約である」という誤解を目にすることが多い。この連載は「第9回著作権・著作隣接権論文」で佳作に入選した論文をベースに、その誤解を解いてみるという試みをしたい。 問題意識:OSS開発者が条件を指定する権利はどこに由来するのか 前回の連載「企業技術者のためのオープンソースソフトウェア(OSS)ライセンス入門」では、企業がオープンソースソフトウェア(OSS)とうまく付き合っていくためのポイントを、ライセンスという観点から解説した。 それから6年が経過した。当時もそうだったが、OSSはますます広がり、企業が新たなビジネスやサービスを展開する際に利活用するのはもちろん、自らの成果物をオープンソースとして公開

    「OSSライセンス=契約」という誤解を解く
  • [マネジメント編1]モジュールは「人間関係」で分割

    「暗闇プロジェクト」ではリスクを見極め、必要なら即行動に移す姿勢が欠かせない。システムのモジュールを「人間関係」を基に分割するといった“非常識”な施策も大いに有効だ。 この連載では、先の見えない「暗闇プロジェクト」でトラブルに陥らないための実践的なヒントやノウハウを紹介している。今回と次回ではメンバー追加やモジュール分割、課題管理、品質管理に関わる六つのセオリーを紹介する。 セオリー1 メンバーの追加は “下っ端”が判断する 一つめのセオリーは、「プロジェクトにメンバーを追加すべきどうかは現場の“下っ端”が判断する」である。 「遅延しているプロジェクトに人を追加すると、さらに遅れる」というブルックスの法則をご存じの方は多いだろう。筆者の経験でも確かにその通りだと思うが、こんな例もある。「デスマーチ(失敗プロジェクト)」に陥る寸前で踏ん張っていたあるプロジェクトでは、要員を追加することで、明

    [マネジメント編1]モジュールは「人間関係」で分割