PR から monetize へ — 業界 SaaS 運営者が受託・コンサル受付ページを 1 日で公開した話
Build-in-Public 14 日で reach は積めた。けど着地ページが無い、ということで tasteck.tech/work を 1 日で公開した運営記録。4 サービス・透明 pricing・英語 CTA まで含めた設計の実例。
第 6 弾 (Stripe webhook 5 日サイレント失敗 incident) を出した次の朝、ユーザーから刺さる指摘を受けました。
"PR 活動してるけど、どうやったら案件増えるかね"
確かに、Build-in-Public 14 日で blog 26 本 / Zenn / dev.to / GSC indexed 50+ URL / 検索 clicks 0→40 と reach は積んできた。でも**「で、お金は?」**の答えが詰まってない。
漏斗の底が抜けてたわけです。
Build-in-Public 第 7 弾、PR から monetize 軸への転換ログ。
構造的な問題: 着地ページが無い
PR の流れを冷静に見ると:
- dev.to / Zenn で技術記事を公開 → reach
- 読者が著者プロフィールに飛ぶ → bio 確認
- 「興味あるけど、どこに連絡すれば?」 → 行き場なし → 離脱
tasteck.tech の TOP に飛ばしても、そこは 業界 SaaS の店舗向け / 個人プレイヤー向け の LP。「Stripe webhook の話を読んで興味持った海外 dev」も「業界 SaaS の運用代行を依頼したい店長」も、ここで「自分宛の page」を見つけられない。
PR の reach × 着地ページの質 = 案件数。後者がゼロだと前者をいくら積んでも掛け算でゼロです。
1 日でやったこと
A. /work ページを Next.js で実装 (30 分)
tasteck.tech/work を新規追加。中身:
- 4 サービス (稼働サイズで選べる)
- 1h 技術 / 業界相談: ¥5,000 / 時間
- Stripe / 課金設計レビュー: ¥30,000 〜
- NestJS / Next.js スポット開発: ¥100,000 〜
- Build-in-Public 運用代行: 月額 ¥50,000 〜
- 実績 10 件 (具体性命): 8 年現役運用 / 1467× query 高速化 / Stripe incident 4h 修復 / 4/15 1 日大規模リリース / EC2 移行 / 14 日 Build-in-Public / 2 プロダクト同時 β / 多言語展開 / CSV 14 列対応 / リブランディング
- 英語 CTA (dev.to 経由の海外 dev 向け、Hourly $40)
- FAQ: 業界外 OK / NDA / 流れ / 支払い
- 問い合わせ:
mailto:info@tasteck.tech直 (Form は次フェーズ)
☝️ 実績欄、最初は 4 件だったがユーザーから「過去 commit / blog 読むともっとビッグなの色々超短時間で完了してる」と指摘されて 10 件に拡充。プロダクト運営者の自己評価は控えめになる傾向、第三者の客観性が刺さる。
B. 全媒体の動線整備 (15 分)
/work を作っただけでは届かない。各媒体から「ここから問い合わせて」を明示:
- landing Header nav に
受託・コンサルリンク追加 - landing Footer も同様
- sitemap.xml に
/work追加 (priority 0.85) - dev.to bio: website url + summary + available_for + skills_languages を英語で全部書き直し
- Zenn website url を
tasteck.tech/workに更新 - X bio に「🛠 受託・コンサル → tasteck.tech/work」追記
- X 固定ツイートを「公式紹介」から「受託受付告知」に差し替え
合計 6 媒体に同時動線。
C. GSC 申請 (1 分)
/work を URL 検査 → 「インデックス登録のリクエスト」。
設計上の判断
透明 pricing
受託案件で価格を伏せると、問い合わせ後に「予算合わなくて NG」となるケースが多い。最初に ¥5,000 / ¥30K / ¥100K / 月¥50K を明示しておけば、合わない人は来ない、合う人だけ問い合わせてくる。漏斗の質を高める。
4 サービス階層化
1h 5K (低い壁) → 月 50K (本格) の 4 段階にすることで、「ちょっと相談したい」も「がっつり頼みたい」も両方拾える。
最初の 1 件目の仕事は 1h 相談で来ても、満足度高ければ 30K → 100K → 月顧問 へエスカレートできる関係性を狙う。
業界外 OK / 英語 OK の明示
業界 SaaS の運営者だが、技術スタック (Stripe / NestJS / Next.js / TypeORM / AWS) は汎用。FAQ で「業界外も受けます、英語問い合わせも歓迎」と書くだけで、分母が一気に増える。
Stripe Form でなく mailto
最初は Stripe Payment Link や Google Form より、mailto:info@tasteck.tech 直のほうが摩擦低い。問い合わせの中身を見て、必要なら次フェーズで Form 化する。
想定客層
ざっくり 3 層:
| 層 | 流入元 | 想定リクエスト |
|---|---|---|
| 国内 SaaS 創業者 / 副業エンジニア | Zenn / X / landing blog | Stripe webhook 不具合 / NestJS スポット / 1h 相談 |
| 海外 SaaS dev | dev.to / GitHub | NestJS / Next.js spot, Build-in-Public ghostwriting |
| ナイトレジャー業界店舗 | landing TOP / blog | tasteck 業界 SaaS の運用代行 / カスタム機能開発 |
最も確度高いのは 1 番目 (Zenn/X 経由の dev)、次に 2 番目 (英語記事公開直後)、3 番目はじわじわ。
計測したいこと (Day 15-21)
/workページの GA / GSC clicks- mailto link クリック数 (page-level event)
- 実問い合わせメール数
- そのうち成約数 / 平均単価
- 流入元 (referrer 別)
第 8 弾で 2 週間後の生数値を出します。
まとめ
PR で reach を積むのと、着地ページを用意するのは順序が逆だったかもしれない。
本来は /work ページを最初に作って、PR で /work に向けて球を投げる方が ROI 高かったはず。
ただ、PR で先に積んだ実績が /work ページの説得力 (実績 10 件) になっているので、結果としては悪くない順序。「先に reach を作ってから着地ページを作る」方が、空のサービス LP を作るより信頼が乗る。
同じことに気づいた SaaS 運営者がいたら、半日でも先に着地ページを出す方が後の PR の ROI が変わります。
関連記事: