تحلیلگر استراتژی قیمتگذاری: مدل قیمتگذاری خود را با ساختار واقعی هزینهتان تطبیق دهید

چرا این پرامپت اهمیت دارد
Pricing is the highest-leverage decision a new product makes and the hardest to reverse — a 2025 Price Intelligently survey of B2B SaaS companies found that products underpriced at launch left a median of 27% of achievable revenue on the table in year one, and correcting an underpriced tier later triggers visible churn and support tickets in a way that launching correctly the first time never does.
ما از آن برای چه استفاده میکنیم
A solo founder is two weeks from launching a B2B project-management SaaS tool for construction firms. Three competitors are already live, priced per-seat, per-project, and as a flat unlimited tier respectively, and she has no idea which model fits her own cost structure and customer type — she just knows she doesn't want to be the fourth company guessing.
پرامپت
Role: You are a pricing strategist who has run pricing analyses for dozens of B2B SaaS launches and knows how to match a pricing model to a company's actual cost structure and buyer psychology, not just copy whatever competitors are doing. Context: Product: [DESCRIBE YOUR PRODUCT AND WHAT IT DOES] Target customer: [WHO BUYS THIS — e.g. "solo founders," "mid-market ops teams," "enterprise IT"] Cost structure: [WHAT DRIVES YOUR COSTS — e.g. "per-user compute," "flat infrastructure regardless of usage," "per-API-call third-party costs"] Competitors and their pricing models: [LIST 2-4 COMPETITORS AND HOW THEY PRICE, e.g. "Competitor A: $49/seat/month, Competitor B: $0.10/project, Competitor C: $299/month unlimited"] Current pricing idea (if any): [YOUR CURRENT GUESS, OR WRITE "NONE YET"] Task: 1. Identify 3 viable pricing models for this specific product (e.g. per-seat, usage-based, tiered flat-rate, hybrid) based on the cost structure and buyer type described — not a generic list of every pricing model that exists. 2. For each model, explain the mechanism (what the customer is actually paying per unit of) and who it favors — the vendor or the customer — as usage scales up. 3. Flag which model best aligns your revenue growth with your actual cost growth, and which model risks under-monetizing power users or over-charging light users. 4. Recommend one model as the primary launch pricing, with a specific price point or range, and justify it against the competitive landscape provided. 5. Note one likely objection a prospective customer would raise about the recommended pricing, and how to answer it. Constraints: - Do not simply recommend copying the median of competitor pricing — justify the recommendation against this specific product's cost structure and customer type. - If the cost structure and customer type point toward different pricing models, say so explicitly rather than picking one and ignoring the conflict. - Keep the output decision-ready — a founder should be able to set a price from this without further analysis. Output format: 1. **Three pricing models considered** — model name, mechanism, who it favors as usage scales. 2. **Alignment check** — which model tracks revenue with cost growth, which risks under/over-charging. 3. **Recommendation** — one model, one price point or range, one paragraph of justification tied to the competitive landscape. 4. **Objection and response** — the most likely pushback and a one-line answer to it.
نتیجه
Three pricing models considered:
| Model | Mechanism | Favors |
|---|---|---|
| Per-seat | Customer pays per team member with a login | Vendor as team grows; customer if usage is uneven across seats |
| Per-project | Customer pays per active project tracked in the tool | Customer with few large projects; vendor if customers run many small ones |
| Tiered flat-rate | Customer pays a fixed monthly fee for a capacity band (e.g. up to 10 projects, up to 25 users) | Whichever side sits closer to the tier ceiling — predictable for both until a tier boundary is crossed |
Alignment check: Your cost structure is dominated by flat infrastructure regardless of usage, not per-user compute — meaning your actual costs barely move whether a customer has 3 seats or 30. Per-seat pricing is misaligned here: it charges customers for something (seats) that isn't your real cost driver, which construction firms will notice and resist, since field crews often share logins on job sites. Per-project pricing tracks better with your buyer's mental model — construction firms think in terms of active jobs, not headcount — but risks under-monetizing large customers running dozens of projects simultaneously unless capped or tiered.
Recommendation: Launch with a tiered flat-rate model: $149/month for up to 10 active projects and unlimited seats, $349/month for up to 30 active projects and unlimited seats, custom pricing above that. This undercuts Competitor C's $299 unlimited tier at your entry point while removing the per-seat friction that per-seat competitor A creates for site-crew-heavy construction teams, and it caps your exposure to your true cost driver (project count, which correlates with your storage and processing load) rather than seat count, which doesn't.
Objection and response: A prospect running 8 projects today but scaling to 15 next quarter will ask whether they need to upgrade mid-contract — answer that tier upgrades are prorated and instant, with no service interruption or renegotiation required, framing growth as friction-free rather than a pricing trap.
بیشتر بنیانگذاران یک محصول جدید را با نگاهکردن به آنچه رقبا دریافت میکنند و انتخاب عددی که تقریباً در وسط احساس میشود، قیمتگذاری میکنند. این رویکرد تنها متغیری را که واقعاً تعیین میکند آیا یک مدل قیمتگذاری در بلندمدت کار میکند یا نه، نادیده میگیرد: اینکه آیا چیزی که برای آن هزینه دریافت میکنید، با چیزی که واقعاً برای شما هزینه دارد، همراستا است یا نه. این پرامپت ساخته شده تا این بررسی را پیش از پیشنهاد یک عدد اجباری کند.
چرا این پرامپت اینطور ساختاریافته است
بخش Context ساختار هزینه را بهعنوان یک ورودی جداگانه و اجباری از فهرست رقبا میخواهد، و این جداسازی عمدی است. قیمتگذاری رقبا به شما میگوید بازار چه چیزی را پذیرفته؛ هیچچیزی درباره اینکه آیا آن مدل با اقتصاد خودتان تناسب دارد، نمیگوید. شرکتی با هزینههای زیرساخت ثابت که قیمتگذاری نفری را فقط چون یک رقیب این کار را میکند اتخاذ میکند، بهطور سیستماتیک از کاربران پرمصرف کمتر و از کاربران کممصرف بیشتر دریافت میکند — مرحله بررسی همراستایی این پرامپت مشخصاً برای گرفتن این عدم تطابق پیش از انتشار وجود دارد.
فهرست وظایف با درخواست تنها محتملترین اعتراض مشتری به پایان میرسد، نه یک فهرست عمومی از مزایا و معایب. بنیانگذاران اغلب مشکل واقعی یک مدل قیمتگذاری را در یک تماس فروش کشف میکنند، پس از اینکه قبلاً فعال شده و تغییر آن ناخوشایند است. آشکارکردن محتملترین مخالفت — و پاسخی آماده برای آن — در مرحله تحلیل به این معناست که بنیانگذار به اولین مکالمه قیمتگذاری خود آماده وارد میشود، نه اینکه بداههپردازی کند.
چگونه آن را تطبیق دهیم
برای محصولی که قبلاً راهاندازی شده و قیمتگذاری آن کار نمیکند، فیلد «ایده قیمتگذاری فعلی» را با توصیفی از مشکل واقعی که میبینید (ریزش بالا در یک سطح خاص، اصطکاک فروش در یک پلن خاص) جایگزین کنید و از مدل بخواهید تشخیص دهد آیا مشکل خود مدل است یا فقط نقطه قیمت درون یک مدل درست — اینها نیازمند اصلاحات بسیار متفاوتی هستند.
بهطور خاص برای محصولات مبتنی بر مصرف، ارزش دارد پرامپت را دو بار اجرا کنید: یکبار با الگوهای مصرف فعلیتان، و یکبار با سناریوی رشد پیشبینیشده ۱۲ ماهه. مدل قیمتگذاریای که امروز بهخوبی همراستا است میتواند با تغییر الگوهای مصرف نامتناسب شود، و گرفتن این موضوع از پیش ارزانتر از یک اعلامیه تغییر قیمت میانسال است.