この記事でわかること

• なぜサロンのデータは散らばり属人化するのか — 「予約チャネルの分散」「カルテの属人化」「売上が月末まで見えない」の3つの構造問題
• Lark で組むサロン運営の全体設計 — 顧客カルテ・来店履歴・スタッフ・売上を連結する「サロン一元化モデル」の作り方
• ホットペッパー・LINE・電話・Instagram の予約チャネルを、専用予約システムを捨てずに Lark で束ねる守備範囲の切り分け
• 失客を「気づいたら来なくなっていた」から「一定期間空いたら自動で検知」に変えるオートメーション設計と、売上をダッシュボードで毎日見る方法
• 専用サロン管理システムとの中立な使い分け基準、料金の一次情報（20名まで無料／Pro ¥1,420）、90日の段階導入ロードマップ

目次

1. 結論 — 予約システムは残していい。「予約の外」を Lark で束ねよ
2. なぜサロンのデータは散らばり属人化するのか — 3つの構造問題
3. Lark で組むサロン運営の全体設計 — 顧客カルテ連結モデル
4. 予約チャネルをどう束ねるか — ホットペッパー・LINE・電話・Instagram と Lark の分担
5. 顧客カルテの脱・属人化 — 施術履歴・薬剤・好みを「店の資産」にする
6. 失客管理を仕組み化する — 来店間隔を自動検知して再来店を促す
7. スタイリスト別売上・指名・店販を可視化する — ダッシュボード
8. スタッフのシフト・連絡・教育を Lark に集約する
9. 料金の一次情報 — 10名のサロンでいくらかかるか
10. 自社事例 — 「仕入れて売る」業務を Lark に集約して240h→24h
11. 90日で立ち上げる現実的3ステップ
12. よくある質問（FAQ）
13. まとめ — サロン経営を「人の記憶」から「店の仕組み」へ

結論 — 予約システムは残していい。「予約の外」を Lark で束ねよ

結論を先に述べます。美容室・サロンが「DX したい」と考えたとき、いま使っているホットペッパービューティーや LINE、電話予約を捨てる必要はありません。DX の本丸は、予約が入った「その先」——顧客カルテ・失客管理・スタイリスト別売上・スタッフ連絡が、紙とスタッフの記憶と別々のアプリに散らばっている状態を、Lark で1つに束ねることです。理由は3つあります。第一に、サロン経営の資産は「予約枠」ではなく「顧客との関係の記録」であり、それは施術履歴・好み・失客兆候といったデータの連結で守られるから。第二に、専用のサロン管理システムを新たに導入すると月額と乗り換えコストが積み上がるのに対し、Lark なら顧客カルテのデータベースとチャット・通知・シフト共有が同じアプリの中にあるから。第三に、「システムに入力したのに連絡は LINE、共有は口頭」という二度手間が、Lark 一本化で消えるからです。

本記事の立ち位置をはっきりさせておきます。世の中の「サロン DX」記事の多くは、予約管理システムや POS レジの製品紹介です。それらが有効な場面は確かにあります（後述の使い分け基準で中立に整理します）。しかし、中小企業白書が繰り返し指摘するとおり、中小企業（小規模サロンを含む）の DX を阻む二大要因は「人手不足」と「コスト負担」です。専任の担当者がいないサロンが、いきなり高機能なシステムと乗り換え作業を抱えるのは重すぎる。だからこそ、まず「いま紙とスタッフの記憶でやっていることを、そのまま共有データベースに載せ替える」ところから始め、足りなければ専用システムを検討する——この順番が現実解です。判断の軸は次の3問です。

この3問に「紙・頭の中／気づいたら／月末まで見えない」と答えた店ほど、本記事のモデルが効きます。Lark Base そのものの基礎は姉妹記事 Lark Base が中小企業の業務効率を変える3つの理由 に、DX 全体の進め方は 中小企業の DX を 90 日で軌道に乗せる実践ロードマップ にまとめています。本記事はその「美容室・サロンの予約の外側」への具体適用編です。予約・カルテ・失客という構造は歯科・治療院とも共通するため、歯科医院の DX の実装も参考になります。

