多店舗運営の中小企業が Lark で実現する 店舗オペレーション統合 — シフト・マニュアル・受発注を 1 つに

多店舗運営が直面する 5 つのオペレーション断絶

結論：3 店舗を超えたあたりから、多店舗運営の中小企業は「店舗ごとにツールが分かれている」状態に陥りやすく、本部がチェーン全体を 1 画面で把握できなくなる。痛みの正体は、シフト・マニュアル・受発注・コミュニケーション・KPI の 5 領域がそれぞれ別ツールで動いていることにある。

飲食チェーン、美容室、小売、フィットネス、クリーニング、整骨院。業種は違っても、3〜30 店舗規模の経営者から聞く悩みはほぼ同じです。「店長は頑張っている、でも本部からは中が見えない」「LINE グループが増えすぎて、何が決まったのか追えない」「新店オープンのたびにマニュアルを刷り直すのに 2 週間かかる」。これらは個々の店舗の問題ではなく、チェーン全体のオペレーション基盤が分断されていることから生じています。具体的な断絶は次の 5 つです。

断絶 1: 店舗ごとに LINE グループが乱立、本部が把握できない

多店舗運営で最初に始めたコミュニケーション手段は、ほぼ例外なく LINE グループです。最初は便利だが、店舗数が増えるにつれて「A 店店長グループ」「B 店スタッフグループ」「エリア管理者グループ」「本部経営会議グループ」と分裂し、10 店舗を超えた頃には 30〜50 のグループに膨らんで本部が全体像を追えなくなります。さらに、過去ログは流れて検索しにくく、退職者がいたグループの情報も引き継げません。LINE はパーソナル用途の延長で始まっているため、業務用のログ管理・権限管理・組織図同期に元から弱い設計です。

断絶 2: シフトが Excel と紙の壁、提出漏れと転記ミス

店舗ごとに店長がシフトを Excel で組み、印刷して掲示、本部にはメールで PDF を送付。この運用は、店長がベテランのうちは回ります。問題は、シフト希望提出→店長集計→本部確認→人件費試算→修正→確定までの工程で、各店舗が独自の方法を使っていること。集計シートのフォーマットが店舗ごとに違うため、本部側で人件費率や勤務時間の集計をするにも、再入力が必要になります。さらに、急な欠勤・代打依頼が LINE で飛ぶため、シフト表と実勤務が乖離していき、給与計算前の突き合わせ作業が毎月数十時間かかる、というケースは珍しくありません。

断絶 3: マニュアル・SOP が紙・PDF・動画ファイルで散在

飲食・小売・サービス業の現場マニュアルは、「接客」「衛生」「金銭」「クレーム対応」「販促」「クローズ作業」など領域が広く、それぞれが PDF・紙ファイル・LINE で共有された動画・店長の口伝という形で散らばっています。「最新の手順がどこにあるか分からない」「新人に教えるたびに店長が口頭でやり直す」「本部が改定した手順が店舗まで届いていない」という問題は、3 店舗を超えるとほぼ確実に発生します。中小企業庁「2024 年版 中小企業白書」も、属人化した業務プロセスがデジタル化推進の最大の阻害要因の一つだと指摘しています（中小企業庁「2024 年版 中小企業白書・小規模企業白書」概要 参照）。

断絶 4: 受発注が FAX・電話・LINE・メールに分散

店舗から本部・取引先への受発注は、業種により FAX、電話、LINE、メールが入り乱れます。「肉は FAX で発注」「野菜は LINE で写真送付」「酒は専用 EC サイト」「資材は本部にメール」といった具合に、1 店舗の 1 週間の発注業務だけで 5〜8 種類の伝達手段が使われます。本部側は、店舗の在庫状況・発注額・原価率をリアルタイムで把握できず、月次の決算でようやく全体像が見えるという状態になります。原価高騰時代に、これは経営判断を遅らせる致命的な構造です。

断絶 5: 店舗 KPI の見える化が遅い・属人化

売上・客数・客単価・原価率・人件費率・顧客満足度。これらの店舗 KPI は、本来は週次・日次で見るべき指標ですが、多店舗運営の中小企業では「月末に POS データを Excel に落とし、本部スタッフが手作業で 3〜5 日かけて集計」というケースが多数を占めます。本部は遅れた数字でしか判断できず、店舗側もリアルタイムで自店の数字を見られないため、改善行動が打てません。IPA「DX 動向 2024」でも、中小企業の DX 取り組み比率は 約 4 割に留まり、リアルタイム経営ダッシュボードの整備は大企業との大きな差として残っています（IPA「DX 動向 2024」参照）。

