社内共有用 / 顧客提示時は要匿名化

マーケティング支援 事例まとめ

「作って納める」で終わらせず、売れる仕組みまで一緒に設計した3案件
2026年8月24日 / 株式会社ピースフラットシステム 営業チーム
出典:Notion「顧客別提案資料」データベース内の提案書3件

00この資料は何か

まとめの目的

受託開発の提案は、放っておくと「機能一覧と金額」の勝負になります。そうなると相見積もりで価格の安い会社が勝ちます。

一方で弊社が受注・進行している案件を振り返ると、勝ち筋は別のところにありました。「作った後、どうやって儲けるのか」を、開発の前に一緒に設計しているという点です。

本資料は、その動き方が実際に表れている3案件を「マーケティング支援」という切り口で整理したものです。営業の場で、「開発会社としてではなく、事業パートナーとして選ばれる」ための材料としてお使いください。

取扱いについて。 本資料は社内共有用です。実社名を記載しているため、このまま顧客に提示しないでください。外部提示が必要な場合は、各事例に併記した匿名表記をご利用ください。
お客様が本当に困っているのは
「どう作るか」ではなく「どう売れるか」です。
3案件に共通していたのは、開発の話をする前に、事業の話をしていたことでした。

01マーケティング支援の3つの型

3案件を分類すると、支援の形は3つに分かれます

TYPE A
マネタイズ設計
無料で使ってもらいながら、どこで収益を得るか。機能課金ではなく「利用量」「手間の削減」「外部接続」で課金する構造を設計する。
事例①:A社様
TYPE B
販路・パートナー設計
自社で使うために作ったシステムを、外部にも売れる商品に変える。既存プラットフォームのパートナー制度を組み合わせ、二重の収益を生む。
事例②:B社様
TYPE C
LTV導線設計
単発購入で終わらせず、継続課金へつなげる。データを起点にパーソナライズし、購入 → 再購入のループを回す導線をアプリに組み込む。
事例③:C社様
CASE 01 / TYPE A:マネタイズ設計
供養業界の事業者A社 様
デジタル家族史+死後開示アプリ(ファミリー・ライフログ)
業界
仏壇・仏具販売/供養(事業者)
匿名表記
供養業界の事業者A社(新規事業としてアプリを立ち上げ)
局面
4〜6社の相見積もり。合議での意思決定。「率直に高い」と言われた状態からの巻き返し
担当
営業担当B

何が課題だったか

核家族化で家族の歴史が引き継がれない。故人のスマホのロックが開けられず、口座も保険も分からない。この「心」と「実務」の両方を支えるアプリを作りたい ── ただしフル機能を一度に作る前提だと投資規模が大きく、構想段階では判断できないという状態でした。

さらに、金額について「率直に高い」と言われていました。ただし付帯して「全部できる内容なら適正かもしれない」とも言われている。つまり問題は金額ではなく前提の違いだと分かっていました。

マーケティング支援として何をしたか

1
「基本無料のまま、どう事業を続けるか」を設計した
機能に課金すると、一番使ってほしい層が使わなくなります。そこで「機能」ではなく「利用量」「手間の削減」「外部サービスとの接続」で収益をいただく方針を提案しました。
2
顧客の既存事業に接続する形で収益源を組んだ
紹介先・制作支援・現物商品を、仏具・供養という既存商品とそのまま組み合わせられる構造にしました。アプリ単体の収益ではなく、本業への送客装置として位置づけています。
3
投資判断そのものを段階化した
総額を一度に決めるのではなく、3ヶ月の要件定義フェーズ(準委任・月額)から着手する形に。「構想段階で大きな金額を稟議にかける」のではなく「調査と要件確定の工程として起案する」形に変え、社内合意を得やすくしました。

収益化モデルの3層

モデル内容顧客の本業との接続
1. 容量・保存期間の拡張写真・動画の容量追加、高画質保存、5年・10年の長期保管、二重バックアップ、一括出力「永久保管」は運営コストが積み上がるため、期間を区切った商品設計+更新案内で継続取引に
2. 非常時の専門サービス紹介葬儀・保険金請求・相続・遺品整理・空き家等の相談先を、状況に応じて案内紹介料・成約手数料・提携料に加え、自社商品・サービスへの送客
3. 制作支援・現物商品の販売登録代行・自分史の聞き取り制作・家系図作成/自分史冊子・メモリアルムービー・QR付きカード等既存の仏具・供養商品とそのまま組み合わせ可能
営業で使えるポイント。 「高い」と言われたとき、値引きではなく前提を揃えることで返した案件です。同時に、他社が出していない「収益化モデル」「特許リスク」という別の土俵を作りました。比較の軸を、金額から中身へずらしています。相見積もり局面で最も参考になる進め方です。