なぜサロンのデータは散らばり属人化するのか — 3つの構造問題

結論として、サロンのデータが散らばり属人化するのは、店長やスタッフの怠慢ではなく、「集客チャネルが複数あり、接客が人に強く紐づく」というサロン固有の構造が原因です。この構造から、次の3つの問題が同時に発生します。

構造問題	現場で起きること	経営に効いてくる損失
① 予約チャネルの分散	ホットペッパー・LINE・電話・Instagram DM から予約が入り、紙の台帳やスタッフの記憶で突き合わせ	ダブルブッキング、連絡漏れ、顧客データが集約されない
② 顧客カルテの属人化	施術履歴・薬剤・好み・会話メモが手書きカルテや担当者の記憶に存在	担当スタイリストの退職で顧客ごと失う。指名客が引き継げない
③ 数字が月末まで見えない	スタイリスト別売上・指名率・店販比率・失客が、月末集計まで把握できない	打ち手が後手に回る。失客に気づくのが3ヶ月後

損失は感覚ではなく計算できます。たとえば失客の見落とし。客単価 8,000 円・来店サイクル 2 ヶ月のお客様が「なんとなく来なくなる」と、年間で約 4.8 万円の売上が静かに消えます。こうした「サイレント失客」が月に 5 人いれば、年間で約 288 万円が気づかないうちに失われている計算です——新規集客の広告費を積む前に、まず取りこぼしを止めるべき金額です。そして重要なのは、この3つが独立ではなく連鎖していることです。予約チャネルが分散するから顧客データが1ヶ所に集まらず、集まらないからカルテが属人化し、属人化しているから「誰がいつ最後に来たか」が見えず失客に気づけない。つまり「予約」「カルテ」「売上」を別々のツールで直しても解決せず、1つのデータベースの中で連結して初めて解ける構造です。IPA「DX動向」が示すとおり、日本の中小企業の DX は「ツールを個別に入れる」段階で止まりがちですが、サロンで本当に必要なのは個別ツールではなく顧客データの連結です。次章で、その連結の設計図を示します。

Lark で組むサロン運営の全体設計 — 顧客カルテ連結モデル

結論として、美容室・サロンの運営は「顧客マスタ」「来店・施術履歴」「スタッフ」「売上明細」の4テーブルを Lark Base 上で連結する構成で、店の背骨が完成します。Lark Base はテーブル同士をリンクフィールドで参照し合える業務データベースで、紙のカルテや Excel と決定的に違うのは「同じお客様・同じスタッフを、全テーブルが1つのマスタを参照して使う」点です。名前を毎回書き写さないので、表記ゆれと転記ミスが構造的に消えます。

テーブル	持たせるフィールドの例	連結先
① 顧客マスタ	氏名／連絡先／初回来店日／担当スタイリスト／会員区分／来店経路（HPB・LINE・紹介 等）	来店履歴（1顧客 → 多来店）
② 来店・施術履歴（カルテ）	来店日／顧客（リンク）／担当（リンク）／メニュー／使用薬剤・カラーレシピ／所要時間／写真／次回提案	①③を参照、④へ売上を発生
③ スタッフ	氏名／役職（スタイリスト・アシスタント）／指名対応可否／勤務店舗／時給・歩合条件	来店履歴・売上明細を参照
④ 売上明細	日付／顧客（リンク）／担当（リンク）／技術売上／店販売上／指名の有無／支払方法	①②③を参照。集計で各種KPIを算出

設計のポイントは3つです。第一に、顧客の好み・薬剤レシピはカルテ（来店履歴）に時系列で積み上げること。「この人はいつも○○」という担当者の頭の中の知識が、テーブルの1行になった瞬間に属人化が解けます。第二に、売上は月末に電卓で集計するのではなく、施術1件ごとに売上明細として記録し、集計で自動算出すること。誰がいつ何を売ったかが履歴として残るため、スタイリスト別・メニュー別・指名/フリー別の分析が後からいくらでもできます。第三に、顧客マスタに「最終来店日」を持たせ（または来店履歴から最新日を参照し）、失客検知の起点にすること。これが次章以降の自動化の土台になります。紙カルテや Excel からの載せ替えは CSV インポートで始められます。手順は Lark Base 脱Excel 30日チャレンジ に詳しくまとめています。

