Displaying extended context for query match # 21,594 in text YL201602531
<< Prev Next >>
    
 

是 你 應該 衡量 的 對象 。 __UNDEF__ 找 對 衡量 的 對象 事實 證明 , 你 把 衡量 的 對象 搞錯 了 。 不過 , 至少 你 已經 知道 了 。 但 你 怎麼 知道 什麼 才 是 正確 的 衡量 對象 ? 這 就 是 你 要 把 文書 作業 暫時 擱 在 一 旁 的 時候 了 。 你 可以 透過 腦力 激盪 找出 各 種 可能 的 對象 , 給 顧客 一 份 無所不包 的 問卷 來 進行 調查 ( 如果 有 人 願意 填寫 這麼 常 的 一 份 問卷 ) 。 且 慢 — — 讓 我們 學 聰明 點 。 我們 只要 坐下來 進行 理性 的 思考 就 好 了 。 易地 而 處 , 在 生活 中 的 每 一 天 , 你 不 就 是 一 名 顧客 嗎 ? 如果 你 打電話 找 人 修理 你 的 洗衣機 、 電話 、 或是 任何 一 種 產品 … … 你 會 在意 些 什麼 ? 修理 速度 當然 會 是 其中 之 一 。 站 在 顧客 的 角度 , 你 或許 可以 想到 很多 別的 因素 , 這些 因素 就算 不比 修理 速度 重要 , 至少 也 是 不相上下 。 不要 一 個 人 單打獨鬥 , 找 其他 的 團隊 成員 想想 身為 顧客 時 , 他們 會 在意 些 什麼 。 你 當然 得 在 顧客 身 上 印證 自己 想到 的 因素 。 但 順從 本能 , 找到 解決 方案 的 速度 幾乎 都 會 快 過 數 天 的 詳細 研究 。 下 一 個 步驟 就 是 打電話 給 幾 個 曾 向 你 抱怨 的 顧客 , 請 他們 告訴 你 不 滿意 的 原因 。 幾乎 可以 說 是 屢試不爽 , 總會 呼應 本能 所 找到 的 答案 。 當然 , 有時候 , 顧客 還 會 告訴 你 一些 你 沒有 想到 的 因素 。 現在 你 已經 知道 衡量 的 對象 了 — — 你 已經 知道 顧客 真正 在乎 的 是 什麼 。 而且 , 你 也 知道 該 就 你 的 工作 設定 什麼 樣 的 標準 。 你 不但 確定 自己 使用 的 是 正確 的 衡量 方法 , 還 知道 你 衡量 的 對象 也 是 正確 的 。 因此 , 衡量 顧客 滿意度 的 幾 大 階段 如 下 :1 .
 
  衡量 顧客 的 滿意度 。 2.   繼續 進行 衡量 的 工作 。 3 .
 
  回頭 修正 自己 的 標準 。 4 .
 
  確定 衡量 的 目標 是 正確 的 。 驅 動 顧客 服務 願景 的 力量 就 是 顧客 , 所以 了 解 顧客 的 重要性 不容 小覷 。 了 解 顧客 不能 只 知道 他們 是 誰 , 了 解 顧客 意味 著 與 顧客 建立 親密 的 關係 。 你 必須 比 他們 更 清楚 他們 的 購物 習性 和 模式 , 什麼 樣 的 產品 和 服務 最 有 可能 吸引住 他們 。 每 個 人 都 要 有 他 專精 的 事情 , 你 的 職責 就 是 專精 於 與 顧客 相關 的 一切 。 了 解 越 深 , 在 你 尋找 新 方法 以 改良 提供給 顧客 的 服務 時 , 判斷 就 越 正確 。 無論 是 研究 新 的 產品 、 改變 發票 的 格式 、 重新 設計 包裝 , 或是 尋找 最佳 時機 打 銷售 電話 , 你 都 能夠 揣測出 他們 的 需求 。 不管 你 負責 的 是 哪 一 個 部門 , 對 顧客 有 深入 的 了解 , 都 能夠 幫助 你 提供 更 完美 的 服務 。 如何 了解 你 所有 的 顧客 ? 有 些 企業 只有 寥寥 幾 個 顧客 , 但 每 一 個 都 是 大 客戶 , 這樣 就 能 締造 很 好 的 獲利 。 例如 , 製造 戰艦 或 噴射 客機 的 公司 , 就 不 需要 成千上萬 的 長期 客戶 。 但 大部分 人 所 處 的 公司 都 有 認識 不 完 的 顧客 。 儘管 如此 , 我們 還是 得 要 成為 一 個 顧客 專家 。 保留 、 存取 這麼多 知識 的 方法 只 有 一 種 : 電腦 資料庫 。 要 達到 百分之百 的 顧客 滿意度 , 資料庫 是 一 項 功能 最 強大 的 利器 。 資料庫 集中 一切 與 顧客 相關 資料 。 沒有 高效率 的 顧客 資料庫 , 你 的 工作 就 達 不 到 應 有 的 水準 — — 無論 你 從事 哪 種 行業 。 有 些 公司 的 資料庫 完善 齊備 , 有 些 公司 的 資料庫 卻 沒有 什麼 用處 。 或許 你 的 職權 無法 讓 你 選擇 公司 的 資料庫 , 但 優良 資料庫 應該 包括 哪些 項目 還是 值得 你 花 時間 研究 一下 。 這樣一來 , 至少 你 會 知道 你 缺少 什麼 訊息 ( 假設 你 用 的 系統 還 有 缺失 ) , 並 可以 據 此 要求 改善 。 一旦 公司 有意 改善 該 系統 , 你 就 可以 名正言順 地 提出 切合 實際 的 建議 , 促成 你 或 你 的 團隊 , 乃至於 公司 其他 部門 , 有效 達成 顧客 服務 願景 所 需要 的 改變 。   首先 , 評定 資料庫 好壞 的 第一 個 重要 標準 是 各 部門 要 充分 地 整合 。 若是 會計 部門 自己 建立 一 套 系統 , 不能 與 其他 部門 的 系統 互通 , 或是 銷售 和 配送 部門 各自 使用 不同 的 系統 , 資料庫 的 功用 就 無法 獲得 充分 的 發揮 。    想像 一下 , 打電話 向 客戶 催收 貨款 , 卻 在 這 個 時候 才 發現 , 他們 正 和 銷售 部門 因為 貨物 送錯 而 爭吵 不休 。 資料庫 若 能 充分 整合 , 你 就 可以 事先 了 解 這 個 情況 , 自然 也 就 不會 打 這 通 電話 了 。 但 若 不同 部門 各 管 各 的 紀錄 , 你 當然 會 因為 不 知情 而 打出 這 通 電話 , 把 自己 和 公司 都 弄得 灰頭土臉 。   其次 , 資料庫 內容 的 讀取 要 簡單 方便 。 儘管 你 可以 透過 各 種 不同 的 方法 來 讀取 資料 , 但 最 基本 的 方法 還是 透過 客戶 的 名稱 來 讀取 。 大權 在 握 的 是 顧客 , 一切 都 要 以 他們 的 意見 為 依歸 。 如果 每 次 想要 搜尋 有關 顧客 的 資料 時 , 就 得 打開 電腦 終端機 , 輸入 一 個 客戶 代碼 或 交易 代號 , 要 集中 心力 服務 顧客 恐怕 是 難上加難 。    如果 公司 的 方針 是 顧客 導向 , 就 必須 以 單一 顧客 的 名稱 當作 讀取 紀錄 的 主要 方法 。 若 也 能 用 其他 的 項目 — — 訂貨 日期 、 不同 產品 等 — — 來 搜尋 資料 , 那 當然 會 有 很 大 的 幫助 , 但 我們 不能 用 這些 項目 當作    系統 建立 時 的 主 搜尋 項目 。   顧客 名稱 雖 是 我們 最 主要 的 搜尋 路徑 , 但 你 也 要 能夠 透過 任何 搜尋 項目 來 讀取 資料 。 你 的 目的 在於 找出 顧客 的 行為 模式 , 並 進行 不同 模式 的 交叉 比對 。 訂單 最多 的 顧客 消費 金額 是否 真的