<code id="okdk5"></code><strike id="okdk5"><small id="okdk5"><samp id="okdk5"></samp></small></strike>

    <tr id="okdk5"><sup id="okdk5"></sup></tr><strike id="okdk5"></strike>

  1. <code id="okdk5"></code>
    <code id="okdk5"></code><strike id="okdk5"><sup id="okdk5"></sup></strike>
  2. 主頁 > 超兔理念 > SaaS產品如何滿足客戶A的個性化需求?

    SaaS產品如何滿足客戶A的個性化需求?

    客戶A的需求,專項開發不難,只要針對分析開發即可。但問題是:邏輯固化,數據固化,業務固化,一句話,通用性不夠。通用性是產品功能的生命力。因此,我們需要將客戶非常具象的專項需求做模型抽象。

    好系統,對用戶的要求是粗放的。如果我們能夠把客戶的場景設計成通用的邏輯、數據和關系,意味著可以為客戶解決更多的問題,可以更靈活應對這個客戶的業務調整。這是面向標準化抽象的基礎邏輯,也是SaaS產品OneCode的技術保障。

    SaaS產品如何滿足客戶A的個性化需求?

    一、最忌諱湊功能、湊邏輯:絕大多數的管理應用類軟件,都是基于主系統邏輯做開發。現在大多數的系統都有自己成熟的框架、體系和技術上的基礎。用現有的東西去搭建,比從零開始寫容易。產品經理在設計方案的時候會依賴原有的體系,這就容易出現用原有的組建、原有的邏輯、原有的界面、原有的UI去湊功能。凡是湊出來的功能,都不夠強壯,缺少魯棒性。魯棒性強的系統,容錯性就強,允許系統在一定(結構、大小)的參數攝動下,維持其它某些性能的特性。

    二、需求分析的方法論:模型抽象分2步:1)分析使用場景。2)業務抽象:邏輯,數據和關系。關系:輸入數據時的約束,表和表的關聯,觸發機制。業務需求元素:場景、用戶、使用頻次、數量級。

    三、在大背景中分析小場景:小場景后面可能是企業核心業務依賴,養成把小場景放到客戶A企業整體業務邏輯中去分析的習慣,才能真正讀懂用戶需求。對于很多廠商而言,用戶需求的滿足不是難度,但是他看不出用戶需求背后的業務重要性。如果我們只是把用戶的需求看成一個小功能,在感知上就發生錯誤了,看不出背后的關系。舉例,超兔最近有個醫療行業的客戶,提出一個業務員回訪終端客戶發掘分銷機會的場景需求。看起來是一個不大的事情,但是放在該企業的整體業務中,即可發現其重要性:

    1)對于一個核心依靠分銷的企業來說:該公司要求銷售對終端客戶(醫院方)做信息挖掘,通過終端客戶去挖掘分銷合作伙伴。這是該公司分銷網絡渠道建設的重要一環,屬于戰略級的行動。

    2)企業的分銷網絡越豐富,影響面越廣,觸及的銷售面越大,相比較一個個找終端客戶,渠道可以起到四兩撥千斤的作用。不過這家醫療公司找渠道分銷合作伙伴的方式更獨特,也更有效。他不直接找,而是通過終端客戶最直接的感覺、最真實的評價,去判斷、去選擇優質分銷商。

    3)企業逐步建立起一個相對強壯、廣泛的分銷網絡,其中根本的業務包括:

    1.發掘新的分銷商線索。包括:分銷商的基本信息,哪家企業,業務員,主營產品,覆蓋區域等。

    2.更新分銷商信息。包括:分銷商有沒有換業務員?換地址?換聯系方式?

    3.監督已經簽約分銷商的服務質量。意義:確保終端客戶滿意度;淘汰不合格的分銷商。

    4)銷售層:一次行為的終端拜訪。分銷商與終端客戶并重。銷售需要把了解到的關鍵數據記錄到系統中,并刷新到各自的主業務表,包括:1.發掘了幾個新線索;2.更新了幾個老線索;3.回訪監督分銷商的數據。

    最終,我們根據客戶提供的所有需求,抽象為:

    1.我要經常回訪老客戶,刷新關鍵聯絡信息。【這是客戶回訪的標準邏輯,通用程度大于90%】

    2.回訪老客戶時,轉介紹了新潛客給我。【通用性可以達到80%】

    3.回訪中我還想記錄和刷新聯系人信息、其他業務信息(支持分類)。【提取共性+拓展自定義:分銷商的終端質量回訪,適應性不超過30%;但是,通過將銷售行為做抽象,即銷售操作記錄與刷新聯系人信息,刷新對應主表數據,可以達到90%的通用性】

    4.上述事務要集成在一個行動事務下。

    到這里,客戶A的個性化小場景,通過系列標準化分析范式,得出了最大普適的標準化邏輯和功能。

    韩国专线福二区