カスタム注文管理アプリ: 分かりやすい1つのワークフローを作る

カスタム注文が追跡しにくくなる理由

カスタム商品の依頼は、1か所から始まるとは限りません。顧客がメールで寸法を送り、チャットで色を確認した後、電話で配送日を変更することもあります。誰かが詳細をスプレッドシートに転記する一方で、別の担当者が共有受信トレイにメモを残していることもあります。

数件の注文なら、この方法でも対応できます。複数の案件が同時に進むと、すぐに問題が起きます。同じ依頼に2人が返信したり、誰も気づかなかったりするかもしれません。最新の変更がメッセージの中に埋もれていると、営業が古い仕様で見積もりを出すこともあります。その結果、生産担当には不完全な指示が届きます。

小さな抜け漏れが大きなコストにつながります。24枚の刻印看板を注文するなら、素材、寸法、仕上げ、デザインファイル、数量、納期、配送先住所、承認状況が必要です。記録が「カスタム看板24枚」だけなら、スタッフは後から詳細を確認しなければなりません。見積もりを間違えたり、生産が止まったり、顧客に同じ質問を何度もしたりする可能性があります。

スプレッドシートでは、ステータスも信頼しにくくなります。あるタブでは注文が準備完了になっているのに、梱包メモには検品が必要だと書かれているかもしれません。配送を手配した担当者だけが配送会社の情報を持っていることもあります。顧客から進捗を聞かれたとき、スタッフは1つのレコードを見る代わりに、ファイルや会話を探します。

カスタム注文管理アプリがあれば、最初の依頼から見積もり、承認、生産、梱包、配送まで、各案件に共有レコードを持たせられます。顧客情報、商品の要件、メモ、ファイル、価格、期限、現在のステータスを保存できる構成にします。

営業は顧客が承認した内容を確認できます。生産担当は、必要な商品情報が揃った状態で作業できます。サポート担当は社内で聞き回らずに状況を伝えられます。次に対応すべき人や、不足している情報も表示できると便利です。

小規模なチームなら、受信トレイのラベルやスプレッドシートの列をつぎはぎした管理方法から移行できます。大規模なチームでは、引き継ぎが明確になります。誰かが注文を開いたとき、顧客の依頼内容、チームが約束したこと、配送までに残っている作業がすぐに分かる状態を目指します。

構築前に注文の流れを整理する

普段の仕事の流れに合わせてアプリを作ります。まず、依頼の受付、価格と納期の確認、商品の製作、梱包、配送手配など、必要な作業を洗い出します。小さな会社では、1人が複数の作業を担当することもあります。担当者の役職ではなく、実際の作業を記録してください。

フィールドや画面を作る前に、紙に注文の流れを書き出します。すべての引き継ぎを含めます。例えば、営業が刻印マグカップ40個の依頼を入力し、マネージャーがデザインと見積もりを承認し、生産担当が刻印し、梱包担当が数量を確認し、配送担当が追跡情報を顧客に送る流れです。

みんなが理解できるステージを使う

実際の判断に合う、短いステージのセットを選びます。チームが作業を開始できるのか、承認待ちなのか、配送会社の手配が必要なのかを知りたいときに、「進行中」のような広すぎるラベルは避けます。

実用的なカスタム注文ワークフローでは、次のステータスを使えます。

• New request
• Waiting for approval
• Ready for production
• In production
• Packed
• Delivered

キャンセル済みと保留中の注文は分けて管理します。保留中の案件には、「素材待ち」や「顧客がデザインを変更」などの理由が必要です。

引き継ぎごとに担当者を決める

ステータスを変更するたびに、担当者を明確にします。見積もりが承認されるまで、営業は注文をReady for productionに移しません。生産担当が注文をPackedに変更する前には、梱包の確認が必要です。境界を明確にすると、誰かが対応するだろうと考えて注文が共有キューに残る事態を防げます。

各ステージについて、誰が注文を移せるのか、どの情報を入力する必要があるのか、次のタスクを誰が受け取るのかを1つのルールにします。配送では、配送会社、追跡番号、発送日、配達完了の証明を担当者が追加する形にできます。

AppMasterなら、ビジュアルなBusiness Processでこうしたルールをモデル化できます。まず通常の流れを作り、実際の注文でアプリを使ってから例外を追加しましょう。

メインの注文レコードを作る