予約チャネルをどう束ねるか — ホットペッパー・LINE・電話・Instagram と Lark の分担

結論として、予約集客のチャネル（ホットペッパービューティー・LINE・電話・Instagram）はそのまま使い続け、Lark は「予約が入った後の顧客データを受け止める器」として使うのが、現実的で失敗しない分担です。集客サイトには集客サイトの強みがあり、それを Lark で置き換えようとすると無理が出ます。守備範囲を切り分けましょう。

領域	担うもの	Lark の役割
新規集客・オンライン予約	ホットペッパー等の予約集客サイト／自店の予約システム	置き換えない。既存を継続
顧客との個別連絡	LINE 公式アカウント・電話・Instagram DM	継続。ただし「誰が対応したか」の記録は Base に残す
顧客カルテ・施術履歴	紙カルテ・スタッフの記憶	Lark Base に集約（本記事の中核）
失客検知・再来店促進	誰もやっていない／担当者の勘	Lark オートメーションで自動化
スタッフの連絡・共有・シフト	スタッフ個人の LINE グループ・口頭	Lark チャット・カレンダーに集約

ここでのコツは、予約の入口を無理に一本化しないことです。卸売業の受発注をフォームに寄せる話とは事情が違い、サロンの新規客はホットペッパーの検索・口コミ・ネット予約に強く依存しています。集客サイトを外すと新規が細るリスクがあるため、入口はそのまま、その先の顧客データだけを Lark に流し込むのが安全です。具体的には、来店したお客様の情報を受付でカルテ（来店履歴）に1行入力する運用から始めます。再来店客であれば顧客マスタから選ぶだけ、新規客なら1行追加するだけ。この「受付での1行入力」が、予約チャネルの分散を吸収して顧客データを1ヶ所に集める最小の一手です。なお、社内向けの申込みや問い合わせ（法人ヘアメイク依頼、スタッフ採用応募など）を受ける場合は、Lark Base のフォームビューが有効です。公式ヘルプには「フォームの共有を有効にすると、フォームのリンクが生成され、リンクを受け取ったユーザーなら誰でも回答・送信でき、回答結果は対応するテーブルに自動追加される」と明記されており（Lark公式ヘルプ「Base でフォームビューを使用する」、2026年8月確認）、相手が Lark を使っていなくてもブラウザから入力でき、QR コード共有にも対応しています。

顧客カルテの脱・属人化 — 施術履歴・薬剤・好みを「店の資産」にする

結論として、サロン経営で最も守るべき資産は顧客カルテであり、これを「担当スタイリストの記憶」から「店の共有データベース」に移すことが、DX の実質的な本丸です。理由は明確で、手書きカルテやスタッフの記憶に依存していると、そのスタイリストが辞めた瞬間に、施術履歴・薬剤レシピ・会話の積み重ね・次回提案の文脈がすべて失われ、指名客ごと他店に流出するからです。これはサロン経営で最大級の損失です。

Lark Base のカルテ（来店履歴テーブル）に移すと、次のことが可能になります。第一に、カラーレシピや使用薬剤を毎回テキスト・数値で記録し、次回に別のスタッフが担当しても同じ仕上がりを再現できる。第二に、仕上がり写真を添付フィールドに保存し、ビフォーアフターや「前回の色味」を画面で見せながらカウンセリングできる。第三に、「次回はこのメニューを提案」というメモを残すことで、担当が代わっても提案の連続性が保たれる。そして Lark は業務データベースとチャットが同じアプリなので、カルテのレコードから直接そのお客様に関するスタッフ間の相談ができ、「あの人のカラー、次どうする？」という会話が紙のメモではなくデータに紐づいて残ります。

