پیشنهاد «طراحی کامل سایت» ممکن است ارزان به نظر برسد، چون چیزهایی را قیمتگذاری نکرده است: ورود محتوا، پاکسازی داده، تمدید افزونه، تست بازیابی، مانیتورینگ، پاسخ به حادثه، اصلاح بعد از تغییر API، آموزش تیم و در نهایت خروج از Vendor. این اقلام ناپدید نمیشوند؛ فقط صورتحسابشان دیرتر و معمولاً در بدترین زمان ظاهر میشود.
پاسخ کوتاه: هزینه پنهان سایت، هزینهای جادویی یا الزاماً فریبکارانه نیست. هر هزینهای است که برای چرخه عمر واقعی سایت لازم میشود اما در Scope، مدل مصرف، مسئولیت یا سناریوی ریسک دیده نشده است. راه کنترل، درصد ذخیره عمومی نیست؛ باید Cost register بسازید، TCO چندساله را با هزینه داخلی و خروج محاسبه کنید، محرک هر هزینه را بشناسید و قرارداد را به Evidence و Acceptance وصل کنید.
این راهنما برای مدیر کسبوکار، مسئول مالی، مدیر محصول و خریدار خدمات طراحی سایت ایرانی نوشته شده است؛ با مثالهایی از سایت شرکتی و فروشگاه آنلاین، بدون قیمت ثابت و وعده بازگشت سرمایه.
هزینه پنهان طراحی سایت دقیقاً چیست؟
یک هزینه وقتی پنهان میشود که در تصمیم اولیه دیده نشود یا اثر آن درست توضیح داده نشود. شش نوع اصلی را از هم جدا کنید:
| نوع | تعریف | نمونه |
|---|---|---|
| حذفشده | برای نتیجه لازم است ولی در Quote نیست | عکاسی، ورود ۳۰۰ محصول یا نوشتن Privacy notice |
| تکرارشونده | پس از Launch تمدید میشود | Hosting، Domain، License، Monitoring و Support |
| متغیر | با مصرف یا رشد تغییر میکند | Storage، Egress، ایمیل/پیامک، Search query یا سفارش |
| داخلی | پول نقد نیست ولی ظرفیت تیم را مصرف میکند | جلسه، QA، ورود محتوا، پاسخ پشتیبانی و Reconciliation |
| ریسکوزندار | قطعی نیست اما احتمال و اثر دارد | Incident، خرابی Provider، افزایش ارز یا ناسازگاری Update |
| خروج/تغییر | هنگام Scale، Migration یا پایان همکاری رخ میدهد | Export، بازسازی Template، URL map، Redirect و آموزش Vendor جدید |
بودجه طراحی، سقف تأمین مالی و نحوه برآورد پروژه را در راهنمای بودجه طراحی سایت توضیح دادهایم. تمرکز این مقاله کشف Cost leakage و تعهدات چرخه عمر پس از آن تصمیم بودجهای است.
قیمت ساخت با TCO سایت یکی نیست
قیمت ساخت معمولاً Discovery، Design و Development اولیه را پوشش میدهد. هزینه کل مالکیت یا TCO باید تمام هزینه لازم برای ساخت، بهرهبرداری، تغییر و خروج در یک افق تصمیم را ببیند:
TCO = Setup + Recurring + Variable usage + Internal labor + Risk-adjusted loss + Change/exit − Recoverable value
افق را متناسب با تصمیم، مثلاً ۳۶ ماه، انتخاب کنید. عدد بدون افق معنایی ندارد. برای هر جزء، Base، Downside و در صورت مفیدبودن Upside بسازید؛ نرخ ارز، رشد مصرف و تغییر پلن را جدا از هم فرض کنید تا اثر هر کدام دیده شود.
چه چیزهایی را داخل مرز TCO بگذاریم؟
قبل از جمعزدن، مرز هزینه را روشن کنید. در غیر این صورت پیشنهادها قابل مقایسه نیستند.
| سبد | داخل TCO سایت؟ | نحوه گزارش |
|---|---|---|
| ساخت و راهاندازی | بله | یکباره، همراه Scope و Acceptance |
| عملیات و نگهداری | بله | ماهانه/سالانه و بر مبنای Service level |
| تغییر و رشد محصول | بله، در سناریو | Backlog و Triggerمحور |
| جذب ترافیک و تبلیغات | معمولاً سبد جدا | Acquisition budget؛ برای پنهاننکردن CAC |
| عملیات اصلی کسبوکار | اگر سایت Driver آن است، سهم مربوط | مثلاً پشتیبانی سفارش و مرجوعی |
| فرصت ازدسترفته | در Business case، نه صورتحساب | با فرض و عدم قطعیت جدا |
تبلیغات را «هزینه نگهداری سایت» ننامید، اما اتصال Landing page، Analytics و Feed تبلیغاتی را هم از TCO فنی حذف نکنید. مرزها باید مانع دوبارهشماری یا پنهانشدن هزینه شوند.
نقشه هزینه در چرخه عمر سایت
| مرحله | هزینههای اغلب جاافتاده | Evidence پیش از تعهد |
|---|---|---|
| Discovery | تحقیق، Inventory، داده، معماری، نمونهسازی | Brief، WBS، Assumption و Decision log |
| Procurement | مقایسه، حقوقی، Pilot، مالکیت حساب | Bid normalization و آزمایش واقعی |
| Build | محتوا، Migration، Integration، QA و Rework | Acceptance matrix و Defect policy |
| Launch | Freeze، DNS، Redirect، Training، Hypercare | Runbook، Rollback و Owner |
| Operate | Hosting، License، Update، Support، Monitoring | Service catalog، SLA و Usage baseline |
| Change | Feature، Compliance، Provider/API و Debt | Change request و Impact estimate |
| Incident | Response، Restore، فروش ازدسترفته و اطلاعرسانی | Risk register، RTO/RPO و Drill |
| Exit | Export، Migration، Redirect، Parallel run و Handover | Exit plan و Rehearsal پیش از قرارداد |
هزینههای پنهان پیش از یک خط کد
Discovery، تصمیم و بازکاری
حذف Discovery پروژه را ارزان نمیکند؛ تصمیمهای حلنشده را به Build منتقل میکند، جایی که تغییر گرانتر و سیاسیتر است. حداقل باید کاربر و Journey اصلی، Outcome، Content/data inventory، Integrationها، کیفیت غیرعملکردی و معیار پذیرش روشن شوند.
اگر Vendor فقط «تعداد صفحه» را قیمت میدهد، این پرسشها را اضافه کنید: چه کسی متن و تصویر را آماده میکند؟ چند حالت Empty/Error/Loading لازم است؟ فرم پس از Submit به کجا میرود؟ داده قبلی چه کیفیتی دارد؟ چه کسی Claimها را تأیید میکند؟ پاسخ هر سؤال میتواند یک Work package باشد.
هزینه زمان افراد داخل سازمان
جلسه مدیر، بررسی حقوقی، تأیید محتوا، پاکسازی Excel، تست محصول و آموزش اپراتور رایگان نیستند. ظرفیت داخلی را اینطور ثبت کنید:
Internal labor cost = Hours × Loaded hourly cost
Loaded cost فقط حقوق نیست؛ مزایا و Overhead مربوط را طبق روش مالی خود سازمان محاسبه کنید. اگر تیم داخلی همان زمان نمیتواند فروش، محصول یا پشتیبانی را انجام دهد، Opportunity cost را جدا و با احتیاط گزارش کنید؛ آن را با هزینه نقدی جمع نزنید مگر روش مالی اجازه دهد.
محتوا، رسانه و داده؛ بودجه فراموششده Launch
«صفحه آماده است» با «محتوای قابل انتشار دارد» فرق میکند. هزینه محتوا شامل تحقیق، مصاحبه، نگارش، ویرایش، ترجمه، عکاسی، ویدئو، مجوز دارایی، Alt، ورود CMS، QA و نگهداری بعدی است.
| دارایی | Driver هزینه | شرط پذیرش |
|---|---|---|
| صفحه خدمت | مصاحبه متخصص، Claim/Evidence و Case study | مالک تأیید و تاریخ بازبینی |
| Catalog محصول | SKU/Variant، تصویر، ویژگی، قیمت و موجودی | Completeness و Error report |
| رسانه | تولید، مجوز، Crop، Compression و Caption | Source/license و نسخه بهینه |
| داده قدیمی | Export، Cleaning، Mapping، Dedup و Import | Reconciliation record-by-record/sample |
| URL قدیمی | Inventory، Mapping و Redirect QA | Coverage، no chain و مقصد هممعنا |
در فروشگاه پنجهزارمحصولی، «انتقال محصول» یک خط نیست: Variant، Media، Attribute، Price، Stock، Review، Customer، Order، Consent و URL رفتار متفاوت دارند. یک Sample migration زودهنگام، هزینه واقعی را بهتر از قیمت بهازای صفحه نشان میدهد.
Integration: هزینه فقط اتصال اولیه نیست
درگاه، CRM، حسابداری، انبار، جستوجو، پیامک، ایمیل، نقشه و Helpdesk چرخه عمر مستقل دارند. برای هر Integration این اقلام را ثبت کنید:
- Setup و احراز هویت؛
- هزینه ثابت، Seat، Transaction یا Usage؛
- Sandbox، Test data و Certification؛
- Retry، Timeout، Queue، Idempotency و Reconciliation؛
- Monitoring، Alert، Log retention و Support؛
- تغییر API، Credential rotation و Deprecation؛
- Fallback دستی و هزینه اپراتور هنگام قطعی؛
- خروج، Export و جایگزینی Provider.
مثلاً «اتصال پیامک» فقط نصب Plugin نیست. Template approval، هزینه هر پیام، Failed delivery، چند Provider، OTP abuse، گزارش تحویل و افزایش حجم میتوانند هزینه بسازند. Cost driver باید «پیام موفق»، «تلاش ارسال» یا «کاربر فعال» باشد؛ از Vendor بپرسید Billing unit دقیق چیست.
قالب، افزونه، SaaS و License
نرمافزار رایگان میتواند انتخاب خوبی باشد، اما قیمت خرید صفر به معنی TCO صفر نیست. بررسی کنید:
- License برای چند Domain، Environment، Seat یا حجم استفاده است؛
- Renewal با قیمت اولیه تفاوت دارد یا نه؛
- Update و Security fix بدون تمدید ادامه دارد یا نه؛
- قابلیت حیاتی در Add-on یا پلن بالاتر قفل است؛
- هزینه ارز، روش پرداخت و دسترسی رسمی برای ایران چگونه است؛
- داده و تنظیمات پس از لغو اشتراک چه میشوند؛
- تعویض ابزار به بازسازی Template یا داده نیاز دارد یا نه.
برای ارزیابی Source، Update، Compatibility، Support، Performance و Lock-in در WordPress از راهنمای TCO قالب و افزونه رایگان استفاده کنید.
کیفیت را حذف نکنید؛ هزینه را به آینده منتقل میکنید
امنیت، دسترسپذیری، Performance، SEO و تست «تزئینات انتهای پروژه» نیستند. حذف آنها ممکن است Quote را کوچک کند، اما Defect، Retrofit، Incident و از دسترفتن کاربر را افزایش دهد.
| Quality lane | هزینه طراحیشده | هزینه انتقالیافته در صورت حذف |
|---|---|---|
| Accessibility | Requirement، Design review، Keyboard/Screen reader test | Retrofit، Support load و حذف بخشی از کاربران |
| Security | Threat review، Identity، Update، Log و Response | Incident، Downtime، Recovery و اعتماد |
| Performance | Budget، Media/Font، RUM و Load test | Scaling اضطراری، UX ضعیف و هزینه Cloud |
| SEO | IA، Metadata، Render، URL map و Release QA | Reindex، Redirect repair و ترافیک ازدسترفته |
| Data quality | Validation، Migration sample و Reconciliation | سفارش/Lead گمشده و اصلاح دستی |
W3C توصیه میکند دسترسپذیری در برنامه، بودجه، مسئولیت، پیادهسازی و پایش مستمر ادغام شود. همچنین SEO release را پیش از Launch به Evidence متصل کنید؛ چکلیست سئو طراحی سایت مسیر Staging تا پایش پس از انتشار را پوشش میدهد.
هزینههای روز انتشار و Hypercare
Launch یک لحظه تقویمی نیست؛ تغییر عملیاتی است. این اقلام معمولاً در Quote طراحی دیده نمیشوند:
- Content freeze و Delta migration؛
- DNS/TLS، Cache purge و Warm-up؛
- URL map و Redirect verification؛
- Smoke test فرم، پرداخت، ایمیل، پیامک و Analytics؛
- On-call تیم و دسترسی Vendorها؛
- Rollback criteria و نسخه قابل بازگشت؛
- Hypercare چندروزه، تریاژ Defect و ارتباط با کاربران؛
- آموزش اپراتور، Runbook و Handover واقعی.
در قرارداد روشن کنید Hypercare چند روز، با چه ساعت پوشش، Severity و زمان پاسخ است. «پشتیبانی رایگان پس از تحویل» بدون Scope و SLA قابلیت قیمتگذاری یا اتکا ندارد.
هزینه عملیات سایت بعد از Launch
Service catalog بسازید
نگهداری را یک عدد ماهانه مبهم نگذارید. هر Service باید Owner، Cadence و Evidence داشته باشد:
| Service | کار واقعی | Evidence |
|---|---|---|
| Update | Inventory، Staging، Compatibility test، Rollout و Rollback | Change log و نتیجه تست |
| Backup | Backup سازگار، Retention، Encryption و Restore drill | Restore report و RPO/RTO |
| Monitoring | HTTP/DNS/TLS/Journey check، Alert و Runbook | Coverage و Incident timeline |
| Security | Access review، Patch، Scan، Log و Response | Risk/control register |
| Content ops | Publish، review، archive و media governance | Inventory و freshness report |
| Support | Ticket triage، bug/change separation و SLA | Volume، severity و resolution time |
Backup با Restore فرق دارد
پرداخت برای Storage بکاپ، بازیابی را ثابت نمیکند. هزینه Restore drill، دسترسی مستقل، Retention، نسخه سازگار Database/File/Config، Key، DNS و محیط تمیز را ببینید. CISA در راهنمای Ransomware بر بکاپ آفلاین/رمزشده و آزمون منظم دسترسپذیری و صحت آن در سناریوی بازیابی تأکید میکند. طراحی کامل RPO/RTO و Runbook در راهنمای بازیابی فاجعه سایت آمده است.
Cloud و Hosting: از مبلغ پلن تا Unit economics
هزینه زیرساخت با «قیمت ماهانه سرور» تمام نمیشود. Compute، Database، Storage، Backup، Egress، CDN، Log، Search، Queue، WAF، IP، Support plan و محیط Staging ممکن است جدا محاسبه شوند. رشد مصرف همیشه با رشد ارزش همجهت نیست؛ Bot، Retry loop، Log پرحجم یا Image transformation میتواند هزینه بسازد بدون اینکه سفارش بیشتری ایجاد کند.
هزینه را به واحد کسبوکار وصل کنید
در کنار مبلغ کل، چند Unit metric بسازید:
Infra cost / kept orderEmail + SMS cost / verified leadSearch cost / successful product discoveryObservability cost / critical journeySupport hours / 1,000 active users
این نسبتها نشان میدهند افزایش هزینه ناشی از رشد سالم است یا Waste. FinOps بر همکاری Finance، Engineering و Business، داده بهموقع و دقیق، تخصیص هزینه، Forecast، Anomaly management و Unit economics تأکید دارد؛ همین منطق را حتی برای سایت کوچک با یک Spreadsheet ساده به کار ببرید.
بودجه و Guardrail مصرف
- Tag/Label و Cost center برای Production، Staging و Campaign؛
- Budget alert در چند آستانه، نه فقط بعد از پایان ماه؛
- Anomaly alert برای Egress، Log، SMS، API و Database؛
- Rate limit و Quota برای مسیرهای پرهزینه؛
- Retention متناسب با نیاز، نه «برای همیشه»؛
- مالک اقدام و Runbook وقتی بودجه شکست.
امنیت، Incident و هزینه ریسک
امنیت یک License نیست. NIST CSF ۲.۰ چرخه را با Govern، Identify، Protect، Detect، Respond و Recover میبیند. اگر فقط WAF یا SSL خریدهاید ولی Access owner، Log، Incident contact و Recovery ندارید، بخشی از هزینه واقعی حذف شده است.
ریسک را با سناریو ثبت کنید:
| سناریو | کنترل پیشگیرانه/آمادگی | اثر هزینهای |
|---|---|---|
| Credential compromise | MFA، Least privilege، access review | تحقیق، Reset، Downtime و اصلاح داده |
| Plugin/API vulnerability | Inventory، patch SLA، staging test | Emergency change و Incident response |
| Data loss | Backup، retention و restore drill | بازسازی، تراکنش ازدسترفته و پشتیبانی |
| DDoS/traffic spike | Capacity، rate limit، CDN/WAF، runbook | Overage، فروش ازدسترفته و Mitigation |
| Third-party outage | Timeout، fallback و reconciliation | کار دستی، Retry و سفارش نامشخص |
برای تعیین سبد کنترل و ذخیره ریسک، از راهنمای بودجه امنیت سایت استفاده کنید. «هک نشدیم» معیار صرفهجویی نیست؛ آمادگی باید با Evidence و Drill سنجیده شود.
Downtime و اختلال؛ فقط هزینه Hosting نیست
اثر قطعی به Journey و زمان وابسته است. یک دقیقه در نیمهشب سایت شرکتی با یک دقیقه Checkout در کمپین یکسان نیست. مدل ساده:
Incident impact = Lost contribution + Recovery labor + Provider/forensic cost + Support/refund cost + Follow-on effects
از Revenue خام بهعنوان «زیان» استفاده نکنید؛ Margin، سفارشهای جابهجاشده به زمان دیگر و عدم قطعیت را لحاظ کنید. برای اندازهگیری، HTTP check عمومی کافی نیست؛ DNS، TLS، Login، Search، Cart و Payment journey ممکن است مستقل خراب شوند. طراحی Probe و Alert در راهنمای مانیتورینگ آپتایم توضیح داده شده است.
Scope creep، تغییر و هزینه تصمیم دیرهنگام
هر تغییر Scope creep نیست. گاهی شواهد جدید، تغییر قانونی/قراردادی یا نقص فرض اولیه، تغییر را ضروری میکند. مشکل وقتی است که تصمیم بدون برآورد Impact و پذیرش رسمی وارد Build شود.
| فیلد Change request | پرسش |
|---|---|
| Reason/Evidence | چه مسئله یا داده تازهای تغییر را توجیه میکند؟ |
| Scope impact | Design، Code، Content، Data و Operation چه تغییری میکنند؟ |
| Cost/schedule | بازه هزینه، زمان و Confidence چیست؟ |
| Risk/dependency | چه Integration یا Acceptance دوباره تست میشود؟ |
| Trade-off | چه چیزی حذف، عقب یا ساده میشود؟ |
| Decision | چه کسی، چه زمانی و با کدام Budget تأیید کرد؟ |
«تغییر کوچک» ممکن است در UI کوچک ولی در Data، Analytics، Permission و Support بزرگ باشد. پیش از Estimate، Impact map بسازید و با Thin slice عدم قطعیت را کم کنید.
بدهی فنی؛ بهرهای که در Invoice اولیه نیست
راهحل سریع ممکن است تصمیم عقلانی باشد، اگر اصل، بهره و Trigger بازپرداخت ثبت شود. Shortcut بدون Owner به کندی Release، Defect تکراری، آسیبپذیری، On-call و دشواری استخدام تبدیل میشود.
- Debt item و علت ایجاد؛
- مسیرها و سرویسهای متاثر؛
- بهره قابل مشاهده: ساعت Rework، Incident یا Lead time؛
- Risk و Deadline؛
- گزینه Refactor/Replace/Accept؛
- Owner و Review cadence.
روش ساخت Debt register و انتخاب Refactor در برابر Rewrite را در راهنمای مدیریت بدهی فنی بخوانید.
Vendor lock-in و هزینه خروج
هزینه خروج را پیش از ورود اندازه بگیرید. راهنمای انتخاب فناوری GOV.UK نیز بر کمینهکردن TCO، کاهش Lock-in، کنترل داده و توان تغییر تصمیم در آینده تأکید دارد. برای سایت این موارد را آزمایش کنید:
- مالک Registrant دامنه، DNS، Analytics، Search Console و حسابهای Provider؛
- دسترسی به Source، Build، Theme، Config و Secret inventory؛
- Export محتوا با Fieldها، Media، Alt و Metadata؛
- Export کاربر/سفارش/Consent طبق مجوز و نیاز؛
- URL inventory، Redirect map و تاریخچه تغییر؛
- دانش عملیاتی، Runbook، معماری و Vendor contact؛
- هزینه Data egress، Parallel run، Archive و حذف امن؛
- مهلت و قالب تحویل پس از خاتمه قرارداد.
یک Export file کافی نیست. Export→Import را روی محیط مستقل تمرین کنید و موارد ازدسترفته را ثبت کنید. اگر Platform مالکیت و خروج را مبهم میکند، راهنمای انتخاب سایتساز و Exit plan را به قرارداد تبدیل کنید.
ریسکهای هزینهای ویژه بازار ایران
هیچ درصد ثابتی برای ارز یا تورم منتشر نکنید. محرکها را جدا بسازید و داده را در زمان تصمیم بهروز کنید:
- Currency exposure: کدام License، Cloud، Font، CDN یا API ارزی است؟ نرخ مبنا، تاریخ و Renewal چه زمانی است؟
- Billing continuity: مسیر پرداخت رسمی، مالک حساب، Invoice و امکان تمدید اضطراری چیست؟
- Access/eligibility: شرایط خدمت و دسترسی Provider برای کسبوکار و کشور شما چیست؟ راهحل حیاتی را بر دورزدن شرایط بنا نکنید.
- Network split: تجربه داخل/خارج ایران و چند اپراتور، DNS، CDN و سرویس ثالث را تست کنید.
- Provider dependency: پیامک، ایمیل، نقشه، درگاه و احراز هویت Fallback و Reconciliation دارند؟
- Talent/continuity: آیا دانش فقط نزد یک فرد یا Vendor است؟ مستندات و Handover چه هزینهای دارد؟
- Contract indexing: تعدیل قیمت با چه شاخص، زمان، سقف، Notice و حق خروج تعریف شده است؟
سناریوها را مستقل نگه دارید: افزایش ارز، دوبرابرشدن مصرف، تغییر پلن و خرابی Vendor چهار ریسک متفاوتاند. ترکیب همه در یک «ذخیره ۲۰درصدی» علت و Owner را پنهان میکند.
Cost register؛ دفتر کنترل هزینه واقعی
یک Spreadsheet ساده میتواند از ابزار پیچیده مفیدتر باشد، اگر فیلدهای تصمیم را داشته باشد:
| فیلد | نمونه محتوا |
|---|---|
| Cost item / Owner | SMS OTP / مدیر محصول |
| Category / lifecycle | Variable / Operate |
| Billing unit | Attempt، Delivered یا Verified user |
| Base volume | برگرفته از Pilot یا داده فعلی |
| Rate/currency/date | Quote مستند با تاریخ اعتبار |
| Cadence/renewal | ماهانه؛ تمدید در تاریخ مشخص |
| Trigger | عبور از حجم، Seat یا پلن |
| Scenario | Base/Downside و فرض هر کدام |
| Evidence | Contract، invoice، console یا usage export |
| Actual/variance | مبلغ واقعی و توضیح انحراف |
| Exit/cancel | Notice، Export، fee و حذف داده |
هزینه ریسک را چگونه وارد کنیم؟
برای مقایسه، میتوان از Expected Monetary Value بهعنوان تقریب استفاده کرد:
Expected risk cost = Probability × Impact
این عدد پیشبینی قطعی یا سقف زیان نیست. ریسکهای Tail، همبستگی و عدمقطعیت احتمال را جدا توضیح دهید. بعضی سناریوهای شدید با احتمال کم، بهجای میانگین بودجه به Contingency، بیمه، Contract control یا Continuity plan نیاز دارند.
سه مثال ایرانی بدون قیمت ثابت
سایت شرکتی B2B
Quote شامل طراحی ۱۵ صفحه است. Cost register آشکار میکند که مصاحبه متخصصان، تدوین Case study، عکاسی، مهاجرت ۸۰ مقاله، CRM form routing، آموزش Editor، مانیتورینگ و بازبینی فصلی جدا هستند. تصمیم ممکن است حذف آنها نباشد؛ میتوان Launch را دو مرحله کرد و اول صفحات دارای تقاضا و Evidence را کامل تحویل داد.
فروشگاه با چند هزار SKU
هزینه طراحی در برابر Data work کوچک است. Attribute normalization، Variant، Media، موجودی، URL map، Search، Feed، درگاه، پیامک، Reconciliation، Support و Return driver اصلیاند. Metric درست فقط «هزینه ماهانه» نیست؛ هزینه فناوری و عملیات بهازای سفارش Paid و Kept باید دیده شود.
Landing page کمپین
صفحه سریع ساخته میشود، اما Burst traffic، Bot، Form delivery، CRM capacity، پیامک، Support و Rollback فراموش میشوند. Load test کوچک، Capacity limit، Budget alert و Runbook کمپین ارزانتر از Scale اضطراری و Lead گمشدهاند.
قرارداد چگونه هزینه پنهان را آشکار میکند؟
مشاور حقوقی باید متن متناسب با قرارداد شما را بازبینی کند؛ اما از منظر محصول و عملیات، این پیوستها ضروریاند:
- Scope با In/Out، Assumption، Dependency و Constraint؛
- WBS و تحویلدادنی قابل مشاهده؛
- Acceptance criteria و دوره رفع Defect؛
- تفکیک Bug، Change request، Support و Enhancement؛
- نرخ/روش برآورد Change و حق رد یا De-scope؛
- License/third-party register و مسئول Renewal؛
- SLA، Severity، ساعت پوشش و Escalation؛
- Security/backup/monitoring outcomes و Evidence؛
- مالکیت Domain، Data، Source، Design و Account؛
- Handover، Documentation، Training و Exit assistance؛
- Price adjustment، Notice، Termination و Data deletion؛
- Change log و Invoice traceability به Cost item.
عبارت «تمام امکانات موردنیاز» یا «پشتیبانی کامل» قابل پذیرش نیست. هرکدام را به Service، حجم، ساعت، استثنا و Evidence تبدیل کنید.
کاهش هزینه با حذف کنترل فرق دارد
| اقدام ظاهراً ارزان | جایگزین کنترلشده |
|---|---|
| حذف QA | Risk-based test روی Journey حیاتی و Device واقعی |
| حذف Backup مستقل | Retention متناسب + Restore drill محدود ولی واقعی |
| خرید ارزانترین Hosting | Capacity/Support/Recovery fit و Pilot |
| افزونه برای هر Feature | Capability map، تعداد کمتر و Owner/Exit |
| همه قابلیتها در نسخه اول | Thin slice با Outcome و Trigger توسعه |
| یک Vendor برای همه حسابها | مالکیت حساب کسبوکار و Access register |
| ذخیره درصدی کور | Risk register و Contingency مبتنی بر سناریو |
صرفهجویی پایدار معمولاً از کاهش پیچیدگی، حذف Feature بیمصرف، استانداردسازی، Automation قابل نگهداری، قرارداد روشن و جلوگیری از Rework میآید؛ نه از حذف Security، Accessibility یا Recovery.
ریتم کنترل هزینه پس از Launch
| تناوب | بررسی | تصمیم |
|---|---|---|
| روزانه/هفتگی | Anomaly مصرف، Incident و Delivery failure | Contain، Retry یا Escalate |
| ماهانه | Invoice در برابر Usage/Cost center و Unit metric | اصلاح Waste، Forecast یا Budget |
| فصلی | License/Seat، Vendor SLA، Content، Debt و Risk | Keep/Renegotiate/Replace/Retire |
| پیش از Renewal | قیمت، پلن، وابستگی، Export و گزینه جایگزین | Renew، De-scope یا Exit |
| سالانه | TCO actual، Business outcome و Roadmap | Invest، maintain، consolidate یا migrate |
برنامه ۳۰روزه ممیزی هزینههای پنهان سایت
- روز ۱ تا ۵: قرارداد، Invoice، Provider، Account، License، Architecture و Ownerها را Inventory کنید.
- روز ۶ تا ۱۰: همه هزینهها را به Setup/Recurring/Variable/Internal/Risk/Exit و Lifecycle نگاشت کنید.
- روز ۱۱ تا ۱۵: Billing unit، Usage baseline، Renewal، Currency و Evidence را کامل کنید.
- روز ۱۶ تا ۲۰: پنج سناریوی پرریسک و هزینه Restore/Incident/Exit را با Drill یا Sample بسنجید.
- روز ۲۱ تا ۲۵: TCO Base/Downside، Unit economics و انحراف Actual را محاسبه کنید.
- روز ۲۶ تا ۳۰: اقدامها را به Stop/Reduce/Renegotiate/Automate/Accept/Transfer تقسیم و Owner/Deadline تعیین کنید.
چکلیست نهایی هزینه واقعی سایت
- افق TCO و مرز هزینه تعریف شده است.
- هزینه نقدی، داخلی، متغیر، ریسک و خروج جدا هستند.
- هر Quote روی Scope و واحد یکسان Normalized شده است.
- محتوا، داده، Migration، Integration و QA Owner دارند.
- License، پلن، Renewal، ارز و Cancellation ثبت شدهاند.
- Service catalog نگهداری با Cadence و Evidence وجود دارد.
- Backup با Restore drill و Monitoring با Runbook همراه است.
- Usage به Cost center و Unit economics وصل شده است.
- Change request اثر بر Cost/Schedule/Risk و Trade-off دارد.
- Domain، Data، Source، Account، Export و Exit تحت کنترلاند.
- Base و Downside بر فرضهای تاریخدار استوارند.
- Actual در برابر Forecast با Owner انحراف بازبینی میشود.
پرسشهای متداول هزینههای پنهان سایت
هزینه نگهداری سایت ماهانه چقدر است؟
عدد عمومی معتبری وجود ندارد. نوع سایت، Journey حیاتی، ترافیک، داده، Integration، SLA، امنیت، محتوا و توان تیم Driver هستند. Service catalog و حجم مصرف را مشخص کنید و سه سناریوی Base/Downside/Upside بسازید؛ قیمت بدون Scope و تاریخ قابل مقایسه نیست.
برای هزینه پیشبینینشده چند درصد ذخیره بگذاریم؟
درصد ثابت برای همه پروژهها مناسب نیست. Risk register بسازید، احتمال/اثر و همبستگی را بررسی و Contingency را از سناریوها استخراج کنید. ریسکهای شدید ممکن است به کنترل، قرارداد، بیمه یا Continuity plan نیاز داشته باشند، نه فقط ذخیره نقدی.
سایت ارزان همیشه در بلندمدت گرانتر میشود؟
خیر. Template یا SaaS ساده اگر با Requirement Fit باشد میتواند TCO کمتری داشته باشد. خطر وقتی است که Quote ارزان، هزینه لازم را حذف، مسئولیت را مبهم یا خروج را قفل کند. گزینهها را با Scope، TCO، Risk و Evidence یکسان مقایسه کنید.
آیا هزینه محتوا و سئو جزو هزینه سایت است؟
محتوای لازم برای Launch، Migration، Metadata و SEO release داخل هزینه ساخت/راهاندازی است. تولید مستمر و جذب تقاضا میتواند سبد عملیاتی یا بازاریابی جدا باشد. مرز را مکتوب کنید تا نه حذف شود و نه دوبارهشماری رخ دهد.
مهمترین هزینه پنهان سایت چیست؟
یک پاسخ ثابت ندارد؛ اما کار داخلی، داده/محتوا، Integration operations، Incident/Recovery و Exit اغلب کمبرآورد میشوند. برای یک فروشگاه، Reconciliation و پشتیبانی سفارش ممکن است بزرگتر از Hosting باشد؛ برای سایت B2B، تولید Evidence و نگهداری محتوا.
منابع رسمی برای طراحی کنترل هزینه
- راهنمای GOV.UK برای انتخاب فناوری، TCO، کنترل داده و کاهش Lock-in
- FinOps Framework برای هزینه/مصرف، Forecast، Allocation و Unit economics
- NIST Cybersecurity Framework ۲.۰ برای Govern تا Recover
- راهنمای CISA برای Backup، Restore test و آمادگی حادثه
- راهنمای W3C برای بودجه، مسئولیت و پایش مستمر دسترسپذیری
هزینه پنهان زمانی قابل مدیریت میشود که نام، واحد، Owner، Trigger و Evidence داشته باشد. هدف «صفرکردن هزینه سایت» نیست؛ باید بدانید هر هزینه چه Outcome یا ریسکی را پوشش میدهد، کجا Waste است و کجا حذف آن فقط صورتحساب را به آینده منتقل میکند.






