フロントデスクで使える自転車修理ワークオーダートラッカー

受付で自転車修理のインテイクがよく破綻する理由

ほとんどの問題はカウンターの最初の3分で始まります。顧客が症状を説明している間に電話が鳴り、整備士が「次は何？」と聞きます。インテイクが付箋や写真、または半分しか書かれていないフォームに頼っていると、細かい情報がすぐに失われます。

欠けている情報が原因でトラブルになります。例えば「ブレーキがこすれる」とだけ書かれていて、どちらのブレーキか、ブランドか、静かさ重視か制動力重視かといったことが記録されていないと後で誰かが電話する羽目になり、バイクは置かれたままになり、預かり時にした約束が知らぬ間に変わってしまいます。

トラッキングがないとフロントデスクがボトルネックになります。質問があるたびにインテイクした人に戻る必要があり、整備士は明確な指示がないと作業を進められません。顧客も現在の状況を誰も信用できないために情報を得られなくなります。トラッカーは負担を増やすのではなく、圧力を取り除くためのものです。

小さなインテイクのミスが忙しい日にどう手戻りを生むか、例を挙げます：

• 連絡手段が確定していないため、引取通知が届かない
• 症状があいまいで再現できない
• “上限金額”がないため見積が気まずい電話に変わる
• 期限の約束がないため期待値がずれていく
• 部品のメモがないため発注が遅れる

良いトラッキングは落ち着いた感じです。スタッフが一つのワークオーダーを開くだけで、何が預けられたか、何を約束したか、何が部品待ちか、誰が最後に触ったかがすぐに見えます。顧客が「準備できた？」と聞いたとき、全員が同じ共有された真実から答えを得られます。

例：顧客が「ギアがたまに外れる」と言った場合、インテイクで「一番小さいスプロケットでのみ、最後の雨のライド後に起きる」とキャプチャしていれば、整備士はいきなり20分も試乗して推測する代わりにディレイラーハンガーとケーブルハウジングをまずチェックできます。

各ワークオーダーで何を記録するか

ワークオーダーは次の問いに答えるものでなければなりません：これは誰のためか、どのバイクか、何をするのか、いくらかかるのか、そして迅速にどう連絡するか。

まず顧客情報を押さえます：名前と連絡手段を2つ（テキストとメール、または電話とテキスト）。次に一つだけ好みを聞きます：「引取連絡はテキストか電話か？」この一択で見逃しや留守番電話の応酬を減らせます。

次にバイクの識別情報を確定します。同じ日に黒い Trek が二台来ることはよくある話です。混同を避け、トラブル時に双方を保護するために十分な情報を取っておきます：

• ブランド/モデル、色、可能ならフレームサイズ
• シリアル番号か受付時に付けたタグ番号
• 残されたアクセサリ（ライト、バッグ、コンピュータマウント、ロック）
• 引渡し時の状態メモ（既存のキズ、曲がったハンガー、欠品キャップなど）
• 簡単な写真セット（ドライブ側、目に見える損傷、シリアル）

症状の説明はまず顧客の言葉を書き、その後に短い技術者向けの変換を書きます。例：顧客が「後ろでゴリゴリ言う」と言ったら「おそらくリアディレイラーかカセット摩耗、チェーン伸びを確認」と追加します。これで後で整備士が始めたときの齟齬が減ります。

金銭と承認はチケットが停滞するポイントです。見積はレンジ（範囲）で記録し、”上限を超えたら電話”の設定と、どの権限の人が変更を承認できるか（顧客、パートナー、保護者など）を記録します。預かり金を取るならその金額と支払い方法もメモします。

最後にフロントデスク用の小さなメモ欄を残しましょう：約束した期限、通勤の都合（「月曜に必要」）、特別扱い（「洗わないで、カスタムペイント」）など。小さな詳細が大きな揉め事を防ぎます。

みんなが同じ認識を持てるステータス

ステータスは全員が同じ読み方をする時だけ機能します。例えば一人の整備士が「In progress」をベンチ上の何でもありに使い、受付は「ほぼ終わり」を意味するように使うと、顧客に間違った更新が届きます。

ほとんどの作業をカバーする小さなステータスセット

リストは短く、各ステータスが一つの意味を持つようにします：

• Received：チェックインしてタグ付け済み、まだ診断なし
• Diagnosing：検査中、必要作業を確認中
• Waiting on approval：見積送付済み、承認待ち
• Waiting on parts：部品到着待ちで作業停止中
• In progress：整備士が実際に作業中
• Ready for pickup：作業完了、精算待ち・引取可能
• Closed：バイクが店を出た