権限設計も重要です。顧客の個人情報や施術履歴はセンシティブなので、Lark Base の権限機能で「スタッフは自店の顧客のみ閲覧・編集可、他店の顧客は不可」「連絡先など一部フィールドは店長のみ閲覧可」といった制御をかけられます。権限とセキュリティの設計は Lark のセキュリティ・権限設計 で詳しく解説しています。カルテがデータになると、退職リスクへの耐性が生まれるだけでなく、「客単価が高いのに来店間隔が空いてきた常連」「初回から店販を一度も買っていない層」といった、紙では絶対に見えなかった切り口で顧客を捉え直せるようになります。これが次の失客管理と売上可視化に直結します。

失客管理を仕組み化する — 来店間隔を自動検知して再来店を促す

結論として、失客対策の本質は「気合いのある声かけ」ではなく、「一定期間来店のないお客様を自動で洗い出す仕組み」を持つことです。前章までで顧客マスタに最終来店日が入っていれば、この仕組みは Lark で組めます。Lark Base のオートメーションは「トリガー条件と実行操作から構成される機能」で、レコードの追加・更新や指定した日時・繰り返しスケジュールをトリガーに、Lark メッセージ送信・メール送信などを自動実行できます（Lark公式ヘルプ「Base のオートメーションを使用する」、2026年8月確認）。

サロンの失客管理で効くレシピは、たとえば次のように組みます。まず来店履歴が更新されるたびに顧客マスタの最終来店日を最新化し（またはロールアップで自動算出し）、定期実行のオートメーションで「最終来店日から○日以上経過し、かつ失客フラグが立っていない顧客」を毎朝抽出する。抽出された顧客は「フォロー対象」ビューに自動で並び、担当スタイリストの Lark に「Aさん、前回来店から70日です。フォロー連絡を検討してください」と通知が飛ぶ。スタッフは通知から顧客カルテへ直接ジャンプし、前回の施術内容と次回提案メモを見た上で、LINE や電話でパーソナルなフォローをかけられます。ポイントは、連絡そのものを全自動化するのではなく、「連絡すべき相手を自動で見つける」ところまでを仕組みにすることです。サロンの再来店は関係性の商売なので、機械的な一斉配信より、担当者が文脈を持って声をかける方が効きます。

トリガー	自動実行	止まる取りこぼし
毎朝、最終来店から一定日数を超えた顧客を抽出	担当スタイリストにフォロー候補として Lark 通知	サイレント失客（気づいたら来なくなっている）
来店履歴に新規レコードが追加された	受付・関係スタッフのグループに来店を通知	情報共有の抜け・引き継ぎ漏れ
予約日の前日になった	担当スタッフに翌日の担当予約をリマインド	確認漏れ・準備不足
誕生月・初回来店から1年 等の節目	担当スタッフに特別フォローの提案通知	関係を深める機会の逸失

ここで効いてくるのが、Lark は業務データベースとチャットが同じアプリであるという構造です。通知は普段使っているチャットにそのまま届き、通知から該当顧客のカルテへ直接ジャンプできます。kintone や Notion のようにデータベースと通知チャットが別ツールだと、この連携自体を設定・保守し続ける必要があります（比較の詳細は Lark vs kintone 徹底比較・Notion vs Lark Base 参照）。オートメーションの実行回数はプランごとに月間上限があり（Starter 1,000回／Pro 5万回／Enterprise 50万回、Lark公式料金ページ、2026年8月確認）、失客通知・来店通知が中心の小規模サロンなら Starter の 1,000 回でも検証には十分、本稼働は Pro が現実的です。オートメーションの具体レシピは Lark 自動化10レシピ でも扱っています。

スタイリスト別売上・指名・店販を可視化する — ダッシュボード

結論として、売上管理の目的は「月末に合計を出すこと」ではなく「今日の時点で、誰が・何を・どれだけ売っているかが見えること」であり、これは売上明細を Base に貯めてダッシュボードで見るだけで手に入ります。前章までの4テーブルモデルで、施術ごとに売上明細（技術売上・店販売上・指名の有無・担当）を記録していれば、集計はすべて自動です。

Lark Base のダッシュボード機能を使えば、売上と顧客の状況をグラフで常時表示できます（Lark公式ヘルプ「Base でダッシュボードを使用する」、2026年8月確認）。サロンでまず置くべきブロックは次の5つです。

