紙・PDFで続けてきた申込・注文業務をWebへ移す｜実務知識

紙の申込書をWebフォームにする。PDFの商品一覧を画面にする。言葉にすると簡単ですが、実際に着手すると「この選択は誰が確認するのか」「該当しない場合はどこへ戻すのか」「受付後は何へ転記するのか」が次々に出てきます。

私たちの制作でも、紙の注文手順をカテゴリ選択から受付まで組み直した案件や、検索から申込、社内システムへの連携まで整理した案件がありました。画面をきれいに並べただけでは、これまで担当者が会話や手作業で補っていた判断が抜け落ちます。

ここでは、紙やPDFをそのまま画面へ写すのではなく、利用者の行動と受付側の仕事を一つのWeb業務へ変換する方法を整理します。

帳票ではなく、実際の一日を聞く

最初に見るのは用紙の項目ですが、仕様を決める材料は用紙だけでは足りません。担当者が受け取ってから何を確認し、どこへ転記し、不足があれば誰へ連絡するかまで聞きます。

紙では一枚に見えていても、実務では複数の役割と判断がつながっています。そのつながりを先に出すと、画面に必要な入力と、画面外に残す仕事を分けられます。

Web化で先に作りたくなるのは入力項目の一覧です。しかし、項目だけでは「途中」「確認待ち」「差し戻し」「受付済み」を表せません。利用者と担当者の双方について、状態と次の行動を並べます。

この順番が見えると、確認画面や自動返信が必要な理由も、管理画面に必要なステータスも説明できます。

紙の運用では、欄外のメモや担当者の判断が例外を吸収しています。Webでは、選択肢にない、在庫や条件が変わった、同じ人が二度送った、途中で戻った、といった場面を仕様にしなければ止まります。

例外を全部自動化する必要はありません。人が判断するなら、その人に必要な情報と戻し方を用意することが仕様になります。

条件検索、料金計算、シミュレーター、顧客管理への登録などが入ると、見た目は一つでも処理は複数になります。入力値、計算結果、外部へ送る値、保存する値を分け、どこが正しい状態を持つか決めます。

外部会社がフォームや計算処理を担当する場合は、画面の幅、項目名、エラー表示、受け渡すデータ、最終確認者まで揃えます。「組み込めば完成」ではなく、組み込んだ後の一連の操作が完了条件です。

利用者に完了画面が出ても、通知が届かない、台帳に保存されない、担当部署へ振り分けられないなら業務は終わっていません。受付番号、通知、保存データ、担当者の確認画面、外部連携を一続きで試します。

最初から全パターンを作るより、代表的な一つの申込を、開始から担当者の処理完了まで通す方が早く不足を見つけられます。その後、対象外、重複、取消、情報不足などの境界へ広げます。