カスタム注文ごとに、チーム全員が共有できる1つのレコードを作ります。顧客名、必要に応じて会社名、電話番号、メールアドレス、依頼日、希望配送日を含めます。

検索しやすく、メッセージにも使える注文番号を追加します。例えばCO-1042のような番号をアプリに生成させ、スタッフが手作業で作らなくて済むようにします。番号が重複したり分かりにくかったりすると、正しい案件を探すのに時間がかかります。

最初の画面は簡潔にします。注文を開いた人が、誰からの依頼か、何が必要か、いつ必要か、現在のステータスをすぐに確認できるようにします。

ステータスは短く明確にする

多くのチームでは、次のステージで十分です。

• New
• Quoted
• Approved
• In production
• Ready to ship
• Delivered

各ステータスに1つの明確な意味を持たせます。顧客が見積もりを承認した後だけApprovedに移し、営業担当が承認を期待している段階では移しません。これにより、生産注文の追跡が正確になります。

明細に属さない背景情報には、全体メモのフィールドを使います。「15時以降に顧客が受け取りに来る」「5月12日に提供されたサンプルに合わせる」といった内容です。参考写真、署名済みの承認書、仕様書、デザインファイルは、メールのスレッドではなく注文と一緒に保存します。

社内情報と顧客向け情報を分ける

メッセージ欄を2つ用意します。社内メモには、仕入先の問題、見込み作業時間、価格に関する懸念、発送前に電話するためのリマインダーなどを記録します。顧客にはこの欄を見せません。

顧客向けの更新情報には、「ご注文は生産中です」「ご注文品の受け取り準備ができました」のように、送信してよい内容だけを記載します。AppMasterでは、これらのフィールドを1つのビジュアルな注文フォームに配置し、閲覧や編集ができる人を管理できます。

例えば、ベーカリーがブランド入りカップケーキ80個の依頼を受けた場合、イベント担当者、配送日、ロゴの添付ファイル、合意した価格、ステータスを1つの注文レコードに保存できます。生産担当は、フレーバー、数量、個別タスクを追加する前から、信頼できる情報を確認できます。

詳細を失わずに明細を追加する

カスタム注文は、最初のメッセージだけを見ると簡単に見えます。例えば、刻印マグカップ2個、印刷カード1枚、来週金曜日の配送です。しかし、それぞれに価格、素材、承認の要否、生産作業があります。商品やサービスは、すべて独立した明細にします。

メインの注文には顧客情報、希望配送日、全体のステータスを保存します。明細には商品ごとの詳細を保存します。複数の商品を含む依頼でも、アプリを見やすく保てます。

各商品に十分な情報を持たせる

履行中にチームが判断する内容に合わせてフィールドを作ります。印刷会社なら、カードサイズ、用紙、デザイン、数量、単価、箔の色が必要かもしれません。ケータリング会社なら、提供数、メニュー、アレルギーや食事制限、設営指示が必要になるでしょう。

カスタム明細の多くには、次の情報が必要です。

• 商品またはサービス名と数量
• サイズ、素材、色、選択したオプション
• デザイン、参考ファイル、承認状況
• 単価と商品ごとの割引
• 生産指示

指示は該当する明細に保存します。「青いマグカップにSarahの名前を刻印する」という指示は、マグカップの明細に記載します。生産担当と梱包担当がすぐに確認できます。

アプリで合計金額を計算する

アプリが明細ごとに数量と単価を掛け、小計を合計して注文金額を計算するようにします。顧客が数量を変えたり商品を入れ替えたりするとき、手計算ではミスが起きます。

例えば、1枚3ドルの招待状20枚と、1枚18ドルの看板2枚なら、合計は96ドルです。招待状が30枚に増えた場合、合計はすぐに126ドルになります。

注文を編集できる状態で、スタッフが明細を追加したり削除したりできるようにします。複数人が注文を扱うなら、誰がいつ変更したかを記録します。監査の記録が必要な場合は、「顧客がキャンセル」など、削除理由も残します。

AppMasterでは、明細のデータモデルを使って、1つの注文に複数の商品を紐づけられます。スタッフは簡単な注文画面で明細を追加し、数量を更新し、生産開始前に計算済みの合計金額を確認できます。

生産作業を段階的に追跡する

承認済みの注文に「In production」というラベルを付けるだけでは不十分です。チームが商品の製作を進める方法に合わせて、作業をタスクに分けます。各タスクを注文に紐づけ、必要に応じて特定の明細にも紐づけます。