• メトリックカード：今月の総売上・客単価・指名率・店販比率。オーナーが毎朝スマホで見る数字。
• 横棒グラフ（スタイリスト別売上）：技術売上・店販売上を担当別にランキング。評価・歩合の根拠にもなる。
• 円グラフ（メニュー構成比）：カット・カラー・パーマ・トリートメントの比率。単価改善の余地を見る。
• 折れ線（新規/リピート推移）：新規客とリピート客の月次推移。集客と定着のバランスを把握。
• グリッドのビューブロック（フォロー対象一覧）：失客候補の顧客リスト。毎朝ここを見てフォローに動く。

紙の売上表や POS の締めレポートと決定的に違うのは、スマホからいつでも、追加費用ゼロで、同じ最新の数字をオーナーもスタッフも見られることです。スタイリスト本人が自分の指名率や店販比率を毎日見られると、行動が変わります。ダッシュボードの作り方・全ブロックの種類・スマホ対応は Lark Base ダッシュボードで経営数字を可視化する2026 で網羅しています。複数店舗を運営している場合は、店舗横断で数字を束ねる設計を 多店舗運営の店舗オペレーション統合 にまとめています。

スタッフのシフト・連絡・教育を Lark に集約する

結論として、サロン運営の「予約・カルテ・売上」以外の日常業務——シフト調整・スタッフ間連絡・技術教育・店舗マニュアル——も、同じ Lark の中に置くことで、はじめて「一元化」が完成します。データベースだけ Lark にしても、連絡が個人 LINE、シフトが紙、マニュアルが誰かの Google ドライブ、では散らばりは解消しません。

業務	Lark の機能	変わること
シフト管理	Base（シフト希望テーブル）＋カレンダー	希望提出・確定・共有が1画面。急な交代も履歴で追える
スタッフ連絡	グループチャット（店舗別・全社）	個人 LINE と仕事の連絡が分離。退職者を外すのも一括
技術教育・研修	Docs・動画共有・Wiki	カット手順・接客動画を一元管理。新人の立ち上がりが速い
店舗マニュアル	Wiki（ナレッジベース）	「どこにあるか分からない」が消える。検索で一発

特にサロンは離職と採用の入れ替わりが起きやすい業種です。連絡・教育・マニュアルが個人アプリや口伝ではなく Lark に集約されていれば、スタッフが入れ替わっても店のノウハウが残り、新人が最短で戦力になる。個人 LINE でのやり取りに依存していると、退職者との情報の切り離しも、業務連絡の履歴確認も難しくなります。Wiki を使ったナレッジ蓄積の手順は Lark Wiki で社内ナレッジを30日で立ち上げる に、コミュニケーション基盤としての比較は Lark vs Microsoft Teams 徹底比較 にまとめています。

専用サロン管理システムとの違い — 内製をいつ選び、いつ選ばないか

結論として、Lark Base 内製と専用サロン管理システム（予約・POS・顧客管理一体型）は競合ではなく守備範囲が違います。「予約は既存の集客サイトで足り、その先のカルテ・失客・売上・スタッフ運営を柔軟に組みたい店」は Lark 内製が合い、「予約・レジ・電子カルテ・在庫・会計まで1台で完結させたい店」は専用システムが合います。中立に整理します。

観点	Lark Base 内製	専用サロン管理システム
初期コスト・スピード	低い。テーブル設計から数週間で運用開始。20名までは無料プランで検証可	月額＋初期設定費が発生しがち。機能は最初から揃う
自店の運営への適合	フィールド・自動化を自分で追加。カルテ項目・失客ルール・歩合条件に柔軟	標準機能に運用を合わせる。細かな独自ルールは対応外のことも
予約・レジ・会計	予約・POS レジ・会計は守備範囲外。既存の集客サイト・会計ソフトと併用	予約・レジ・売上・在庫・会計連携まで一体で完結が多い
コミュニケーション・教育	チャット・シフト・Wiki・ビデオ会議と同一アプリ。スタッフ運営ごと集約	顧客管理が中心。スタッフの連絡・教育は別ツール
データ量の上限	1テーブルの行数はプラン依存（後述）。大規模チェーンは設計に注意	サロン用途の想定内なら上限を気にしにくい