5 つの断絶に共通する答え：本部と現場を貫く 1 つの基盤

断絶 1〜5 はそれぞれ別々のツールで解こうとすると、LINE WORKS でチャット、kintone でシフト、Notion でマニュアル、専用 EC で発注、Tableau で KPI、というスタックが膨張し、月額コストもアカウント管理コストも増えます。中小チェーンに必要なのは、これらの 5 領域を「同じユーザ・同じ組織図・同じ権限」で 1 つの基盤の上に乗せることです。Lark は、IM・Base・Wiki・承認・カレンダー・メール・ビデオ会議を 1 アカウント・1 組織図で提供するため、まさにこの統合の役割に向いています。

既存の打ち手と限界 — LINE WORKS／kintone／Microsoft 365 の整理

結論：LINE WORKS・kintone・Microsoft 365 はそれぞれ「ある領域」では極めて強い。だが、多店舗運営の 5 領域を 1 つでカバーする設計ではないため、組み合わせ運用で月額コストとアカウント管理コストが膨らみやすい。これが中小チェーンの DX が「個別最適の積み重ね」で止まる構造的理由。

LINE WORKS — 店舗コミュニケーションは強い、業務 DB は持たない

LINE WORKS は LINE と同じ UI で店舗スタッフが迷わず使える点が最大の強みで、店舗 IM の置き換えとしては非常に有力です。料金はスタンダードプランで月額 ¥450／ユーザ（年払い）または ¥540／ユーザ（月払い）、アドバンストプランで月額 ¥800／ユーザ（年払い）または ¥960／ユーザ（月払い）（いずれも税抜、2026 年 6 月時点）と、低価格帯です（LINE WORKS 公式料金ページ 参照）。一方で、業務 DB（シフト管理・受発注・KPI 集計）の機能は掲示板・カレンダー・アンケート程度で、本格的な構造化データを設計する用途は想定外です。そのため、LINE WORKS だけで店舗オペレーションを統合するのは難しく、別途 kintone や Google スプレッドシートを併用する必要があります。

kintone — 業務 DB は強い、チャットと本部発信が弱い

kintone は中小企業向け業務アプリ作成プラットフォームの代表格で、シフト管理・受発注・案件管理など構造化データを扱う用途に強い設計です。料金はスタンダードプランで月額 ¥1,800／ユーザ（税抜、2026 年 6 月時点）（kintone 公式料金ページ 参照）。一方、kintone は「業務 DB の中で完結する」設計のため、店舗スタッフ向けの即時チャット、本部からの全店一斉お知らせ、動画マニュアルの配信、本部経営会議のビデオ通話には別ツールが必要になります。多店舗チェーンが kintone を採用すると、ほぼ確実に LINE WORKS + kintone + Zoom + Google ドライブの 4 点セットになり、コストが膨らみます。

Microsoft 365 + Excel — 慣れた人は強い、店舗パートには遠い

Microsoft 365 Business Standard は月額 ¥1,874／ユーザ（税抜、年払い）（Microsoft 365 公式ページ 参照）と、機能面では強力です。Teams・Excel・SharePoint・Lists を組み合わせれば理論上は店舗運営も組めますが、多店舗の店舗パート・アルバイトが日常的に Excel や SharePoint を使いこなすには学習コストが高すぎるのが現実です。本部スタッフは使えても、現場が定着しないため、結局 LINE と紙シフトに戻る、というパターンが頻発します。

既存スタックの月額イメージ — 10 店舗 50 名規模

仮に、10 店舗 50 名の中小チェーンが「LINE WORKS スタンダード + kintone スタンダード + Microsoft 365 Business Standard + Zoom Pro」を組み合わせて使うと、概算で次のような月額になります（いずれも税抜・公式料金ベース・年払い）。

サービス	単価／月	50 名小計／月	主な役割
LINE WORKS スタンダード（年払い）	¥450	¥22,500	店舗チャット・組織連絡
kintone スタンダード	¥1,800	¥90,000	シフト・受発注 DB
Microsoft 365 Business Standard（年払い）	¥1,874	¥93,700	Excel／メール／SharePoint
Zoom Pro（年払い・本部分のみ 5 ライセンス）	¥2,124	¥10,620	本部会議
合計（月額・税抜）	—	約 ¥216,820	—