オーダーメイドの看板なら、デザイン確認、素材のカット、印刷、品質確認、梱包などのタスクがあります。担当者はメッセージを探さなくても、タスクを開いて商品情報、約束した日付、顧客メモ、ファイルを確認できるようにします。

承認済みの注文からタスクを作る

よくある商品タイプごとにタスクテンプレートを用意します。スタッフが注文を承認すると、アプリが必要なタスクを作成します。繰り返しの入力を減らし、最初から作業を見える化できます。

各タスクには、担当者またはチーム、期限、次のような簡単なステータスを設定します。

• Not started
• Ready to work
• In progress
• Waiting
• Complete

タスクを進められないときはWaitingにします。承認不足、素材の遅れ、機械の問題など、ブロッカーを選び、短いメモを追加します。注文担当者は遅れを早く見つけ、約束した日付に影響が出る前に顧客へ連絡できます。

期限は推測ではなく配送日から逆算します。集荷の1日前に梱包を終え、印刷に2日かかるなら、タスクの日付もその順番に合わせます。週末、仕入先のリードタイム、品質確認の時間も考慮してください。

スタッフ向けの作業画面を絞り込む

生産担当者が注文の履歴全体を必要とすることはほとんどありません。画面には、次の担当タスク、期限、注文番号、作業開始に必要な詳細を表示します。

印刷担当者に必要なのは、承認済みファイル、素材、数量、仕上げ、印刷メモだけかもしれません。マネージャーには、完了したタスク、ブロッカー、注文履歴を含む全体表示が必要です。

タスクを完了したら、誰がいつ対応したかを記録します。「校正データとデザインを確認済み」のようなメモがあれば、単なるステータス変更よりも次の担当者に多くの情報を伝えられます。

AppMasterでは、タスクを注文や明細に紐づけ、Business Processでタスクの作成、作業の割り当て、生産完了時の注文更新を行えます。

依頼から配送までの流れを確認する

顧客が、2色印刷のブランド入りトートバッグ50個を依頼したとします。内訳は、白いロゴのネイビー30個と、黒いロゴのナチュラルカラー20個です。営業は顧客名で新しい依頼を作成し、期限、連絡先、デザインファイル、配送先住所を追加します。

注文には「トートバッグ50個」という1つのメモではなく、2つの明細を作ります。1つ目には、白い印刷のネイビーバッグ30個と合意した単価を記録します。2つ目には、黒い印刷のナチュラルカラー20個、個別の価格、メモを記録します。工房には、それぞれの組み合わせに対する別々の指示が必要です。

アプリが明細を合計し、送料とセットアップ料金を加えて見積もりを作成します。営業が顧客の承認を記録し、注文をApprovedに変更します。見積もり時の数量をロックして、スタッフが間違った内容で作業を始めないようにもできます。

作業を見える順番で進める

生産担当者は、承認済みの注文を作業キューで確認します。担当者がデザインを確認し、ロゴのサイズと色を確定します。その後、注文を印刷に進めます。

明確な順番は次のようになります。

• デザイン確認
• 印刷
• 品質確認
• 梱包
• 発送

品質確認では、担当者が両方のバッチの数量と印刷位置を確認します。ネイビーのバッグ5個を再印刷する必要があれば、注文全体ではなくネイビーの明細にメモを追加します。梱包担当者は、最終数量、箱数、配送先住所を同じレコードで確認できます。

役に立つ配送更新を送る

発送後、配送担当者がステータスをDispatchedに変更し、配送会社、追跡番号、発送日を追加します。顧客には、50個のトートバッグを発送したことと追跡番号を含む更新情報が届きます。

営業は工房に状況を聞かなくても顧客からの電話に回答できます。生産担当者も、古いメールを探さずに承認済みの詳細を確認できます。AppMasterでは、ビジュアルなデータ設計、ステータス変更用のBusiness Process、営業、生産、発送向けの別画面を利用できます。

注文を遅らせるミスを避ける

遅延は、解釈に任される部分が多すぎるワークフローから始まります。アプリには、何に対応する必要があるのか、誰が担当するのか、次に進む前に何を完了すべきかを表示します。

意味が明確なステータスを使う

注文のライフサイクルの大部分で、「保留」や「進行中」を使うのは避けます。こうしたラベルでは、スタッフがメモを読んだり同僚に確認したりしなければ、何が起きているか分かりません。承認が遅れている注文と、誰かが実際に製作している商品も同じように見えてしまいます。

