修理依頼を紙で受け、受付担当がPDFへ保存しても、作業担当が機種名や症状を別の表へ転記していれば、仕事の重複は残ります。紙を電子化した段階と、同じ記録を次の担当が使える段階を区別します。

今回の対象は1種類の修理受付票に絞ります。電話や店頭で受ける依頼、追加の写真、作業結果などがどこへ保存されるかを調べます。最初から全ての帳票を変えようとすると、異なる保存条件や担当が混ざります。

経営者は、受付担当だけでなく、作業担当と顧客へ状況を答える担当へ話を聞きます。誰が何を探しているかが分かれば、受付票の必須欄と保存方法を具体化できます。ファイル数の削減だけを目標にしません。

この章の根拠：出典1

受付番号があれば、似た顧客名の依頼を区別できます。架空の依頼番号U101に、受付票、追加写真、作業状況を対応させます。番号をファイル名だけへ付けるのか、一覧の欄にも持つのかを担当者と決めます。

番号の付け方が担当者ごとに違うと、同じ依頼が別々の記録になります。誰がいつ番号を発行し、追加情報にはどの番号を使うかを決めます。番号の形式そのものより、重複や付け忘れを見つける手順が必要です。

依頼が変更された場合も、元の受付票を上書きして経緯が分からなくならないようにします。現在の情報と追加・訂正の記録を分けます。どの資料が最新なのかを、作業担当が検索時に判断できる状態を作ります。

この章の根拠：出典3

保存担当が分かるフォルダでも、別の担当者には探し方が分からない場合があります。受付番号がある問い合わせと、番号が分からず日付と機種だけが分かる問い合わせを用意します。返答担当が資料を見つけられるかを試します。

検索の結果から、どの資料が現行なのかも分かる必要があります。「修理票_最終」「修理票_最終2」のような名前だけでは、追加内容を見落とすかもしれません。記録一覧へ更新日と状態を付け、元資料への参照先を残します。

閲覧範囲と保存の管理も確認します。受付票の内容を業務で必要な人が見られることと、全社員へ無条件に共有することは別です。管理担当と対象者、バックアップ、困った時の連絡先を整理します。会社の保管条件は担当者へ確認します。

この章の根拠：出典2

「対応中」だけでは、症状を確認しているのか、作業を始めたのか、連絡を待っているのか分かりません。返答担当が使うなら、確認中、作業中、連絡待ち、完了などの状態と、その意味を決めます。状態の数は必要な範囲へ絞ります。

誰がいつ更新するかも必要です。作業担当が夕方にまとめて更新するなら、午前中の一覧は現状と違うかもしれません。更新日時を表示し、未確認の情報を顧客へ確定した状況として伝えない方法を決めます。

追加依頼やキャンセルが起きた場合の担当も確認します。紙を電子化することと、現在の状況を管理することは別の仕事です。保存担当へ全ての更新を集めると負担が増える場合があるため、後工程の担当と分けて設計します。

この章の根拠：出典3

薄い手書きの受付票を読み取れない場合は、受付担当が原本へ戻り、必要な欄を確認します。AI OCRなどを使う場合も、推測した値を確定扱いしません。読めない資料をどこへ保管し、誰が確認するかを決めます。

保存漏れや番号の付け忘れが分かった場合は、後工程の担当へ伝えます。作業だけが進み、一覧が空欄になると、返答担当が状況を把握できません。試行中は、紙と電子の両方が残る範囲と、どちらを確認元にするかを明示します。

仕組みが止まった日にも依頼を受け付けられる方法を用意します。復旧後に誰が番号と記録を照合するかを決め、二重登録を確認します。紙の廃棄を急ぐ前に、必要な保存条件と試行結果を管理担当へ確認します。

この章の根拠：出典2出典3

最初は修理受付票のように、後工程が明確な帳票を1種類選びます。番号、保存先、必要な欄を決め、通常の依頼と訂正・追加のある依頼で確認します。件数が少ない試行の結果は、対象範囲を限定して説明します。

紙の枚数だけでなく、資料を探す時間、聞き直し、保存漏れ、次工程への引き継ぎを記録します。検索が速くても更新が遅ければ、返答の負担は残ります。仕事の各工程を別に見て、次の改善を選びます。

経営者は、使える条件と残った条件を現場へ返します。全帳票へ広げる前に、保存条件や担当が違うものを整理します。ペーパーレスは、紙を減らす作業と後工程の情報をつなぐ設計を一緒に進めます。

この章の根拠：出典1出典2