業務自動化の始め方｜転記・確認・通知を分けて考える

「受付から完了まで」を並べてみる

例として、問い合わせの受付を考えます。フォームが届く、内容を読む、種類を分ける、担当者に知らせる。この四つを並べるだけでも、判断の必要なところと、単純な受け渡しを分けられます。

最初は分類結果を人が確認してから通知する形でも十分です。自動化する範囲より、いまの仕事に無理なく戻せるかを優先します。

「メールが届く」という開始条件を、ツールではトリガーと呼ぶことがあります。その後に行う転記や通知がアクションです。名前を覚えるより、始まりと終わりを一行で説明できることが先です。メールを読むたびに自動実行されてほしくないなら、担当者が印を付けたときだけ始める方法もあります。

問い合わせ一件を、担当者へ渡すところまで書く

次は説明のための架空例です。フォームには受付番号A-015、「注文番号123の納期を知りたい」という内容が届いたとします。転記するだけの処理にAIは不要です。自由な文章から問い合わせの種類を推測する場合は、誤分類を人が戻せるようにします。

受付番号は二重処理を見分けるためにも残します。名前やメールアドレスだけで同じ依頼と決めると、同じお客様の別の注文まで止めてしまいます。実際には、フォームや管理表が発行する一件ごとの番号を使えるか確認してください。

いつもと違う入力を、置き去りにしない

内容が空だったり、必要な情報が足りなかったりすることはあります。どの条件で処理を止め、誰に知らせるかを決めておけば、間違ったまま次へ進むのを減らせます。

同じ依頼が二度届いたときも確認しましょう。通知や請求を二重に実行しない仕組みは、便利さと同じくらい大切です。

注文番号が空なら「不明」として確認担当へ戻し、適当な番号を補いません。同じ受付番号が再び来たら、処理記録を見て既存の一件へまとめます。書式の整った依頼だけを試すのではなく、空欄・二重受付・通知先不明の三つも試験用データで確かめます。

• 空欄・不明な内容の受け皿を用意する
• 二重送信を確かめる
• 失敗した場所と再開方法を残す

浮いた時間と、見直す時間を両方残す

作業が速くなっても、確認や修正に時間がかかれば負担は残ります。導入前の作業時間と、導入後の確認・修正時間を同じ条件で比べてみます。

定型的な作業には取り入れやすい一方、一件ごとに判断の重さが変わる業務では、人の確認を残す方が扱いやすいこともあります。

この例でも「導入した初日から得」とは言えません。件数が少なければ準備にかけた時間を取り戻しにくく、月額料金や作り直しも加わります。一週間だけ記録して、確認・修正まで含めて楽になったかを見てください。

「送れなかった」と「届いたかわからない」は違う

外部サービスから返事が来ないとき、実は通知だけ届いていることがあります。そのまま再送すれば、同じ依頼が二つ並ぶかもしれません。受付番号を付けて同じ依頼か判定し、結果を確認してから再開できるようにします。

Cloudflare Workflowsの公式資料では、再試行と冪等性を設計上の注意点として扱っています。どのツールを使う場合でも、通常時だけでなく「途中で止まった後」を試すと、運用に残る手間が見えてきます。

最初の一週間は、送信する前までを試す

まず普段の仕事から、同じ項目を何度も扱う一件を選びます。社外への送信・請求・削除までつなぐ前に、下書きの作成か表への転記で止め、人が確かめます。使うツールも、この段階で社内が利用を認めているものから選びます。

会議メモから担当と期限を拾う仕事なら、資料へ質問できるサービスで、必要な項目が正しく出るか先に試せます。これは、転記や通知を自動で実行する仕組みとは別の段階です。

仕事を選ぶところで迷うなら業務の棚卸し表、手順を他の人に渡すなら小さなチームの業務マニュアルへ進めます。入力をそろえ、戻せる範囲を決めてから接続すると、導入後の困りごとを減らせます。

• 普段の一件と、空欄・重複の例を用意する
• 成功と失敗を、受付番号で追えるようにする
• 最初は人が結果を見てから次へ進める
• 確認・修正・費用を一週間記録する