年額にすると約 260 万円。さらに、4 サービスのアカウント管理（入退社・組織変更・権限変更）の運用工数、SaaS 間のデータ分断による集計工数が、表に現れないコストとして上乗せされます。多店舗運営の中小企業がここで気付くのは、「個別最適のスタックを足し続ける」アプローチでは、店舗が増えるほど 1 店舗あたりの管理コストが下がらないという構造です。Lark で 1 基盤に統合した場合の試算は、後段「10 店舗 50 名規模の月額コスト試算」で詳述します。

Lark で組む店舗オペレーション統合の 4 本柱

結論：Lark は IM・Base・Wiki・承認の 4 機能を 1 アカウントで提供する。多店舗チェーンの 5 つの断絶（コミュニケーション・シフト・マニュアル・受発注・KPI）は、この 4 本柱の組み合わせで構造的に解消できる。重要なのは、4 機能が同じユーザ・同じ組織図・同じ権限の上で動くこと。

Lark を多店舗運営の業務基盤として位置づけるとき、機能をバラバラに見ると複雑に感じます。実際の運用では、4 つの柱の役割分担を最初に決めることで、設計がシンプルになります。

柱	主な役割	置き換える既存ツール
IM（メッセンジャー）	店舗グループチャット／本部一斉お知らせ／緊急連絡／写真・動画共有	LINE グループ／LINE WORKS／Slack
Base（業務 DB）	シフト管理／受発注／顧客／店舗 KPI／タスク／物販在庫	kintone／Excel／Google スプレッドシート
Wiki（ナレッジ）	マニュアル・SOP／規程／業種別ノウハウ／新人教育動画	紙マニュアル／PDF／Notion／SharePoint
承認ワークフロー	シフト確定／値引き決裁／設備修繕／新規発注／有給申請	紙申請／メール承認／rakumo

この 4 本柱を 1 アカウントで運用できる点が、Lark の構造的な強みです。IM で告知された全店一斉お知らせから、関連する Base シフト表に 1 クリックで遷移し、未読の Wiki マニュアルが見つかり、必要に応じて承認ワークフローを起票する、という導線が サインインなし・コピペなしで完結します。kintone と LINE WORKS と SharePoint を行き来する 3 SaaS 運用との最大の違いは、ここにあります。Lark の料金プラン詳細はLark 公式料金ページを参照してください（2026 年 6 月時点）。

シフト管理の実装パターン

結論：Lark Base に「シフト希望」「確定シフト」「実勤務」の 3 テーブルを作り、IM・承認・カレンダーと連動させる。月初の希望提出から月末の給与計算前突き合わせまでを 1 基盤で完結させ、店長の集計工数を月 10〜15 時間削減する設計が現実的。

3 テーブル構成の基本

シフト管理の Base 設計は、シンプルに「希望」「確定」「実績」の 3 テーブルに分けます。各テーブルの主なフィールドは次のとおりです。

テーブル	主なフィールド	入力者
シフト希望	店舗・スタッフ名・希望日・希望時間帯・優先度・備考	スタッフ本人（モバイル）
確定シフト	店舗・日付・時間帯・配置スタッフ・想定人件費・原価率／売上計画	店長（承認後ロック）
実勤務	店舗・日付・スタッフ・実打刻時刻・実労働時間・備考	POS／勤怠連携または手入力

3 テーブルを「日付＋スタッフ」のキーでリレーションさせると、本部側で 「希望と確定のズレ」「確定と実績のズレ」「月次の店舗別人件費率」を 1 つのダッシュボードで把握できます。スタッフはモバイルの Lark アプリから希望を提出するだけ、店長はその一覧をフィルタしてドラッグでシフト表を組むだけ、本部は Lark Base のダッシュボードで全店比較するだけ、という分業が成立します。

承認ワークフローとカレンダーへの連動

確定シフトは、店長が起票して本部エリアマネージャーが承認するワークフローとして組みます。承認されると、自動的に Lark カレンダーの「店舗カレンダー」に勤務予定が登録され、スタッフ個人のカレンダーにも同期されます。「シフト表を見るのを忘れた」「直前に変更されたが気付かなかった」というよくある事故は、カレンダー通知でほぼゼロになります。代打が発生した場合は IM のシフトチャネルで募集を打ち、応募が承認されると Base と承認の両方が自動更新される、という運用が標準です。

給与計算前の突き合わせ工数を月 10〜15 時間削減する

