工務店の施工事例サイト改善｜事例一覧から相談につなげる構成

工務店の施工事例サイトは、完成写真の保管に加え、相談準備を助ける役割を持ちます。読者が地域、住宅タイプ、暮らし方などの条件から候補を探し、個別事例で土地や要望に対する提案を理解し、自分の計画を整理する場所です。

写真の枚数が増えても、一覧の分類が分かりにくい、個別ページに判断材料がない、相談フォームへ見ていた事例が引き継がれない状態では、閲覧と相談が分断されます。この記事では、分類、一覧、個別ページ、関連リンク、写真許諾、相談受付、更新手順を解説します。一件の記事本文を作る際にも共通する土台です。

施工事例サイトの役割

施工事例サイトでは、写真を見る行動から相談準備までを段階に分け、それぞれに必要な情報を置きます。すべての読者が最初から工法や予算を決めているわけではないため、写真から入る人と条件から絞る人の両方を受け止めます。

工務店は、掲載件数や写真枚数だけでサイトを評価せず、読者が次の段階へ移れるかを確認します。一覧で条件が分かっても、個別ページに同じ条件が書かれていなければ比較はできません。個別ページを読んでも、関連する住宅商品や相談方法が分からなければ次の行動を選べません。

各事例には公開用の事例IDを付けます。事例IDは一覧カード、個別ページ、画像台帳、相談フォームで共通に使い、閲覧していた住宅を受付担当者へ伝えられるようにします。住所や施主名をIDへ含めず、公開情報と顧客情報を分けます。

サイトの目的も事前に決めます。写真の閲覧、特定地域の事例確認、商品理解、見学会予約、家づくり相談では、必要な導線が異なります。目的を一つに限定する必要はありませんが、各ページがどの行動を助けるかを決めておくと、一律の問い合わせボタンだけに頼らずに済みます。

目的と担当者を事例台帳へ記録し、公開後の確認先も社内で明確にします。

事例一覧の分類項目

一覧の分類は、 読者が使う条件と継続更新できる情報から選びます。分類を増やしすぎると一件しか表示されない一覧や、今後更新されないタグが増えるため、公開前に掲載件数と運用担当を確認します。

分類名はタグ辞書で管理します。たとえば平屋、平屋住宅、ワンフロア住宅が別のタグとして混在すると、同じ条件の事例が分散します。表示名、内部ID、定義、対象条件、除外条件、確認担当者を一つの表へまとめます。

地域分類は、対応地域と施工地を混同しないようにします。施工実績がある地域でも、現在は対応していない場合があります。反対に、対応地域でも公開できる施工事例がないことがあります。一覧には事例の施工地域を表示し、現在の対応範囲は別ページで確認できるようにします。

費用条件を分類に使う場合は、土地、外構、プラン作成、諸費用など何を含むかをそろえます。過去の建築時点の費用を現在の価格として受け取られないよう、時期と個別見積もりが必要なことを示します。条件を統一できない場合は、一覧の絞り込みに使わず個別事例の補足情報にします。

分類の採用は検索語だけで決めません。営業担当者が相談時に聞かれる条件、広報担当者が確認できる資料、今後追加する事例の見込みも合わせます。一定期間更新できない分類は、独立した一覧を残すより、関連事例へのリンクや本文内の表示へ戻します。

絞り込みと検索結果

絞り込み画面では、読者が選択条件、結果、解除方法を同じ画面で確認できるようにします。結果がゼロ件になったとき、理由や戻り方が分からない状態を避けます。

一覧カードには、個別ページで確認できる主要条件だけを載せます。地域、住宅タイプ、暮らし方、面積などを表示したら、リンク先でも同じ名称と値を使います。カードだけに強い表現を加え、詳細ページで説明できない状態を作りません。

