見積案件を、営業担当者の頭の中に置かない。
新しいツールを増やす前に、
今ある仕事の中に、仕組みをつくる。
Gmailも。スプレッドシートも。Driveも。すでに御社で使われているなら、まず、それを活かします。新しいシステムへ業務を合わせるのではなく、今ある業務の中から、人がやらなくていい仕事を減らします。
すべての案件を見る
画面イメージ（サンプル）。社名・金額・日数はすべて架空のものです。
DON'T ADD.USE WHAT YOU HAVE.
増やす前に、今あるものを使い切る。
Gmailがある。Sheetsがある。Driveがある。そして何年分もの、顧客とのやり取りがある。
それなのに、新しいシステムを入れ、新しい入力作業を増やす。それが本当に、最初にやるべきことでしょうか。
既存の環境で解決できるなら、既存の環境を使います。既存のサービスで解決できるなら、それを使います。作る必要がある部分だけ、作ります。
作ることが目的ではありません。
仕事が減ることが目的です。
ある朝の、28分。
営業担当者が出社してから、最初の1件を前に進めるまでに起きていることです。
「あの案件、どうなってたっけ？」と思い出す。
Gmailを「山田食品」で検索する。
見積を送ったのが8日前だと分かる。
メーカーからの回答メールを探す。
スプレッドシートを開いて、金額と担当者を確認する。
別の案件の催促メールが目に入る。
「今日はどれから確認すべきか」を考える。
確認メールを、1通書く。
サンプルシナリオ。実在の企業・案件ではありません。
28分使って、
案件を前に進めた時間は、数分。
残りは、思い出す・探す・確認する・並べ替える時間です。これは能力の問題ではありません。案件の状態が、人の記憶と検索の中にしか無いから起きています。
営業担当者が、
「案件管理係」に
なっていませんか。
- 見積を送る
- 数日経つ
- 「あの案件どうなった？」
- Gmailを検索する
- メーカーの回答を確認する
- 顧客のメールを確認する
- スプレッドシートを確認する
- 次に何をするか考える
- 確認メールを書く
- また数日後に思い出す
一つひとつは、小さな仕事です。誰かに頼むほどでもなく、システムを入れるほどでもない。
でも、案件が100件あれば、
100回「覚えておく仕事」が生まれます。
御社にはすでに、
必要な情報があります。
- 顧客との会話
- 仕入先との会話
- 見積の提出
- 回答
- 確認
- 交渉
- 案件
- 金額
- 顧客
- 担当者
- 進捗
- 見積書
- 仕様書
- 関連資料
情報はある。
でも、仕事にはなっていない。
情報そのものが不足しているとは限りません。問題は、「今誰待ちなのか」「何日止まっているのか」「今日どの案件を見るべきか」「次に何をすべきか」を、人間が毎回、情報を探して判断していることです。
データを増やすのではなく、
すでにあるデータを、仕事に変える。
御社では、
すぐ答えられますか。
4つだけ、お答えください。入力内容はどこにも送信されません。
0 / 4 回答
システムを増やすことにも、
コストがあります。
- 新しいアカウントを発行する。
- 社員に使い方を説明する。
- 新しい入力ルールを決める。
- 既存データを移行する。
- 入力されているか確認する。
- Gmailと新システムを行き来する。
- 結局、一部の社員しか使わなくなる。
システムの利用料だけが、導入コストではありません。
「新しい仕事を覚えること」も、
導入コストです。
そのため、「何を導入するか」より先に「今ある環境で、どこまでできるか」を考えます。
「これ、社内でも
作れるのでは？」
はい。単純な仕組みなら、社内でも作れます。Google Apps Script。生成AI。ノーコード。既存のサービス。以前より、「作ること」は大幅に簡単になりました。
だから私たちは、「作れること」そのものに、大きな価値があるとは考えていません。
難しいのは、
何を作るかを決めること。
- ―どの仕事をなくすべきか
- ―どこは人間が判断すべきか
- ―どの情報を使うべきか
- ―例外をどう扱うか
- ―どこまで自動化するか
- ―社員が本当に使うか
- ―誤判定したとき、どうするか
- ―導入の前後で、何が変わったか
- ―運用しながら、どう改善するか
コードを書くことは、この仕事の一部でしかありません。
AIで作れる時代だからこそ、
「作る前」が重要です。
「Gmailから7日以上返信がない案件を検出するコードを書いて」と頼めば、コードは作れるかもしれません。しかしAIは、御社の仕事を見たわけではありません。
- ?なぜ7日なのか
- ?3日で確認すべき案件はないか
- ?仕入先の回答待ちも、同じ扱いでよいのか
- ?重要顧客はどうするか
- ?失注した案件を、どう判断するか
- ?担当者によって運用が違わないか
- ?通知が増えすぎないか
- ?何をもって改善とするか
これらを決めなければ、「動く仕組み」はできても、「役に立つ仕組み」になるとは限りません。
AIは、作る速度を上げる。
私たちは、何を作るべきかから考える。
- 担当者が課題を見つける
- AIに相談する
- コードを書く
- 動いた
- 業務で使ってみる
- 例外が出る
- 修正する
- 担当者が忙しくなる
- いつの間にか止まる
- 業務を見る
- 負を測る
- 作る価値があるか判断する
- 既存ツールで解決できるか確認する
- 必要な部分だけ実装する
- 実業務で使う
- 例外を整理する
- Before / After を測定する
- 改善する
- 会社の仕組みとして残す
問題設定。業務設計。実装。導入。検証。改善。「作ったけれど使われない」まで含めて、仕組みにする対象です。
私たちが引き受けるのは、
「開発」だけではありません。
既存SaaSで解決できるなら、
SaaSを使います。
すでに市場にあるSFAやCRMで御社の問題が十分に解決できるなら、わざわざ新しく作る必要はありません。
ただし、新しいシステムを入れることで、次のことが起きるのであれば、「システムを増やす」以外の方法を考えます。
- ―入力項目が増える
- ―営業の運用が変わる
- ―データ移行が必要になる
- ―二重管理になる
- ―既存業務との間に、人手が残る
SaaSを売りたいわけでも、
開発を売りたいわけでもありません。
御社の仕事を、一番小さな変更で良くする。
手段を比べる。
どれが優れているという話ではありません。それぞれに向いているケースがあります。この表は、どの手段がどこを得意とするかの整理です。
| 新規SaaS | 社内内製 | 受託開発 | Vitality Design | |
|---|---|---|---|---|
| 既存環境の活用 | △ | ◎ | ○ | ◎ |
| 新しい入力の負担 | △ | ◎ | △ | ◎ |
| 問題設定 | △ | △ | △ | ◎ |
| 個社の業務理解 | △ | ◎ | ○ | ◎ |
| 実装 | ◎ | ○ | ◎ | ◎ |
| 導入後の検証 | △ | △ | △ | ◎ |
| Before / After の測定 | △ | △ | △ | ◎ |
新規SaaSが最適なら、SaaSをおすすめします。社内で簡単に作れるなら、内製をおすすめします。いずれの手段も、条件が合えば有効です。
私たちが必要なのは、
「作れるけれど、何をどう仕組みにすれば
本当に仕事が減るか分からない」
そんな業務です。
人が覚えることを、
仕組みが引き受ける。
- 人が覚える
- 人が探す
- 人が整理する
- 人が判断する
- 人がメールを書く
- また覚えておく
- 普段どおりGmailを使う
- やり取りを整理する
- 案件の状態を理解する
- 滞留を検知する
- 今日見る案件を提示する
- 次の行動を示す
- 必要ならメール案を用意する
営業がやるべきなのは、顧客を理解すること。提案すること。交渉すること。判断すること。
「あの案件、どうなってたっけ？」ではありません。
通知するだけなら、
社内でも作れます。
「7日経ったら通知する」。それだけなら、既存のツールでも実現できます。目指しているのは、通知を増やすことではありません。
通知を増やすのではなく、
確認する仕事そのものを減らします。
なぜ、
Vitality Designなのか。
私たちは、「AIを入れるところ」から始めません。
業務を見る。問題を決める。
必要なものだけ作る。実際に使う。効果を見る。
要件を持ってくる必要は、
ありません。
- 顧客「これを作ってください」
- 開発会社「要件を教えてください」
- 顧客「この仕事、毎回面倒なんです」
- Vitality Design「まず、その仕事を見せてください」
要件が決まっていないことを、問題だとは考えません。むしろ、何を作るべきか決まっていない段階に、一番大きな改善余地があると考えています。
AIを入れたかではなく、
仕事が減ったかを見る。
導入前に測り、導入後に同じ指標を測ります。変わらなければ、広げません。
- 案件の確認にかけている時間
- — h / month
- 次のアクションが決まっていない案件
- — 件
- 14日以上動いていない案件
- — 件
- 結果が分からないままの案件
- — %
- 営業会議での状況確認の時間
- — min
- 案件の確認にかけている時間
- — h / month
- 次のアクションが決まっていない案件
- — 件
- 14日以上動いていない案件
- — 件
- 結果が分からないままの案件
- — %
- 営業会議での状況確認の時間
- — min
数値は空欄です。実績のない段階で、改善率を掲載することはしません。実際に測って埋める欄として置いています。成果を保証するものではありません。
いま「確認すること」に使っている時間の概算です。
現在、人が「確認すること」に使っている時間の概算です。削減できる時間ではありません。入力した値はどこにも送信されません。
まずは、
「見積を出したあと」だけ。
何でも開発する会社ではありません。扱う範囲を、はじめから狭くしています。
対象外：基幹システムの全面刷新／在庫システムの全面開発／EC構築／一般的なWeb制作／AI導入そのものが目的の案件。
このサービスが
必要ない会社もあります。
- ×SFAで案件管理が完全にできている
- ×見積の件数がもともと少ない
- ×追客の漏れがほとんど起きていない
- ×単純な期限通知だけが欲しい
- ×コードだけを納品してほしい
- ×AIを導入すること自体が目的になっている
- ×大規模な基幹刷新が目的である
既存のツールだけで十分なら、
新しく作ることはおすすめしません。
こんな会社と、
まずお話ししたいです。
営業責任者が「今、どの見積が止まっている？」に
すぐ答えられない。そんな状態が対象です。
会社には、すでに
たくさんの資源があります。
- 顧客との会話がある
- 案件の情報がある
- 資料がある
そして社員の中に、仕事の進め方があります。だから、最初から全部を入れ替える必要はありません。
今あるものを活かして、
人がやらなくていい仕事だけを減らす。
「あの案件、どうなってたっけ？」
を、人間の仕事にしない。
今の環境で改善できるか、
確認します。
Google Workspaceを使っている専門商社・卸売会社向け。30分のオンラインで、「新しいシステムを入れずに改善できる余地があるか」を確認します。
- 既存ツールで十分 → 既存ツールをおすすめします
- 社内で簡単に作れる → 内製をおすすめします
- 仕組み化する価値が小さい → 作らないことをおすすめします
その上で、人が覚え、探し、判断し、追いかけている仕事が残る場合だけ、改善方法をご提案します。この確認に費用はかかりません。
- 方法オンライン・30分
- 日程夜間・土日も対応します
- 準備資料を整えていただく必要はありません
- 回答原則メールでご返信します
- メールcontact@vitality-design.jp
お答えいただける範囲で構いません。内容を確認し、メールでご返信します。
内容を確認し、メールでご回答します。届かない場合は、お手数ですが contact@vitality-design.jp まで直接ご連絡ください。