目安として、①予約・レジ・電子カルテ・在庫・会計までを1つのシステムで完結させたい、②複数店舗で数万件規模の顧客・売上を厳密に管理したい、③POS 連携での自動売上計上が必須——のいずれかに強く該当するなら、専用サロン管理システムを検討すべきです。逆に、予約は既存の集客サイトで回っていて、困っているのが「カルテの属人化」「失客の見落とし」「売上が月末まで見えない」「スタッフ連絡の散らばり」なら、Lark 内製で店の背骨は組めます。そして重要なのは、内製で始めても無駄にならないことです。顧客データの整備・運用ルールのデータ化・スタッフの入力習慣という「DX の土台」は、将来専用システムに移る場合でもそのまま資産になります。ツール選定の考え方全般は Salesforce・Notion・kintone・Lark の使い分け でも整理しています。

料金の一次情報 — 10名のサロンでいくらかかるか

結論として、Lark は 20 ユーザーまで無料の Starter プランがあり、スタッフ 20 名以下のサロンなら無料で始められます。本稼働で有料化する場合も、10 名なら Pro プラン（1ユーザー月額 ¥1,420・税抜・年払い）で月額 ¥14,200 が目安です。Lark公式料金ページ（2026年8月14日確認）の一次情報を整理します。

プラン	料金（税抜）	ユーザー上限	Base 行数上限/テーブル	オートメーション/月
Starter	¥0	20 名	2,000 行	1,000 回
Pro	¥1,420／ユーザー・月（年払い）	500 名	2 万行	5 万回
Enterprise	要お問い合わせ（個別見積）	無制限	5 万行	50 万回

出典: Lark公式料金ページ（2026年8月14日確認）。Starter のユーザー上限は 2025 年 3 月 1 日の改定で 50 名から 20 名に変更されています。料金・上限は変更される場合があるため、最新は公式ページでご確認ください。

サロンで気をつけるべきは行数上限です。来店履歴（カルテ）テーブルは1来店＝1行で増えるため、月 400 来店の店なら年間 4,800 行。無料の Starter（2,000 行/テーブル）は小規模店の検証・立ち上げ用と割り切り、来店数が多い店や本格運用は Pro（2 万行/テーブル）を前提にするのが安全です（年度ごとにテーブルを分ける、過去分をアーカイブへ移す設計で長期運用にも対応できます）。一方、スタッフ数名の個人サロンで来店履歴が年 2,000 行に収まるなら、Starter 無料で本稼働まで視野に入ります。そして 10 名で月 ¥14,200——専用サロン管理システムの多くが「顧客管理・予約」に特化して同価格帯以上を課金するのに対し、Lark はこの金額に顧客カルテだけでなくチャット・シフト・ビデオ会議・ドキュメント・Wiki まで含まれるため、スタッフの連絡ツールや情報共有ツールの置き換えと合算で判断すると、実質コストはさらに下がります。プラン選定の詳細は Lark 料金完全ガイド2026 をご覧ください。

自社事例 — 「仕入れて売る」業務を Lark に集約して240h→24h

結論として、「顧客と接し、記録し、売上を管理し、スタッフと連絡する」業務を Lark に集約すると劇的に軽くなることは、当社自身が自社事業で実証済みです。月 240 時間かかっていたバックヤード業務が 24 時間、90% の削減になりました。当社（アウフヘーベンジャパン株式会社・群馬県前橋市）は Lark コンサルティングと並行して自社の物販事業（4 チャネル・約 200 SKU）を運営しています。業種はサロンと違いますが、「顧客対応が複数チャネルに散らばる」「連絡と記録が別アプリに分かれる」「数字が集計待ちで見えない」という悩みの構造はサロンと同じでした。