ステータスのずれを防ぐルール

ステータスは誰かが変更を管理しないと古くなります。シンプルなルールを決めて守ってください：

• 受付がインテイク時に Received を設定
• 整備士が作業開始時に Diagnosing と In progress を設定
• 受付が見積送付時に Waiting on approval を設定
• 部品担当または整備士が部品でブロックされたら Waiting on parts を設定
• 受付が顧客に連絡し引渡し時に Ready for pickup と Closed を設定

「保留」案件では理由が見えない曖昧なステータスは避けてください。代わりにブロッカーステータス（通常は「Waiting on approval」か「Waiting on parts」）を使い、短い理由メモを付けます（例：「顧客は金曜まで旅行中」「バックオーダー、1/25到着予定」）。これで案件は見える化され、検索やフォローアップがしやすくなります。

部品を混乱なく追跡する方法

部品はシンプルなチケットを推測ゲームに変えてしまいます。解決策は部品をワークオーダー内のミニワークフローとして扱い、整備士が何かを指摘した瞬間に更新することです。

フロントデスクが速やかに答えられるべき3つの質問：何の部品が必要か、どこにあるか、顧客に何を伝えたか。

各チケットに小さな「部品」テーブルを追加します。各行は一つの部品（「消耗品」や「ケーブルエンドキャップ」でも可）。これでブロッカーが一目でわかります。

一貫した部品ステータスを使いましょう：

• Needed（特定済み、未発注）
• Ordered（発注済み）
• Received（受領済み）
• Installed（取り付け済み）
• Returned（サイズ違い、重複、顧客辞退など）

各行に仕入先、ETA、単価、発注者を記録すれば中断が減ります。

代替品やバックオーダーは起こります。元の行を書き換えたり削除したりせず、元の部品は Returned（またはBackordered を使うならそのまま）とし、代替品は新しい行で追加、変更理由を記録します（例：「在庫のため顧客が別サイズのローターを承認」）。

部品遅延には短い顧客連絡メモを付け、可能ならタイムスタンプを残します。例：「火 15:10：Alexにチェーンがバックオーダーで金曜到着予定と伝え、到着後に作業して良いと了承済み。」

承認、見積、作業変更の扱い方

整備中にプランが変わることはよくあります。変更は可視化して承認を取り、引取時に顧客が驚かないようにしましょう。

「承認が必要」は一つの明確な意味で使います：価格や作業範囲が変わる前に止めて顧客へ連絡すること。トリガー例：総額が閾値を超える、チューニング中にチェーン交換が必要になった、安全上の発見、部品の代替など。

見積はシンプルに、でも追跡可能に

見積は数行（工賃、部品、手数料）と合計で保存します。変更が起きたら旧数字を上書きせず改訂を追加して、「何がどう変わったか」を記録します。受付は「何がどう変わったのか」を即答できるようになります。

基本構成：

• 元の見積（項目と合計）
• 改訂メモ（何が変わったか、その理由）
• 改訂後の総額（新しい上限）
• 承認履歴（誰が、いつ、どの方法で）

承認された内容を正確に記録する

「承認済み」だけでは不十分です。顧客が何に同意したか、金額や上限、誰がいつどのチャネルで承認したかを記録してください。例：「承認：リアブレーキパッドとケーブル交換、最大 $145（部品・工賃）。承認者：顧客名、日時、対面/電話/テキストの別」

驚きの請求を避けつつ作業を進めるには、受付時に「上限額を設定する」か「事前承認のバッファを許可する」いずれかを決めさせます。トラッカーが対応するなら、改訂が上限を超えたときは作業が進まないようフラグを立てられると便利です。

手順：預かりからクローズまで

トラッカーは全ての作業が同じ流れをたどるときだけ役立ちます。目的は簡単：必要な情報を一度で正しく取り、整備士の作業を止めず、顧客をノート探しに走らせないこと。

1) 引き取り：必須項目でワークオーダーを作る

顧客がその場にいる間にチケットを作成します。情報が新鮮で、誤りを訂正しやすいからです。基本（顧客名、電話、バイクのブランド/モデル/色）、顧客の言葉での問題点、依頼サービスを記録します。

また後で忘れやすいことも記録します：付けているアクセサリ、明らかなダメージ、簡単な安全メモ（例：「リアブレーキほとんど効かない」）。フォームを使うなら、忙しい日でも必須項目を強制するようにしましょう。

