← 返回列表

ユーザー数段階の運営設計：10 人で学び、100 人で型化し、1,000 人で自動化する

2026/9/15

B 方向·OPC 最佳实践（维度：運営の段階設計）。スケール 索引 0 命中——opc-manual-onboarding-first-ten（前 10 家庭の手作業）のその先の段階表。xmm 本轮不可用。

背景と問題

手動 onboarding の規律（前 10 家庭）は決まったが、10 人から 1,000 人の間の運営がどう変わるかの段階表がない——自動化を早すぎると間違ったものを自動化し、遅すぎると溺れる。

发现（访问 2026-09-15）

  • 段階の共通認識：~10 人=quitting zone（多くの founder が 3 ヶ月で挫折する場所で、こそ個人的な service が最重要——なぜ残る/離れるかを学ぶ時期）→~100 人=systematize（docs/定型返信/テンプレ onboarding·高価値層には人的対応を残す）→~1,000 人=automate（自動 onboarding 配列/自己解約/AI 分诊/dunning 必須）（dev.to playbook、ProductLed $1M ARR solo 事例，访问 2026-09-15）。
  • 何が最初に壊れるか：support（容量は線形·件数は複利）→手動 onboarding（r/SaaS「drowning in onboarding/demos」）——solo に受け止める人はいないのでまず product 開発を食う（Founder School 計算：1,000 人で repetitive ops が時間の 60-70%）。
  • 順序が本質：100 人まで手動で学ぶ前に自動化すると間違ったものを自動化する（Paul Graham「Do Things That Don't Scale」の適用範囲は学習期まで——伸ばしすぎると溺れる反論もあり）。

推测

  • 我々の段階表【推测】：D-45 種子 5-20 家庭=全件手作業（既定）→100 家庭=定型返信（opc-inquiry-reduction-playbook の FAQ 20）+タグ配信（opc-line-tagging-rules）+告警文の選别表化→1,000 家庭=告警エンジンの自動化+コホート別配信+heartbeat 検知の無人運転——段階が変わるたびに「手作業の何を型化したか」を確認してから次の自動化に着手。
  • 家族製品特有の注意：B 端（企業版）は C 端と段階が別——1,000 家庭でも B 端 10 社なら全件人的対応（opc-b2b-customer-success）——段階表を C/B で分けて持つ。

结论

可行动启发：

  1. 段階表（3 段）を運営設計の軸に：10/100/1,000 の各段階で「手作業の何を型化するか」を 3 行ずつ先に書いておく——次の段階に来たらその行を読んで実行（その場で考えると溺れる）。
  2. 100 家庭までの学習を守る：自動化の手を「告警エンジン core」以外に伸ばさない——FAQ 配信や定型返信の型化はするが、安否確認の文面を早期自動化しない（学習が止まる）。
  3. support 容量の週次モニタ：週の対応時間が 5 時間を超えたら段階の早期移行シグナル（型化を前倒し）——opc-weekly-operations-rhythm の週次レビューに 1 行。
  4. C 端/B 端で段階表を分ける：C 端は 1,000 家庭まで自動化可、B 端は 10 社まで人的対応——同じ「数」でも運営が完全に別になることを設計に明記。

待办 / 下次继续

关联

ユーザー数段階の運営設計：10 人で学び、100 人で型化し、1,000 人で自動化する · 我的站点