スマホでは、絞り込み項目が画面を埋めて事例写真へ到達できないことがあります。初期状態ではよく使う条件だけを見せ、その他の条件を開閉できるようにします。適用前に選択中の条件を確認でき、適用後は結果の先頭へ移動するなど、実機で操作順を確かめます。

ゼロ件の場合は条件を自動で無視せず、該当事例がないことを明示します。そのうえで、近隣地域、似た住宅タイプ、条件を一つ外した結果を提案します。自社に事例がない条件を相談できるかどうかは営業責任者が確認し、対応できない相談へ安易に誘導しません。

並び順は新着や更新日など説明できる基準を使います。人気順を使う場合は閲覧数、相談数など何を基準にしたか、集計期間と重複アクセスの扱いを定めます。根拠を管理できない場合は人気という表示を避けます。

個別事例ページの情報

個別事例では、写真、土地、要望、提案、間取り、仕様、費用条件を同じ一件の情報として対応させます。写真と説明が別の住宅を指していたり、一覧カードと数値が違ったりすると、読者は自分の条件と比較できません。

各数値には対象を付けます。面積なら敷地面積、建築面積、延床面積を分け、性能ならどの計算や測定による値かを確認します。一件の性能値を自社の全住宅へ当てはめず、その事例で採用した条件として示します。

費用は建築時期と含む範囲が違うため、一覧で単純に比較させる前に定義をそろえます。公開できるのが価格帯だけの場合も、土地、外構、付帯工事、諸費用を含むかを説明します。現在の見積もりや同じ住宅の再現を約束する表現は避けます。

写真には、何を示す画像かが分かる説明を付けます。外観、玄関、LDKといった部位に加え、要望と提案の対応が分かる場合は、その関係を簡潔に示します。ただし、担当者の意図や施主の感想を広報担当者が推測して作りません。

個別事例の公開前には、広報、プラン担当または現場、営業の確認範囲を分けます。広報は表記とリンク、プラン担当や現場は仕様と提案、営業は相談条件と現在の対応範囲を確認します。修正日、確認者、次回確認日を事例台帳へ残します。

古い事例も公開価値がある場合は残せますが、現在の標準仕様や価格と混同させません。採用商品の終了、担当者の退職、対応地域の変更、見学受付の終了など、関連情報だけが古くなることもあるため、本文とリンクを別々に点検します。

関連ページとの接続

個別事例を読んだ後の疑問は人によって違います。同じ問い合わせボタンだけの案内を避け、次の疑問に合う関連ページを示します。

内部リンクは、事例だけでは答えきれない疑問へ置きます。たとえば断熱仕様に触れた直後なら性能ページ、プラン担当者の判断に触れた後ならスタッフページというように、リンク先との関係を説明します。

終了した見学会や販売を終えた商品へリンクが残らないよう、関連ページの公開状態を定期的に確認します。終了情報に代替ページがある場合は差し替え、ない場合はリンクと案内文を削除します。リダイレクトだけに頼ると、本文と遷移先の約束がずれることがあります。

同分類の事例を表示する場合も、関連性の基準を定めます。地域、住宅タイプ、暮らし方のどれが共通するかをラベルで示し、閲覧数だけのおすすめにしません。事例が少ない段階では、無理に自動表示せず、担当者が確認した関連事例を選びます。

写真と掲載許諾

施工事例で公開できる写真、間取り、地域、施主コメントの範囲は案件ごとに異なります。広報担当者は口頭確認だけで公開せず、事例IDにひも付く許諾台帳を管理します。

公開前には次を確認します。

• 表札や郵便物から個人を特定できない
• 車のナンバーや人物の顔を許諾範囲で処理した
• 窓の外や位置情報から詳細住所が分からない
• 間取り図に氏名や管理番号が残っていない
• 撮影者と画像の利用範囲を確認した
• 施主コメントを別の事例へ流用していない
• SNS用の許諾をサイト公開へ拡大解釈していない
• 撤回依頼を受けた際の担当者と期限が決まっている