2) 計画、診断、承認、仕上げ

作業を小さな分かりやすいステップで前に進めます：

• 優先順位と現実的な納期目安（今日、明日、3–5日）を設定
• 診断は当日中にログし、受付が理解できるメモを残す
• 必要部品は数量と在庫状況を含めてすぐに記載

診断と部品が記録されたら、作業を広げる前に承認を取ります：

• 見積を送って決定（承認、辞退、上限付き承認）を記録
• 変更があれば平易な言葉でステータスを更新し短いメモを追加

3) チケットをきれいに閉じる

クローズ時はレシート兼引き継ぎメモのように記録します：作業内容の要約、実際に使った部品、支払い状況（支払済み、引取時精算、保証）。

きれいにクローズしておけば、翌週顧客から電話があってもフロントの誰でも数秒で対応できます。

引取通知と顧客への更新方法

多くの顧客不満は修理そのものではなく沈黙から生まれます。これを防ぐルールは一つ：デフォルトの連絡チャネル（SMS、メール、電話）を決め、顧客が別の希望を示さない限りそれに従うこと。

通知を発生させるイベントをいくつかに絞れば、チームの過剰な連絡を防ぎつつ顧客に安心を与えられます：

• 承認が必要なとき
• 部品遅延（発注、欠品、新しいETA）
• 引取準備完了
• 安全上の問題発見
• 一定時間応答なしの場合（フォローは1回まで、その後は保留）

テンプレートは短く、次のアクションを必ず含めます。どのスタッフも最後のメモを見れば次に何をすべきかがわかるようにします。

使える短いテンプレート例：

• 承認用：「こんにちは Taylor さん、修理は承認待ちです。合計 $89（パッド + 工賃）。進める場合は YES と返信してください。質問があればどうぞ。」
• 部品遅延：「お知らせ：ディレイラーがバックオーダーです。新しい到着予定は木曜です。そのまま待ちますか、それとも別案を相談しますか？」
• 引取：「お知らせ：作業完了しました。本日～18:00まで引取可能です。合計 $146。引取のご希望があれば返信ください。」

送信したメッセージ（試みた通話や留守電も含む）はすべてワークオーダーに記録します。これにより朝番から昼番への引き継ぎもスムーズです。

実用的な制限：重要な変化がない限り、1日1回以上の更新はしないほうが顧客に喜ばれます。

フロントデスク用のクイックチェックリスト

トラッカーはカウンターの習慣が強くないと意味がありません。以下のチェックリストでチケットを一貫させ、整備士が詳細を追いかける必要を減らします。

5分でできる引取チェック

店が混んでいても同じ順序で入力する習慣をつけます：

• 連絡先と最適な連絡方法（電話かテキスト）を確認し、明確な承認ルール（「最大 $X まで可」または「超える場合は要電話」）を決める
• 部品やフィットに関わるバイクの基本情報を記録する：ブランド、モデル、ホイールサイズ、特殊コンポーネント（e-bike システム、スルーアクスル、油圧ブレーキ）
• 顧客の言葉で症状を書き、検証できる短い補足を一つ追加（いつ起きるか、どのギアで起きるか、悪化する条件など）
• ステータスをすぐに設定し、担当者を割り当てる（「ショップ」ではなく具体的な技術者やサービスライター）
• 目安の期待日を追加（荒い目安でも良い）

作業中にチケットを健康に保つ方法

インテイク後の最大の遅延要因は部品と沈黙です。早めに部品レビューを行い、必要なもの、ETA をリストアップし、進行を阻むものは必ずブロッカーとしてマークします。ETA がずれたら期待日を更新し、顧客に最初に店から知らせるようにしましょう。

引取準備に移す前に必ず書いておくこと：最終テストのメモ（何をチェックして結果はどうだったか）と最終金額。価格が変わった場合、承認メモと一致していることを確認します。

引取時に支払いを記録し、保証やフォローアップメモを平易な言葉で残して当日中にチケットをクローズします。

遅延や顧客不満を生むよくあるミス

多くのフロントデスク問題は「腕の悪い整備士」から来るわけではありません。小さなワークオーダーの抜けやズレが積み重なって大きな驚きになります。

よくある罠の一つはステータスを増やしすぎることです。チームが「In queue」「Queued」「Waiting」「Waiting - parts」の違いを覚えられないと、適当なものを選んでしまい、2日後にはボードが信用されなくなります。