10 店舗規模の中小チェーンで月初の給与計算前に発生する突き合わせ作業は、店長と本部経理を合わせて月 20〜40 時間が一般的です。Lark Base の 3 テーブル構成にすると、突き合わせは「確定 vs 実績」のフィルタビューを開くだけで終わるため、月 10〜15 時間の削減が現実的に見込めます。当社の自社 EC 事業（楽天・Yahoo・Amazon）では、Lark Base に業務を集約したことで月 240 時間→24 時間（-90%）の業務時間削減を実証しており、シフト・勤怠分野でも同じ構造で削減が効きます。EC 事業での実証詳細は「中小 EC 事業者の Lark 活用 — 自社実証で見る業務時間 240h→24h と 90% 削減の現実」を参照してください。

マニュアル・SOP を 1 か所に集約する Wiki 設計

結論：Lark Wiki に「業種別 SOP・新人教育・接客／衛生／金銭／クレーム・販促・クローズ作業」を階層化し、改定責任者を 1 人決める。動画マニュアルも同じ Wiki に埋め込むことで、「最新版がどれか分からない問題」を構造的に解消する。

Wiki の階層設計テンプレート

飲食・小売・サービス業の多店舗運営で、最初に整える Wiki の階層は次のような構成が現実的です。

• 00 はじめに（理念・行動指針・組織図・連絡網）
• 01 新人 14 日プログラム（Day 1〜14 の到達目標・チェックリスト・動画リンク）
• 02 接客 SOP（入店時／注文時／会計時／お見送りの基本セリフと所作）
• 03 衛生・安全（HACCP／食品衛生／清掃手順／衛生チェック日次）
• 04 金銭・レジ（開店レジ／クローズレジ／違算発生時の手順）
• 05 クレーム対応（一次対応／本部エスカレーション基準／記録テンプレート）
• 06 販促・SNS（公式 SNS 投稿ルール／キャンペーン展開手順）
• 07 設備・トラブル（冷蔵庫故障時／POS 故障時／停電時の手順）
• 08 本部規程（就業規則／個人情報／インボイス対応／電帳法対応）

各項目の改定責任者を 1 人決め、改定履歴を Wiki の標準機能で残します。「全員で書き換えよう」は美しいが現実的には誰も書かないため、責任者制が定着の鍵です。新人教育プログラムは、Day 1〜14 の到達目標と動画マニュアルへのリンクを 1 ページにまとめ、店長のチェックボックスで進捗管理できる構造にします。

動画マニュアルの埋め込みで「読まないマニュアル問題」を解く

紙や PDF のマニュアルは、現場スタッフが読まない、というのは中小チェーンの普遍的な課題です。Lark Wiki は動画ファイルの直接埋め込みと、外部動画サービス（YouTube 限定公開等）のリンク埋め込みの両方に対応するため、テキスト＋動画の組み合わせで「読まれる／視られる」マニュアルが作れます。新店オープン時の研修も、Wiki の新人プログラム 1 ページだけを店長が説明すれば、あとは Day 1〜14 のチェック項目を消化していくだけで進む構造になります。

受発注フローを Base に統合する実装

結論：受発注は「商品マスタ」「取引先マスタ」「発注」「入荷」の 4 テーブルで設計する。FAX・電話・LINE・メールに分散していた発注を Base のフォームに統一し、本部がリアルタイムで全店の発注額・原価率を見える化する。

4 テーブル構成と入力の単純化

受発注の Base は次の 4 テーブル構成が基本です。商品マスタと取引先マスタを最初に整え、発注は「商品マスタからプルダウンで選ぶだけ」の状態にすることが定着の鍵です。

テーブル	主なフィールド	役割
商品マスタ	商品コード・名称・標準単価・主要取引先・カテゴリ	本部が一元管理
取引先マスタ	取引先名・連絡方法（FAX 番号／メール）・締日／支払日・担当者	本部が一元管理
発注	店舗・発注日・希望納品日・商品（マスタ参照）・数量・単価・備考	店長が入力
入荷	店舗・入荷日・商品・数量・差異・受領者	店舗スタッフが入力

FAX・電話・LINE をフォーム入力に集約する

店舗からの発注を Base のフォームに統一すると、店長はスマホで商品マスタから選択・数量を入力するだけになります。発注が登録されると、Base の自動化機能（オートメーション）で取引先別に発注書 PDF を生成し、FAX 番号宛に自動送信する／メール送信する／取引先用フォームに転記する、といったフローが組めます。FAX 送信が必須の取引先には、PDF を本部担当者経由で FAX 機に送る運用にし、店舗側からは 「フォーム入力で完結」という体験に統一できます。これにより、店舗側の発注ミス・記録漏れが構造的に減ります。