補足:本件では特許抵触リスクの整理も並行して行い、「対処できるのは設計を固める前だけ」という論点で要件定義フェーズの必要性を説明しています。マーケティングというよりリスク設計ですが、価格勝負を避ける材料としては同じ効き方をします。

CASE 02 / TYPE B:販路・パートナー設計
B社 様
店舗管理システムの外販戦略(POSベンダーのパートナー制度の活用)
業界
店舗運営(自社8〜10店舗)
匿名表記
飲食・接客業を複数店舗展開するD社
局面
自社向けに作ったシステムを、同業他社へ外販して収益化したい

何が課題だったか

自社の8〜10店舗向けに管理システムを導入する案件でした。ここで止めれば、単なる社内システムの受託開発です。しかし「自社で使えるものは、同業他社にも売れるはず」という発想に立てば、顧客にとって新しい収益事業になります。

マーケティング支援として何をしたか

1
既存POSのパートナー制度と組み合わせて、二重の収益を作った
管理システムを外販する際にクラウドPOSもセットで提案する構造にしました。外販先はシステム利用料を顧客に払い、POS利用料をPOSベンダーに払う。そしてPOSベンダーから顧客へパートナー報酬が入る。売れば売るほど2方向から収益が入ります。
2
セット提案が成立する理由を、業務構造から説明した
同業界は独自の会計・接客フローがあり、POS単体では業務が回りません。管理システムがフロア・キャスト・給与を担い、POSが会計・決済・レシートを担う。この役割分担があるからセット導入が自然になります。
3
交渉相手(POSベンダー側)のメリットまで整理した
パートナー交渉を有利に進めるため、POSベンダー側の利点も言語化しました。新規販路の開拓/営業コストがかからない/セット導入で導入率が高い/自社8〜10店舗の大口導入が最初の実績になる。顧客が交渉に持っていける形にしています。

外販までの4フェーズ

Phase 1
自社導入
8〜10店舗に
システム+POS
Phase 2
実績構築
運用改善し
効果を数値化
Phase 3
パートナー契約
実績をもとに
POS側へ提案
Phase 4
外販開始
同業他社へ
セット販売

ポイントは Phase 2 で「売上○%UP」「業務時間○%削減」の事例を作ること。実績がないとパートナー交渉も外販営業も成立しません。順番の設計そのものが提案の中身になっています。

顧客が外販で強い理由(提案書に明記した内容)

強み外販への活かし方
自社8〜10店舗での運用実績「自分たちが使って成果が出たシステム」として信頼性が高い
業界ネットワーク業界の横のつながりを活かした営業が可能
現場の課題を熟知同業者の悩みに刺さる提案ができる(机上の空論ではない)
導入・運用サポート力自社で培ったノウハウで、外販先の導入もスムーズに支援できる
営業で使えるポイント。 「自社用に作るシステム」を「売れる商品」に読み替える提案です。同じ開発費でも、コストセンターへの投資か、新規事業への投資かで、顧客の稟議の通りやすさが変わります。複数店舗・複数拠点を持つ顧客には、ほぼ横展開できる考え方です。
CASE 03 / TYPE C:LTV導線設計
ペット関連ECのC社 様
ペット健康管理×DNA解析×EC連携アプリ
業界
ペット関連(EC事業者)
匿名表記
ペット関連商材を扱うEC事業者E社
局面
DNA解析キットを売って終わりにせず、定期購買につなげたい

何が課題だったか

DNA解析キットは単発で売れる商品です。買って、検査して、結果が出たら終わり。これでは事業が積み上がりません。「解析結果を、その後の継続購入につなげる導線」をどう作るかが本質的な課題でした。

マーケティング支援として何をしたか

