iKonekt

服務行業適用

當你嘅產品係一個十點鐘上門嘅人

師傅、安裝工人、診所、工作室、車房、教練——所有做完一單生意最後會有一架車、一張椅或者一間房嘅人。對你嚟講,預約唔係成交之後嘅一步——預約就係成交,其他嘢都只係圍住佢轉嘅行政工作。

服務行業有一種好特別嘅壓力:查詢喺唔方便嘅時間嚟,答案要快到贏過兩個競爭對手,而一旦傾掂咗,份工係一個實體事件,唔係改個狀態就可以改期。

所以啲軟件通常都喺同一個位斷開。聊天widget喺23:41答咗;日曆知有星期六;付款連結喺某人嘅已寄出郵件入面;發票星期一先憑住一張筆記本相開出嚟。四個系統,一個客人,但想答「星期六到底confirm咗未?」就一定要求人。

Anna Kowalska聊天 → 發票 · 11日
  • AK聊天你哋週末會唔會安裝?
  • BOT助手星期六得㗎——Marek朝早會confirm個時段。
  • MWMarek星期六10:00得閒。要我留低佢嗎?
  • MW備註撳門鐘,唔好敲門。有狗。
  • ✓搞掂、收咗錢、開咗發票2 400 zł,畀卡,發票由紀錄直接開出。

一個紀錄零次重新輸入

23:41嘅問題

呢行大部分查詢都係放工時間之後用手機嚟嘅,來自一個一次過比較緊三間公司嘅人。贏出嗰個好多時就係回覆得最早嗰個——諗落幾灰,直到你發現呢個問題其實完全有得解。

聊天機械人喺度嘅工作唔係要叻,而係喺23:41確立幾件事:星期六係存在嘅、朝早會有人confirm、而呢個人已經係一個由真嘅銷售員負責嘅真實聯絡人。通常咁就夠你喺食早餐嗰陣仲喺入圍名單度。

跟住Marek就做機械人做唔到嗰部分:佢睇住真嘅日曆,留低一個真嘅時段。

掛喺同一個紀錄上面嘅四樣嘢

時段
掛喺聯絡人度,所以日曆項目知道佢係由邊個對話嚟——而個對話都知道有個日曆項目。取消會出現喺thread度,就喺客人解釋旁邊。
提示
前一晚自動發出,喺thread度睇到,所以銷售員知道已經發咗。單單呢一行就消滅咗大部分爽約,同埋所有關於「到底有冇發過提示」嘅爭拗。
付款
入到銷售員自己個戶口,紀錄返去聯絡人度。做嘢嗰個人唔使問辦公室任何人,都知收咗錢。
發票
由已經有客人、價錢同做咗啲乜嘅紀錄直接開出。對波蘭企業嚟講包括KSeF,按公司設定,因為義務生效日期視乎公司而定。

關於隻狗嗰句note唔係講笑——或者應該話,係一個一直講都仲啱嘅笑話。每間服務企業都靠呢啲細節運作:閘機密碼、有鎖匙嘅鄰居、十點前接唔到電話嘅客人。一個冇地方放呢啲細節嘅軟件,你個團隊遲早靜靜雞繞過佢去用自己嘅方法。

一個工作星期

實際上改變咗啲乜

架車都知

邊個上門都會喺手機度睇到成個對話紀錄:報價係幾多、承諾過過乜、閘門密碼,仲有上次拜訪搞得好唔掂。有備而嚟,基本上已經係成功咗大半。

星期六有得答

「星期六確定咗未?」呢條問題只有一個地方睇、一個答案。唔使打去 office,亦唔使對住兩個差一個鐘嘅日曆互相核對。

星期一短咗

唔使靠收據同記憶去重組成個星期。單據係喺每份工收工嗰陣已經開咗,資料全部由本身已有嘅紀錄度攞。

由「你哋星期六做唔做嘢?」到一張已收款嘅發票,全部喺同一份紀錄度。

十一日、四個渠道、一個客,冇人打過地址多過一次——個客就更加唔使。

開啟控制台 睇下個銷售流程

「星期六係咪真係確定咗?」

一個地方睇。一個答案。

時段、提醒、付款同發票全部掛喺同一個聯絡人度——所以邊個上門都已經知閘門密碼,仲知你隻狗嘅事。

由銷售流程到發票 →