家具職人は、顧客が見積もりを依頼しただけの段階で素材を切り始めるべきではありません。顧客が承認し、チームが承認を記録するまで、注文は「Quote sent」に留めます。これにより、生産時間を守り、未承認の変更をめぐるトラブルを避けられます。

自由記述のメモにも問題があります。「青いシャツ3枚、MとL、ロゴを追加」という記述では、生産に必要な明細情報が足りません。サイズごとの数量、ロゴの位置、商品の期限をすぐに確認できないからです。数量、オプション、価格、生産メモ、作業ステータスのフィールドを持つ明細を使います。

配送更新を注文と一緒に管理する

配送を別のスプレッドシートで追跡しているチームは少なくありません。そこで発送済みに変更しても、注文ワークフローの更新を忘れることがあります。サポート担当者には古いステータスが表示され、顧客に誤った回答をしてしまいます。

配送会社、追跡番号、発送日、配送先住所、配送ステータスを注文アプリに保存します。スタッフが配送情報を更新すると、顧客向けのレコードも更新されるようにします。マネージャーは、予定日を過ぎた注文を見つけられます。

権限も慎重に設定します。生産担当者にはタスクを完了する権限が必要でも、注文価格、支払い状況、配送先住所を編集する権限は不要かもしれません。各役割が扱うフィールドだけにアクセスできるようにします。

公開前に簡単なチェックを行う

現実的な注文を使った15分のテストで、画面上では小さく見えるものの、後で作業漏れにつながる問題を見つけられます。複数の明細、顧客メモ、生産ステージ2つ、配送日を含む注文を使います。アプリを作っていない人にテストを完了してもらいましょう。

すべての引き継ぎでレコードを確認します。営業、生産、配送の担当者が、他の場所を探さずに必要な情報を確認できる状態にします。

• すべての注文に担当者と現在のステータスがあることを確認する。
• すべての明細に説明、数量、単価、明細合計があることを確認する。
• すべての生産タスクに担当者、期限、ステータスがあることを確認する。
• 作業開始前に顧客の指示とデザインが表示されることを確認する。
• 配送メッセージを実行し、顧客が正しい更新情報を受け取ることを確認する。

通常の変更もテストします。生産開始後に、顧客がプリントシャツの注文を20枚から24枚に増やすかもしれません。注文担当者に変更が表示され、明細の合計が更新され、生産担当者にも新しい数量が表示される必要があります。発見のためにスタッフ同士のメッセージが必要なら、ワークフローを調整します。

不完全な注文もテストします。顧客、配送日、明細数量のいずれかを入力せずに保存してみてください。アプリは保存を止めるか、不足情報を明確に表示する必要があります。不完全なレコードを受け入れると、後で整理する作業が増えます。

最初のバージョンは1つの注文タイプに絞る

オーダーメイドの看板、プリントシャツのセット、家具の依頼など、チームがよく扱う注文タイプを1つ選びます。初日からすべての商品を対象にしようとしないでください。その注文を受け付け、製作し、配送するために必要な情報に集中します。

依頼を受ける人、作業をする人、配送を手配する人に、現実的なサンプル注文でテストしてもらいます。どこで手が止まるかを確認してください。生産担当者が次に何をすべきか分からないなら、フィールドを増やす前に画面やステータスを改善します。

通常のケースと難しいケースの両方を含めます。複数の明細がある完全な注文、顧客の承認待ちの依頼、素材不足で遅れている注文、配送準備が整った完了済み注文、顧客が変更またはキャンセルする注文などです。

まず手作業の流れを整えます。スタッフがチャットのメモや別のスプレッドシートに頼らず、注文の作成、作業の割り当て、進捗の記録、配送更新の送信をできるようにします。その後、承認待ちや配送準備完了などのイベントに対する通知から、慎重に自動化を追加します。

AppMasterは、このタイプのアプリを作るためのノーコードプラットフォームです。Data Designerで顧客、注文、明細、生産タスクを作成し、Business Process Editorでルールを設定します。営業、生産、顧客向けの画面も個別に作成できます。必要に応じて、メール、SMS、Telegramで更新情報を送信できます。

最初の注文タイプが実際のユーザーに使われ、うまく機能してから拡張します。別の商品カテゴリー、生産チーム、顧客ポータルを1つずつ追加し、依頼、現在の作業、配送状況の共有元として注文レコードを維持します。