正直に書くと、当社の場合、受注処理そのものは EC 一元管理 SaaS でほぼ自動化できていました。手作業のまま残っていたのはその上のオペレーション層——顧客対応が LINE・メール・各モールに分散して月 72 時間、売上分析・販促判断の材料づくりが Excel 6 シートで月 36 時間、倉庫との連絡が LINE とメールで月 30 時間——という、サロンの「予約の外側」とまさに同じ構造の仕事でした。Lark への集約でこれらが激減した理由を、サロンに引き付けて言えば3点です。第一に、顧客データが Base に、連絡が同じアプリのチャットに一元化され「ツール間の往復と転記」という工程が消えたこと。第二に、売上・顧客実績が同じ Base にあるため判断が集計待ちゼロで即断できるようになったこと。第三に、通知の自動化で「人が思い出して連絡する」仕事がなくなり、取りこぼしの後始末に使っていた時間が消えたこと。全内訳と実装の詳細は 自社事業を Lark に集約して月240時間を24時間にした話 で公開しています。削減の主因は高度な AI ではなく、本記事で述べた「マスタ参照・履歴主義・自動検知」という地味な構造化でした。だからこそ、同じ「顧客商売」の構造を持つサロンで再現性が高いと考えています。

90日で立ち上げる現実的3ステップ

結論として、サロンの Lark 一元化は「30日で顧客カルテ、60日で売上と失客検知、90日でスタッフ運営」の3段階で立ち上げるのが現実的です。一気に全部を作らないことが定着の条件です。

1. Day 1–30｜顧客マスタとカルテの載せ替え：顧客マスタ・スタッフを紙／既存システムから CSV インポートで移行。来店履歴（カルテ）テーブルを作り、受付での「1来店＝1行入力」の運用を開始。薬剤レシピ・好み・写真をこの30日で貯め始める。この30日が全体価値の半分を占めます。
2. Day 31–60｜売上明細とダッシュボード、失客検知：施術ごとの売上明細（技術・店販・指名）を記録開始。ダッシュボードにメトリックカードとスタイリスト別売上を設置。最終来店日をもとに失客候補を毎朝抽出するオートメーションを設定。
3. Day 61–90｜スタッフ運営の集約：シフト・スタッフ連絡・技術教育・店舗マニュアルを Lark（Base・チャット・Wiki）へ移す。個人 LINE 依存の業務連絡を店の Lark に一本化し、「人の記憶」から「店の仕組み」への移行を完成させる。

90 日ロードマップの汎用版（推進体制・スタッフの巻き込み方・失敗パターン）は 中小企業の DX を 90 日で軌道に乗せる実践ロードマップ に、導入がつまずく典型パターンは Lark 導入失敗の3パターン にまとめています。予約・カルテ・失客という隣接業種の実装は 歯科医院の DX、店舗運営の統合は 多店舗運営の店舗オペレーション統合 が参考になります。

よくある質問（FAQ）

Q1. 予約はホットペッパービューティーで回っています。Lark に置き換える必要がありますか？

いいえ。置き換える必要はありません。本記事の提案は、ホットペッパー等の集客・予約システムはそのまま使い続け、Lark は「予約が入った後」の顧客カルテ・失客管理・売上・スタッフ連絡を束ねる役割に使う、という分担です。集客サイトには新規集客の強みがあり、そこは既存を活かすのが安全です。困っているのが「カルテの属人化」「失客の見落とし」「数字が月末まで見えない」なら、そこだけを Lark で解決できます。

Q2. 顧客カルテをデータベース化すると、スタイリストが辞めても情報は残りますか？

はい。それがカルテをデータベース化する最大の目的です。施術履歴・薬剤レシピ・好み・仕上がり写真・次回提案メモを Lark Base の来店履歴テーブルに記録しておけば、担当スタイリストが退職しても情報は店に残り、別のスタッフが同じ仕上がりを再現しながら引き継げます。手書きカルテや個人の記憶に依存している状態こそ、退職時に指名客ごと失う最大のリスクです。

Q3. 失客の自動検知は具体的にどう動きますか？