1
単発購入をループ構造に変えた
キット購入 → 識別ID登録 → 解析 → 結果通知 → 健康ログ入力 → フード提案 → EC購入 → 定期購買化 → 再び健康ログへ。一度きりの取引を、回り続ける輪に組み替えています。
2
パーソナライズをAIではなくルールベースで実装した
DNA結果×健康ログ×ペット情報から商品を提示しますが、AI・機械学習は使いません。マッピングルールは顧客が設計し、弊社は適用機構を実装。コストを抑えつつ、提案の精度は顧客の知見で担保するという割り切りです。
3
既存ECの資産を捨てずに使う構成にした
アプリ側に独立した顧客DBを作らず、既存ECサイトのDBを拡張してペット情報を持たせる設計を提案。初期構築コストを抑えつつ、既存EC会員情報を一元管理できます。
4
EC基盤の選択を、判断材料ごと渡した
既存ECプラットフォーム継続 と 新ECプラットフォーム新規構築 の両プランで見積を提示。「コスト最小で最短スタートならA、ユーザー体験最良で将来拡張ならB」と整理し、最終判断は顧客のEC戦略に委ねました。決めさせるのではなく、決められるようにする提案です。

LTVを生むループ

キット購入
単発の売上
解析結果
アプリで通知
健康ログ
日々の記録
=接触頻度
フード提案
ルールベースの
パーソナライズ
定期購買
LTV最大化

健康ログが効いています。毎日記録するという行為がアプリを開く理由になり、その蓄積が提案の精度を上げ、提案の精度が購入につながる。ここが途切れるとループは回りません。単なる記録機能ではなく、マーケティング上の要として設計しています。

営業で使えるポイント。 EC・物販の顧客に対して、「アプリを作る」ではなく「リピートの仕組みを作る」と言い換える提案です。第2フェーズ(オンライン診療・病院予約)、第3フェーズ(獣医ネットワーク・BtoB・院内POP)まで見据えた設計を初期段階から示すことで、単発開発ではなく継続的な取引に持ち込んでいます。

023案件に共通する型

なぜこの進め方が効くのか

共通点中身
開発の前に事業の話をしている3件とも、機能一覧より先に「どう儲かるか」「どう売るか」を整理している。顧客が本当に判断に迷っているのはそこ
顧客の既存資産に接続しているA社=仏具・供養の本業/B社=業界ネットワークと自社店舗/C社=既存EC。ゼロから作らず、持っているものに乗せる
段階に分けて、最初の判断を軽くしている要件定義フェーズのみ/自社導入から始めて外販へ/第1フェーズと第2フェーズの分離。いきなり全額を稟議にかけさせない
選択肢を、判断材料ごと渡している松竹梅の3パターン/既存ECプラットフォーム vs 新ECプラットフォーム の両見積。決めてあげるのではなく、決められる状態にする
後から拡張できる設計を約束している3件とも「初期フェーズの設計時点で将来拡張を考慮する」と明記。将来の話が、今回の設計品質の説明になっている
結論として、これが相見積もりへの答えになっています。 価格で比較される土俵に乗ると、開発会社は差がつきません。「事業として成立するかを一緒に考えている会社」は、そもそも比較対象が違います。3件のうち2件は明確な相見積もり局面(4〜6社/6社)でしたが、いずれも金額以外の論点を提示することで議論の軸を移しています。

03営業での使い方

どの局面で、どの事例を出すか

こう言われたら出す事例言い方の例
「他社より高い」CASE 01(A社)「前提が違う可能性があります。同じ土俵で比較いただけるよう、機能別の前提条件を出させてください」
「予算が通せない/稟議が重い」CASE 01(A社)「総額を一度に決めず、まず要件定義フェーズだけ起案する形もあります」
「社内システムだから投資対効果が見えない」CASE 02(B社)「自社で使えるものは、同業他社にも売れます。外販まで含めて設計しませんか」
「作った後、続くか分からない」CASE 03(C社)「単発で終わらない導線を、最初から組み込みます」
「相見積もりで何社か見ている」CASE 01+03「機能と金額以外の論点を1つ持ち込ませてください。収益化と、リスクの話です」
「要件がまだ固まっていない」全件「弊社は要件が固まる前から入るのが得意です。要件そのものを一緒に作らせてください」
注意点。 実社名・実案件の詳細は社内限定です。顧客に話す際は、本資料の「匿名表記」欄の言い方(供養業界の事業者A社/飲食・接客業を複数店舗展開するD社/ペット関連ECのE社)を使い、金額はレンジ表記かつ具体額は伏せてください。