本文同步刊載於個人連載網站

第一次做諮商所預約管理工具時，我很早就有一個想法：

如果所有事情都可以直接在 LINE 裡，靠機器人一問一答完成就好了。

不用另外記一個網址。

不用重新學一套陌生的操作介面。

個案、心理師和櫃檯本來就會用 LINE，那就直接讓系統在 LINE 裡工作。

實際的順序不是，我先把整套系統有哪些功能想清楚，再決定把它們放進 LINE。

更接近的是：

我先決定想用 LINE 對話來處理事情，接著才一邊理解現場，一邊把那些工作拆成一段一段的對話。

LINE 本來就在工作裡

這個選擇和諮商所原本的工作方式很有關係。

LINE OA 本來就是櫃檯和個案、心理師之間很主要的聯絡管道。

個案有事情會從 LINE 詢問。

預約時間需要確認，也常在訊息裡來回。

心理師需要聯絡的事情，同樣很常透過 LINE 處理。

所以我看到的不是：

「現場完全沒有工具。」

而是：

很多工作本來就在 LINE 裡開始。

只是訊息進來之後，後面的事情還是要靠櫃檯接著處理。

收到預約需求，要再確認時間。

確認完之後，可能還要把資料輸入其他地方。

事情完成了，也可能還要再通知下一個人。

那我就開始想：

如果原本靠櫃檯一個一個處理的事情，可以直接讓 LINE 機器人接著做呢？

我就是把人的工作拆成一段一段對話

最開始的想法很簡單。

使用者傳來訊息，機器人判斷他想做什麼，再回覆下一個問題。

如果要預約，就先問一件事。

回答之後，再問下一件。

遇到不同選擇，就走不同分支。

我當時理解功能的方式，常常就是：

「先問這個。」

「回答之後，再問下一個。」

「如果選 A，就往這裡走。」

「如果選 B，就換另一段。」

Day 3 寫過，我常常是在看懂一段工作之後，開始想：

如果這裡可以少做一步呢？

而在當時，這些「許願」很快就會進入同一個框架：

這件事情要怎麼用 LINE 對話完成？

如果原本需要櫃檯問幾個問題，就讓機器人照順序問。

如果原本需要人工確認選項，就讓使用者直接在對話裡選。

如果一件事情完成後，原本每次都要通知下一個人，那是不是可以讓系統自己接著處理？

所以很多功能不是先在 LINE 外面完整長好，再被搬進對話裡。

它們本身就是在把工作拆成一次又一次對話的過程裡形成的。

這對使用者很直覺，對我也很有吸引力

我當時很在意一件事：

大家不用另外學新的東西。

個案本來就知道怎麼用 LINE。

心理師也一樣。

不用第一次進入一套陌生系統，再重新找：

預約在哪裡？

我要按哪裡？

這個功能藏在哪一頁？

連帳號這件事情，我當時也想得很簡單。

既然使用者本來就有自己的 LINE 帳號，那系統就可以利用這個身分，知道現在是哪一個 LINE 使用者在互動。

看起來很多事情都已經有一個現成的入口。

而且我當時根本還不太知道完整前端可以長什麼樣子

這個選擇也和我自己的能力有很直接的關係。

那時候我開始接受前端訓練才幾個月。

學過一些 JavaScript、TypeScript，也做過一點基本切版。

但我對完整產品介面的理解還很淺。

那時候甚至還沒學到 RWD。

至於一套後台操作介面到底要怎麼規劃、功能變多之後怎麼整理、桌面和手機畫面要怎麼處理，我更沒有完整概念。

我只很模糊地知道：

系統需要一個讓人操作的前端。

但那個前端到底可以長成什麼樣子，我其實不知道。

LINE 在這時候就顯得很方便。

它已經幫我準備好一個使用者看得到、也知道怎麼操作的地方。

我不用先從一張空白頁面開始想：

這裡要放什麼？

按鈕放哪裡？

不同功能怎麼切？

畫面之後變複雜了怎麼辦？

對一個幾個月前才剛經歷過「網站雖然做得出來，但自己完全改不動」的人來說，這確實是一條比較容易走進去的路。

所以我當時想的，不只是「把 LINE 當入口」

我真正的想法更接近：

既然 LINE 已經可以跟使用者互動，那是不是乾脆所有操作都放在這裡？

個案在 LINE 裡操作。

心理師在 LINE 裡操作。

櫃檯和經營者需要做的事情，也盡量放進 LINE。

我不用先弄懂一整套完整前端。

使用者也不用另外學一套新的系統。

看起來兩邊的問題一起被解決了。

產品早期的樣子，也就是在這種條件下長出來的。

一邊是現場本來就存在的 LINE。

另一邊是我當時能理解、能實作到的程度。

於是每多一個需求，我想到的都還是同一件事：

這件事情，要怎麼繼續拆成 LINE 裡的一段對話？

那時候的願望很單純：

如果所有事情都能交給 LINE 機器人完成，就好了。