背景
販売経路ごとに受注の管理画面が分かれ、在庫と顧客対応も別のサービスで管理されていました。担当者は毎日それぞれの情報を照合し、必要な内容を表計算へ転記していました。取扱商品や注文が増えるにつれ、確認作業の負担が大きくなっていました。
課題
- 同じ情報を複数のサービスへ手入力し、入力漏れや不一致が発生していた
- 最新の在庫状況を把握するために、その都度確認が必要だった
- 対応が必要な注文や問い合わせを見落とすおそれがあった
- 月次集計を毎回手作業で行っていた
開発時の条件
既存の業務を続けながら導入するため、次の条件を踏まえて設計しました。
- 運用中の販売経路やツールを止めず、既存の使い方を維持する必要があった
- 各サービスのAPI利用回数の制限内で連携する必要があった
- 顧客情報の受け渡しを、連携に必要な項目だけに限定する必要があった
- 社内に開発担当者がいないため、運用担当者が操作・対処できる仕組みが必要だった
提案
n8nを活用し、既存の販売経路、チャットツール、表計算サービスを連携する仕組みをご提案しました。データ連携に加え、エラーの記録・通知と再実行の手順を整え、運用中のトラブルに担当者が気付いて対処できるようにしました。
設計のポイント
- 既存ツールを活用して連携
- 新しい管理画面への切り替えを避け、担当者の作業手順を維持できる部分から連携しました。効果を確認しながら、自動化の対象を広げられる設計にしました。
- 再実行による重複を防止
- 外部サービスの応答が遅れた場合や、担当者が処理を再実行した場合に備え、処理済みかどうかを確認して重複登録を防ぐ仕組みを実装しました。
- 対応が必要な内容に通知を限定
- 重要な通知が埋もれないよう、処理のエラーと、担当者の判断が必要な注文に絞って通知する設計にしました。
- 担当者が再実行できる手順を整備
- エラーが発生した処理、日時、箇所を記録し、担当者が再実行できる手順を用意しました。開発者に連絡せず対処できるようにしています。
実装内容
- 01業務のヒアリングと、自動化する範囲の決定
- 02連携先の仕様確認と、データ項目の対応表作成
- 03n8nによるワークフローの設計・実装
- 04エラー記録・通知・再実行機能の実装
- 05実際のデータでの試験運用と、想定外のデータへの対処
- 06運用担当者への引き継ぎと納品後の調整
導入後の業務の変化
導入後の業務の変化をご紹介します。作業時間や売上への効果は、数値での計測を行っていません。
- 受注・在庫・顧客対応の情報を、連携先のサービス間で自動的に受け渡せるようになりました。
- 手入力による転記が減り、サービス間のデータの不一致が起こりにくくなりました。
- 対応が必要な注文や問い合わせを、通知で確認できるようになりました。
- 月次集計が自動で作成されるようになりました。
- 処理が止まった場合に、担当者が再実行できるようになりました。
今後の改善
- 残っている手作業を確認し、自動化の対象を広げる
- 連携先の仕様変更を確認する頻度を決める
- 実行記録をもとに、エラーの多い処理を改善する