別の問題は整備士のメモが紙や付箋、誰かの記憶にだけ残ることです。顧客が「ローターもチェックした？」と聞いたとき、カウンターにいる人が自信を持って答えられないと信頼が落ちます。

引取時の争いは承認が記録されていないことが原因です。作業が「基本チューン」から「チューン＋ケーブル＋チェーン」へ変わった際に、誰がいつ何を承認したかが明確でないと顧客は不満を感じ、店が費用を負担する羽目になります。

部品は別の場所で追跡されると混乱を生みます（ホワイトボード、別スプレッドシート、テキストスレッドなど）。ワークオーダーには「Waiting on parts」とあるのに、どの部品か、どの仕入先か、ETA がいつか誰も答えられない、という状況です。

これらのパターンが仕事を静かに停滞させます：

• ステータスが多すぎて意味があいまい
• メモがチケットに残らないため更新が失われる
• 承認が記録されておらず引取で揉める
• 部品情報が別管理で「何を待っているか」答えられない
• 担当者が割り当てられておらずチケットが放置される

シンプルな対策：チケットごとに一人の担当者を割り当て（整備士が変わっても担当は明確に）、部品とメモは同じワークオーダー内に残し、アクションを促す少数のステータスに絞ることです。

例：部品遅延が発生したブレーキ作業の流れ

顧客が通勤用バイクで来て「フロントブレーキがキーキー鳴って制動が弱い」と言ったとします。フロントはワークオーダーを開き、顧客名と電話、バイクのブランド/モデル、預かり時間、顧客の言葉での症状を記録します。

整備士が簡易チェックをすると、原因はパッドの摩耗とローターの汚染・傷であることがわかりました。ワークオーダーに診断と作業計画（パッドとローター交換、キャリパー清掃、ベッドイン）を記録し、ステータスを Received から In progress に移します。

そこで問題発生：適合するローターがバックオーダーでした。チケットを半端な状態で放置する代わりに、受付はステータスを Waiting on parts にし、必要部品、仕入先、今日のETA（例：「ローター 160mm、ETA 金曜 14:00」）を記録します。これで顧客が電話してきても誰でも自信を持って答えられます。

受付が一目で分かる情報：

• 完了していること：診断完了、パッド取り外し、キャリパー清掃
• 未完了のこと：ローター交換と最終テストライド
• 保留理由：ローターがバックオーダー
• 期待到着日時：ETA 金曜 14:00
• 顧客に伝えた内容：「ETAが変わったらテキストします」

仕入先がETAを月曜にずらした場合、店は一回だけ明確な遅延連絡を送ります：「ローターが月曜に遅れました。お客様側での対応は不要です。準備ができ次第ご連絡します。」トラッカーにはそのメッセージと新しいETAを記録します。

月曜にローターが届き、整備士が作業を終えたらステータスは Ready for pickup に移り、顧客に引取通知（営業時間と残金）を簡潔に送ります。

次のステップ：実際に使えるトラッカーを設計する

フロントで本当に必要な情報を決めます。主に「見える化」（ここに何があるか、何が待っているか、何が終わったか）だけが目的なら、シンプルなボードやスプレッドシートで十分です。承認、部品発注、メッセージ管理、バイクごとの履歴が必要ならフルワークフローに近いツールが必要になります。

毎日使う最小限の項目で組み立て、1週間運用してみて本当に必要なものだけを追加するのが現実的です。

実用的な「まずは小さく始める」セットアップ例：

• 最小フィールド：顧客名、電話、バイクのブランド/モデル、シリアル（任意）、インテイクメモ、約束日、預かり金（ある場合）
• 部品欄：部品名、数量、仕入先、発注済み（はい/いいえ）、ETA
• ステータス：Received、Waiting on approval、In progress、Waiting on parts、Ready for pickup、Closed
• 所有権：誰が担当か、最終更新のタイムスタンプ

メッセージテンプレートは省略しないでください。短めのテンプレートを2～3個標準化して毎回使います。平易で具体的に：何が変わったか、顧客に何が必要か、次に何が起きるかを示します。

内部用のインテイク、部品追跡、承認、修理状況更新を一括で扱う共有アプリを作りたい場合、AppMaster（appmaster.io）はコーディング不要でカスタムワークフローを作れる一つの選択肢です。主な利点はすべてを一箇所にまとめて、受付とサービスエリアが同じチケットを見られることです。