画像を差し替えるときも、新しい写真IDと許諾範囲を確認します。元画像を上書きすると、過去にどこで使ったか追えなくなるため、加工履歴と掲載URLを残します。退職した担当者だけが許諾資料を持つ状態を避け、閲覧権限を定めた共有先で管理します。

相談フォームと事例ID

読者が相談フォームへ進んだとき、見ていた事例の情報が消えると、受付担当者は何に関心があったかを再度聞く必要があります。事例IDと直前ページを自動で引き継ぎ、相談内容と合わせて記録します。

事例IDは利用者にも確認できる形で表示し、送信完了画面と受付通知へ載せます。複数事例を比較している場合は、気になる事例を保存できる仕組みか、フォームで追加できる欄を用意します。自由記述だけに頼ると、表記の違いで集計できません。

フォーム項目は少なければよいとは限りません。受付に必要な情報を削ると、送信後の電話やメールが増えます。初回返信に必要な項目と、相談当日に聞ける項目を分け、入力完了、受付確認、来場、商談まで同じ案件IDで追います。

相談結果には、対象、対象外、追加確認、来場予定、保留などの状態を残します。サイト改善では送信数だけでなく、どの事例からどの相談が入り、受付後にどう進んだかを見ます。個人情報を含む営業記録と、Web担当者が見る集計データは権限を分けます。

電話相談にも、案内元の事例IDを記録します。電話ボタンを押した時点で受付へIDを渡せない場合は、ページ上に短いIDを表示し、電話で伝えられるようにします。経路が分からない相談は推測で事例へ割り当てず、不明として残します。

更新と改善の手順

全事例を同時に作り直す前に、分類辞書、必須情報、許諾、計測方法を決め、改善対象を固定します。変更履歴と対照条件を残します。

改善は次の順で進めます。

1. 公開中の事例URL、事例ID、更新日、閲覧状況を一覧にします。
2. 写真、地域、面積、仕様、費用条件、許諾の欠損を抽出します。
3. 読者が使う条件と社内で確認できる情報から分類辞書を作ります。
4. 重複タグ、一件だけの分類、今後更新できない分類を整理します。
5. 一覧カードと個別ページで表示する項目を対応させます。
6. 個別事例から商品、性能、スタッフ、見学会へのリンクを点検します。
7. 相談フォームへ事例IDと閲覧ページを引き継ぎます。
8. 変更前の画面、表示回数、個別閲覧、相談結果を保存します。
9. 対象事例と変更しない対照事例を決め、変更内容を一つに絞ります。
10. 公開後に表示崩れ、絞り込み、リンク、フォーム通知を実機で確認します。
11. 一覧表示から受付結果までを対象と対照で同じ期間観測します。
12. 維持、再改善、統合、非公開を決め、判断理由を履歴へ残します。

表示回数が少ない事例は、内容を長くする前に、検索対象になっているか、一覧と関連ページから到達できるかを確認します。一覧表示はあるのに個別閲覧が少ない場合は、写真、名称、主要条件の不足を見ます。個別閲覧はあるのに相談へ進まない場合は、関連情報、相談内容、現在の対応範囲が分かるかを点検します。

相談完了が増えても、対象外や確認不能が増えた場合は成功と確定しません。事例ID、建築予定地、相談内容が受付へ届いているか、営業結果が記録されているかを確認します。計測欠損が多い期間は、文章やデザインの効果判断より記録方法の修正を優先します。

観測中にサイト全体のナビゲーション、広告配信、相談フォームを変更した場合は、同じ実験として扱わず変更日を記録します。季節、見学会、施工事例の追加など外部条件も残し、少数の相談率だけで横展開を決めません。

施工事例サイトの改善は、写真を増やす作業で終わりません。探せる分類、比較できる個別情報、疑問に合う関連ページ、事例ID付きの相談受付をつなぎ、変更履歴と対照条件を残すことで、どの構成が相談準備に役立ったかを判断できます。