本部の原価率・取引先別発注額のリアルタイム把握

発注テーブルに「数量 × 単価」の自動計算フィールドを置けば、本部は当日／当週／当月の全店発注額を 1 ビューで把握できます。さらに、確定シフトの「想定売上計画」と組み合わせれば、原価率の見込みもリアルタイムに見える化されます。原価高騰時代に、月次決算を待たずに翌週の発注計画を調整できることは、経営判断の速度に直結する強みです。

店舗 KPI ダッシュボードと本部レビュー会の運用

結論：店舗 KPI ダッシュボードは「日次」「週次」「月次」の 3 階層で設計する。日次は店舗自身が確認、週次はエリアマネージャー、月次は経営会議で利用。Lark Base のダッシュボードと IM のレビューチャネルを連動させ、数字に基づく改善行動を定着させる。

3 階層の KPI 設計

階層	対象 KPI	見る人
日次	売上・客数・客単価・人件費率・原価率（速報値）	店長／スタッフ
週次	前週比・前年同週比・カテゴリ別売上・ロス率	エリアマネージャー
月次	全店比較・損益・人件費率・原価率（確定値）	経営会議

日次 KPI は店舗 iPad で常時表示し、店長が朝礼／終礼で確認する運用が定着しやすい形です。週次レビューは Lark IM の「週次レビューチャネル」で、エリアマネージャーが各店の数値にコメント、店長が改善行動を返信する非同期会議として運用します。毎週集まらず、IM 上で数値・改善行動・確認の 3 往復で完結する非同期会議は、移動時間を削減しながら振り返りの密度を上げる現実的な手法です。

POS／会計 SaaS との連携の現実解

店舗 KPI の元データは POS と会計 SaaS（freee／マネーフォワード等）から取得します。理想は API 連携で日次自動取り込みですが、多店舗 10 店舗以下なら、POS から CSV エクスポート→Lark Base へ手動インポート（または自動化）でも実用上は十分です。連携の作り込みに数ヶ月かけるより、まず手動でも日次の KPI ダッシュボードを動かしてしまい、効果を確認してから API 連携に投資する、という順序が中小チェーンには合います。経理 SaaS との API 連携の実装パターンは「Lark × 経理 SaaS(freee / マネーフォワード) 連携で実現する経理自動化」で詳述しています。

10 店舗 50 名規模の月額コスト試算

結論：Lark Pro 1 本に統合した場合、10 店舗 50 名で月額約 ¥71,000（年払い・税抜）。既存の 4 サービス併用（LINE WORKS＋kintone＋Microsoft 365＋Zoom）の約 ¥216,820 と比較し、月額で 約 ¥145,820 削減（年間約 175 万円）。さらにアカウント管理・SaaS 間の集計工数といった「見えないコスト」も削減される。

Lark Pro 1 本に統合した場合の試算

サービス	単価／月	50 名小計／月	カバー範囲
Lark Pro（年払い・税抜）	¥1,420	¥71,000	IM／Base／Wiki／承認／カレンダー／メール／ビデオ会議
合計（月額・税抜）	—	¥71,000	5 領域すべて

Lark Pro プランは、Base テーブル 1 つあたり 2 万行、ストレージ合計 15TB、自動化実行回数月 5 万回まで利用可能です。10 店舗 50 名規模であれば、シフト・受発注・KPI のいずれも Pro プランの上限内に収まる設計が可能です（出典：Lark 公式料金ページ、2026 年 6 月時点）。500 名を超える規模や、Base 1 テーブル 5 万行が必要な場合は Enterprise プラン（年払い・税抜 月額 ¥1,820／ユーザ）への上位移行が選択肢になります。

5 店舗 25 名／30 店舗 150 名の場合の比較

規模	Lark Pro 月額	既存 4 サービス月額	月額差	年額差
5 店舗 25 名	¥35,500	約 ¥111,710	約 ¥76,210	約 ¥91 万
10 店舗 50 名	¥71,000	約 ¥216,820	約 ¥145,820	約 ¥175 万
30 店舗 150 名	¥213,000	約 ¥633,720	約 ¥420,720	約 ¥505 万

この試算には、SaaS 間の運用工数（アカウント管理、データ突き合わせ、ツール切替コスト）は含めていません。10 店舗 50 名規模で運用工数を含めて評価すれば、年間効果は 200 万円〜300 万円規模に達するのが現実的な見立てです。中小企業 DX の段階モデルと費用対効果の考え方は「中小企業の DX を 90 日で軌道に乗せる実践ロードマップ」で体系化しているので、合わせて参照してください。