顧客マスタに「最終来店日」を持たせ、定期実行のオートメーションで「最終来店から一定日数を超え、まだフォローしていない顧客」を毎朝抽出し、担当スタイリストの Lark に通知します。連絡そのものは自動化せず、「連絡すべき相手を自動で見つける」ところまでを仕組みにするのがコツです。担当者は通知からカルテへジャンプし、前回内容を踏まえてパーソナルにフォローできます（Lark公式ヘルプ、2026年8月確認）。

Q4. 費用はどのくらいかかりますか？

Lark は 20 ユーザーまで無料の Starter プランがあり、スタッフ 20 名以下のサロンなら無料で始められます。有料化する場合は Pro プラン（1ユーザー月額 ¥1,420・税抜・年払い）が目安で、10 名なら月額 ¥14,200 です。この金額に顧客カルテ（Base）だけでなくチャット・シフト・ビデオ会議・ドキュメント・Wiki も含まれます（Lark公式料金ページ、2026年8月14日確認）。

Q5. 来店データが増えると上限に当たりませんか？

Base の1テーブルあたり行数上限はプランごとに Starter 2,000 行／Pro 2 万行／Enterprise 5 万行です（Lark公式料金ページ、2026年8月確認）。月 400 来店なら来店履歴は年間約 4,800 行のため、来店数が多い店や本格運用は Pro を前提にするのが安全です。年度ごとにテーブルを分ける・過去データをアーカイブテーブルへ移すといった設計で、長期運用にも対応できます。

まとめ — サロン経営を「人の記憶」から「店の仕組み」へ

本記事の要点を整理します。

• サロンのデータが散らばり属人化するのは、集客チャネルが複数あり接客が人に紐づく構造が原因。「予約チャネルの分散」「カルテの属人化」「数字が月末まで見えない」の3問題は連鎖しており、個別ツールではなく顧客データの連結でしか解けない。
• 予約集客システムは残していい。Lark は「予約の外側」（顧客カルテ・失客・売上・スタッフ運営）を束ねる器として使う。
• Lark Base の顧客カルテ連結モデル（顧客マスタ・来店履歴・スタッフ・売上明細）で店の背骨を作る。好みはカルテに、売上は明細に、最終来店日は失客検知の起点に持たせる。
• 失客はオートメーションで自動検知し、担当者が文脈を持ってフォローする。売上はダッシュボードで毎日見る。スタッフの連絡・シフト・教育も Lark に集約して一元化を完成させる。
• 費用は 20 名まで無料、10 名の本稼働で月 ¥14,200（Pro・税抜）。専用サロン管理システムとは中立な使い分けで判断し、90 日の3段階で立ち上げる。

当社は自社事業で顧客対応・記録・売上・連絡を Lark に集約し、月 240 時間 → 24 時間（90% 削減）を実証しました。同じ「顧客商売」の構造を持つサロンは、このモデルが素直に効く業種のひとつです。まずは「顧客カルテが今どこにあって、失客に誰がいつ気づいているか」を書き出すところから始めてください。

関連記事

• Lark Base が中小企業の業務効率を変える3つの理由 — 顧客カルテ一元化の土台となる業務DBの実力。
• 自社事業を Lark に集約して月240時間を24時間にした話 — 本記事のモデルの実証元。
• 歯科医院の DX を Lark で進める — 予約・カルテ・失客という同構造の隣接業種の実装。
• 多店舗運営の店舗オペレーション統合 — 複数店舗のサロンで数字を束ねる設計。
• Lark Base ダッシュボードで経営数字を可視化する2026 — 売上・指名率をグラフで毎朝見る方法。
• Lark 自動化10レシピ — 失客検知・通知の具体的な組み方。
• Lark Base 脱Excel 30日チャレンジ — 紙カルテ・Excel からの移行手順。
• Lark vs kintone 徹底比較 — 業務DB型ツールの比較検討に。
• Lark vs Microsoft Teams 徹底比較 — スタッフの連絡基盤の選定に。
• 中小企業の DX を 90 日で軌道に乗せる実践ロードマップ — DX 推進の全体像。
• Lark Base 業務システム構築サービス — カルテ設計から運用定着までの伴走。
• アウフヘーベンジャパン株式会社 会社案内 — 群馬・前橋拠点。Lark 導入を支援する独立系コンサルティング事業者。