30／90／180 日 段階的導入ロードマップ

結論：いきなり 5 領域を同時に乗せるのではなく、30 日で IM、90 日で Wiki＋シフト、180 日で受発注＋KPI を順に乗せる。既存スタックは並走させながら段階的に置き換え、現場の負担を最小化する。

Day 0〜30: IM への統合（最初の 1 か月）

• Lark Pro 契約・組織図登録・店舗ごとのチャネル作成（店舗チャネル／本部一斉／エリア／業務種別）
• 店長／本部スタッフを先行投入、店舗パート・アルバイトは順次招待
• LINE グループは「並走→徐々に Lark IM へ集約」（初日に全廃しない）
• 本部からの一斉お知らせは初日から Lark IM に移行
• Wiki に「Lark の使い方」を 1 ページ作成し全員参照

Day 31〜90: Wiki とシフトの実装（2〜3 か月目）

• Wiki の階層を整え、新人 14 日プログラム・接客 SOP・衛生 SOP の 3 つを最優先で投入
• シフト Base 3 テーブル（希望／確定／実勤務）を構築、1 店舗で試験運用
• 承認ワークフローを「シフト確定」「有給申請」の 2 種類で起動
• Lark カレンダーで店舗カレンダー・本部カレンダーを整備
• パート・アルバイトのモバイル定着率を週次でモニタ（目標 90%）

Day 91〜180: 受発注と KPI の実装（4〜6 か月目）

• 受発注 Base 4 テーブル（商品マスタ／取引先マスタ／発注／入荷）を構築
• 取引先別に FAX 自動生成・メール送付の自動化を実装
• 店舗 KPI ダッシュボードを日次／週次／月次の 3 階層で構築
• 週次レビューを IM の「週次レビューチャネル」で非同期化
• 既存 kintone／LINE WORKS の解約計画を立案、6 か月目末で並走終了

180 日後の到達点は、「新人スタッフが入っても、Wiki と Base を見れば自走できる」「本部が当日の数字をリアルタイムで見られる」「全店一斉お知らせが Lark IM 1 本に集約されている」状態。中小企業 DX 全般の段階モデルと整合させたい場合は「中小企業の DX を 90 日で軌道に乗せる実践ロードマップ」を併読してください。

多店舗導入で踏みやすい落とし穴 5 パターン

中小チェーンの DX 伴走支援と当社自社 EC 事業での実証で見えてきた、多店舗導入で特に踏みやすい落とし穴を 5 つに整理します。

落とし穴 1: 「LINE を 1 日で全廃する」と宣言する

LINE グループは個人 LINE と密結合しており、急な切り替えは現場の反発を招きます。並走期間 30〜60 日を最初から計画し、本部発信から段階的に Lark IM に統一していくのが正解です。完全廃止は「並走中の活用度が逆転した時点」と決めます。

落とし穴 2: Base 設計を「完璧にしてから配る」と判断する

業務 DB の設計を 3 か月かけて完璧に練ってから配ろうとすると、現場が触る頃には設計と現実がずれます。最初の 30 日で「シフト希望のみ」を Base 化し、現場で運用しながら 30 日ごとにフィールドを追加する反復設計のほうが、定着率が高くなります。

落とし穴 3: 本部スタッフだけで運用設計してしまう

本部スタッフは Excel や SaaS に慣れていますが、店舗のパート・アルバイトはモバイルの操作だけで業務を回します。本部目線で設計したフォームや Wiki は、現場では「項目が多くて入力できない」「読まない」と却下されることが多い。設計初期から店長 1〜2 名を巻き込んで、「現場が触ってみて違和感がない設計」をベースにすることが鍵です。

落とし穴 4: POS と Base の API 連携を最初から作り込む

POS との API 連携は、技術的に可能でも、初期構築工数が大きく、効果が遅れて顕在化します。最初の 90 日は POS から CSV を週次でダウンロードして手動で Base にインポートするだけで十分です。3〜6 か月後に効果が確認できたタイミングで、API 連携への投資を判断します。

落とし穴 5: 経営層が IM の使い方を学ばない

経営者・本部役員が IM を使わず、引き続きメールと電話だけで指示を出すと、現場の Lark 利用率は確実に伸びません。経営層の「今日から Lark IM を主な連絡手段にする」宣言と、初日からの率先利用が、定着のために最も効きます。経営層が変わらないなら、現場は変わらない、という当たり前のことが、ここでも当たり前に効きます。

よくある質問