وقتی برای طراحی سایت شرکتی، فروشگاه، یا یک نرم‌افزار/پنل اختصاصی «قیمت بدهید» می‌نویسید و سه پاسخ کاملاً متفاوت می‌گیرید — یکی ۲۰ میلیون، یکی ۱۲۰، یکی «بسته به جزئیات» — معمولاً مشکل از بازار نیست؛ از استعلام ناقص است. مجری‌ها روی فرض‌های مختلف قیمت می‌گذارند؛ شما هم بعداً سیب را با پرتقال مقایسه می‌کنید.
این مقاله از زاویه خریدار / کارفرما نوشته شده است: چطور یک RFQ (Request for Quote) یا همان استعلام قیمت ساخت‌یافته بنویسید تا پیشنهادها قابل‌مقایسه شوند، ریسک پنهان کم شود، و بتوانید در ۱۴۰۵ تصمیم آگاهانه بگیرید. تمرکز ما روی «چطور بخواهید» است؛ نه چک‌لیست عمومی طراحی از بریف تا انتشار (آن مسیر در مقاله جداگانه پونوکد آمده).
RFQ چیست و با بریف طراحی چه فرقی دارد؟
بریف طراحی معمولاً می‌گوید پروژه چیست، مخاطب کیست، و ظاهر/تجربه چه حسی باید داشته باشد.
RFQ / استعلام قیمت سندی است که به چند مجری می‌فرستید تا روی یک محدوده مشخص قیمت، زمان، تحویل‌دادنی‌ها و شرایط همکاری بدهند.
اگر فقط بنویسید «سایت شرکتی مدرن می‌خواهم، قیمت؟» هر تیم تفسیر خودش را می‌گذارد: ۵ صفحه استاتیک، یا ۳۰ صفحه + بلاگ + سئو فنی + پنل + اتصال درگاه. نتیجه: پیشنهادهای غیرقابل‌مقایسه و مذاکره فرسایشی.
هدف RFQ خوب این است که:
- همه روی یک تعریف محدوده (Scope) قیمت بدهند
- فرض‌های باز (هاست، محتوا، سئو، پشتیبانی) روشن شود
- خروجی‌ها و مالکیت (سورس، دامنه، دسترسی‌ها) از اول مشخص باشد
- شما بتوانید با یک جدول ساده، پیشنهادها را امتیاز بدهید — نه فقط ارزان‌ترین را انتخاب کنید
چرا استعلام‌های مبهم در بازار ایران گران تمام می‌شوند؟
چند الگوی تکراری:
- قیمت پایین با محدوده پنهان: «طراحی سایت» بدون ذکر تعداد صفحات، فرم‌ها، چندزبانه، درگاه، یا نقش‌های کاربری
- قیمت بالا با پکیج مبهم: سئو، تولید محتوا، تبلیغات و پشتیبانی سه‌ماهه داخل یک رقم قاطی شده‌اند
- زمان تحویل بدون وابستگی‌ها: «۴۵ روز» بدون اینکه مشخص شود تأخیر تأیید طرح یا تحویل محتوا چه اثری دارد
- مالکیت نامشخص: سورس، هاست، اکانت‌ها و لایسنس‌ها بعد از پرداخت آخر روشن می‌شود — وقتی دیر است
مقاله «هزینه طراحی سایت ۱۴۰۵» بازه تقریبی بازار را نشان می‌دهد؛ RFQ کمک می‌کند بفهمید پیشنهاد وسط آن بازه واقعاً چه چیزی را پوشش می‌دهد.
قبل از ارسال استعلام؛ سه تصمیم که باید خودتان بگیرید
بدون این سه مورد، حتی بهترین جدول RFQ هم کم‌اثر است:
۱) هدف کسب‌وکار را در یک جمله بنویسید
مثال‌های خوب:
- «می‌خواهیم از جستجوی گوگل و صفحه خدمات، هفته‌ای X تماس مشاوره بگیریم»
- «می‌خواهیم کاتالوگ B2B با فرم استعلام و پنل نماینده داشته باشیم»
- «می‌خواهیم MVP پنل سفارش داخلی را در ۹۰ روز به تیم فروش بدهیم»
جمله بد: «سایت شیک و حرفه‌ای.»
۲) نوع محصول را انتخاب کنید (حتی اگر بعداً عوض شود)
- سایت معرفی / شرکتی
- فروشگاه (ووکامرس یا اختصاصی)
- لندینگ تبلیغاتی
- وب‌اپ / پنل / CRM سبک / سامانه سفارش
- ترکیب (مثلاً سایت + پنل مشتریان)
این انتخاب روی تیم، زمان و قیمت اثر مستقیم دارد؛ در RFQ بنویسید «فرض فعلی ما X است؛ اگر Y به‌صرفه‌تر است در پیشنهاد توضیح دهید.»
۳) بودجه را به‌صورت بازه یا سقف اعلام کنید (ترجیحاً)
خیلی از کارفرماها بودجه را پنهان می‌کنند تا «ارزان‌ترین» پیدا شود. در عمل، مجری حرفه‌ای یا انصراف می‌دهد یا محدوده را تا حد بودجهٔ فرضی کوچک می‌کند. یک بازه مثل «بین A تا B تومان برای فاز اول» پیشنهادهای واقعی‌تر می‌سازد. اگر بودجه قطعی ندارید، حداقل بنویسید «فاز اول باید زیر سقف B باشد؛ بقیه در فاز ۲.»
ساختار پیشنهادی سند RFQ (یک صفحه تا سه صفحه کافی است)
این قالب را کپی کنید و برای سایت یا نرم‌افزار پر کنید:
- خلاصه پروژه و هدف اندازه‌پذیر
- وضعیت فعلی: دامنه دارید؟ سایت قبلی؟ محتوا آماده است؟ برندبوک؟
- کاربران و نقش‌ها: بازدیدکننده، مشتری، ادمین، نماینده، اپراتور…
- محدوده فاز ۱ (Must-have) در برابر فاز ۲ (Nice-to-have)
- تحویل‌دادنی‌ها: طراحی UI، فرانت، بک‌اند، محتوا، آموزش، مستند
- الزامات فنی غیرقابل‌مذاکره: مثلاً مالکیت سورس، هاست به نام کارفرما، SSL، نسخه موبایل، اتصال درگاه ایرانی، پشتیبان‌گیری
- یکپارچه‌سازی‌ها: پیامک، درگاه، حسابداری، CRM، واتساپ، ایمیل سازمانی
- زمان‌بندی مطلوب و محدودیت‌های شما (کمپین، نمایشگاه، فصل فروش)
- معیارهای ارزیابی پیشنهاد (قیمت فقط یکی از وزن‌ها)
- نحوه ارسال پیشنهاد و مهلت (مثلاً تا ۷ روز کاری، با فایل یا جلسه ۳۰ دقیقه‌ای)
هرچه Must-have کوتاه‌تر و واقعی‌تر باشد، پیشنهادها نزدیک‌تر می‌شوند.
۲۰ سؤال که باید در استعلام بگذارید (و جواب کتبی بخواهید)
از مجری بخواهید به این ۲۰ مورد به‌صورت شماره‌دار پاسخ دهد. همین کار پیشنهادها را هم‌تراز می‌کند.
محدوده و فرض‌ها
- دقیقاً چه صفحات/ماژول‌هایی در قیمت فاز ۱ هستند؟ (لیست)
- چه چیزهایی عمداً خارج از محدوده است؟
- فرض شما درباره تعداد زبان، ارز، درگاه و روش‌های ارسال چیست؟
- محتوا را چه کسی تأمین می‌کند؟ اگر تأخیر محتوا رخ دهد زمان‌بندی چطور جابه‌جا می‌شود؟
طراحی و تجربه کاربری
- چند دور بازبینی طرح (wireframe/UI) در قیمت است؟
- طراحی موبایل از اول هست یا «بعداً ریسپانسیو می‌کنیم»؟
- آیا طراحی بر اساس کامپوننت/سیستم یکپارچه است یا صفحه به صفحه؟
فنی، امنیت، مالکیت
- فناوری پیشنهادی چیست و چرا برای این پروژه مناسب است؟
- سورس کد، ریپازیتوری و دسترسی ادمین در پایان هر فاز به نام چه کسی است؟
- هاست/سرور و دامنه به نام کارفرما ثبت می‌شود؟ چه سطحی از دسترسی می‌دهید؟
- پشتیبان‌گیری، ریکاوری و مسئولیت امنیت در دوره توسعه با کیست؟
سئو، سرعت، اندازه‌گیری
- سئو فنی پایه (ایندکس، نقشه سایت، متا، سرعت موبایل) داخل قرارداد هست یا جدا؟
- هدف تبدیل چیست و چه ردیابی‌ای (فرم، تماس، تگ مدیریتی) نصب می‌شود؟
- اگر سایت قبلی داریم، برنامه انتقال URL و ریدایرکت چیست؟
زمان، تیم، پشتیبانی
- برنامه زمان‌بندی فازها و نقاط تأیید کارفرما چیست؟
- تیم ثابت پروژه چه نقش‌هایی دارد؟ (مدیر پروژه، طراح، فرانت، بک)
- بعد از تحویل، چند روز/ماه پشتیبانی رفع باگ رایگان است و چه چیزی پشتیبانی محسوب نمی‌شود؟
- نرخ تغییر محدوده (Change Request) چطور محاسبه می‌شود؟
تجاری
- شکست پرداخت چگونه است و به چه تحویل‌دادنی‌هایی وصل است؟
- چه تضمین یا شرایط فسخ برای تأخیر غیرموجه طرفین وجود دارد؟
اگر مجری از پاسخ کتبی به این‌ها طفره رفت، همان سیگنال مهمی است — قبل از قرارداد، نه بعد از پیش‌پرداخت.
CTA نرم: اگر برای پروژه سایت یا نرم‌افزارتان وقت تنظیم RFQ کامل را ندارید، یک بریف نیم‌صفحه‌ای (هدف، Must-have فاز ۱، وضعیت فعلی، سقف بودجه تقریبی) بفرستید تا همان را به استعلام قابل‌مقایسه تبدیل کنیم یا روی آن پیشنهاد شفاف بدهیم. ۰۹۹۱۵۶۱۵۹۴۶ | تلگرام | تماس
چطور پیشنهادها را امتیاز بدهید؟ (نه فقط قیمت)
یک جدول ساده با وزن نمونه برای کارفرمای ایرانی:
| معیار | وزن پیشنهادی | چه چیزی را می‌سنجید؟ |
|---|---|---|
| انطباق با Must-have | ۲۵٪ | آیا همان محدوده را قیمت داده؟ |
| شفافیت فرض‌ها و خارج‌ازمحدوده | ۱۵٪ | ابهام کمتر = ریسک کمتر |
| مالکیت، دسترسی، هاست | ۱۵٪ | سورس و اکانت‌ها مال شماست؟ |
| کیفیت نمونه کار مرتبط | ۱۵٪ | پروژه شبیه مسئله شما، نه فقط زیبا |
| زمان‌بندی واقع‌بینانه | ۱۰٪ | وابستگی به تأیید/محتوای شما دیده شده؟ |
| پشتیبانی و نگهداری | ۱۰٪ | بعد از تحویل چه می‌ماند؟ |
| قیمت کل فاز ۱ | ۱۰٪ | در بازه منطقی نسبت به محدوده |
توجه: وزن قیمت را عمداً پایین نگه داشتیم. در پروژه‌های نرم‌افزاری، ارزان‌ترین پیشنهادِ مبهم معمولاً گران‌ترین تمام‌شده است.
برای مقایسه قیمت، همه را به یک واحد برسانید: «هزینه فاز ۱ تا تحویل قابل‌استفاده + ۳ ماه نگهداری پایه». اگر یکی سئو و محتوا را داخل کرده و دیگری نه، یا جدا کنید یا از بقیه بخواهید همان را قیمت بدهند.
تفاوت استعلام سایت با استعلام نرم‌افزار / پنل
اگر موضوع «سایت» است
روی این‌ها بیشتر تأکید کنید: تعداد قالب صفحات، بلاگ، سئو فنی، سرعت، فرم‌ها، اتصال درگاه/پیامک، انتقال از سایت قبلی، محتوا.
اگر موضوع «نرم‌افزار / وب‌اپ / سامانه» است
علاوه بر UI، این‌ها را صریح بنویسید:
- نقش‌ها و سطح دسترسی
- موجودیت‌های اصلی (سفارش، موجودی، تیکت، قرارداد…)
- گردش‌کار (Workflow) حداقل فاز ۱
- گزارش‌ها و خروجی اکسل/PDF
- حجم تقریبی کاربران هم‌زمان
- محیط‌های Staging و Production
- روش آموزش کاربران و تحویل مستند
بدون Workflow فاز ۱، قیمت نرم‌افزار بیشتر حدس است تا برآورد.
اشتباهات رایج کارفرما در استعلام قیمت
- فرستادن پیامک یک‌خطی به ۱۰ نفر و انتظار پیشنهاد جدی
- کپی کردن کل آرزوها در فاز ۱ بدون اولویت
- پنهان کردن سایت/نمونه رقیب در حالی که بعداً می‌گویید «مثل همان شود»
- مقایسه فقط رقم پایین بدون خواندن خارج‌ازمحدوده
- شروع کار با پیش‌پرداخت بالا قبل از تثبیت مالکیت دامنه/ریپو/هاست
- خلط RFQ با مناقصه نمایشی — اگر از قبل مجری را انتخاب کرده‌اید، صادق باشید؛ وقت همه را نگیرید
مقاله فریلنسر در برابر شرکت طراحی سایت پونوکد را هم کنار این چک‌لیست ببینید: نوع مجری روی ریسک تحویل اثر دارد، اما بدون RFQ خوب هیچ‌کدام قابل‌مقایسه نیستند.
نمونه کوتاه؛ پاراگراف طلایی اول استعلام
می‌توانید استعلام را این‌طور شروع کنید:
«ما یک شرکت خدماتی در تهران هستیم. هدف فاز ۱: سایت شرکتی + ۳ صفحه خدمت + بلاگ + فرم تماس متصل به پیامک، با تمرکز روی جذب تماس از گوگل. سایت فعلی وردپرسی قدیمی داریم و دامنه به نام خودمان است. محتوا را خودمان طی ۲ هفته پس از تأیید طرح می‌دهیم. Must-have فاز ۱: موبایل‌اول، سئو فنی پایه، مالکیت سورس و هاست به نام ما، آموزش ۳۰ دقیقه‌ای پنل. خارج از فاز ۱: فروشگاه، چندزبانه، اپ موبایل. سقف بودجه فاز ۱: … تومان. لطفاً تا تاریخ … به ۲۰ سؤال پیوست و جدول زمان‌بندی/شکست پرداخت پاسخ دهید.»
همین یک پاراگراف، کیفیت پیشنهادها را جهش می‌دهد.
جمع‌بندی؛ استعلام خوب = خرید قابل‌دفاع
در ۱۴۰۵ که هزینه طراحی سایت و نرم‌افزار شفاف‌تر از قبل در محتواهای عمومی مطرح می‌شود، مزیت رقابتی کارفرما دیگر «پیدا کردن شماره تلفن مجری» نیست؛ نوشتن استعلامی است که پیشنهادها را هم‌کف کند. RFQ خوب:
- محدوده فاز ۱ را قفل می‌کند
- فرض‌ها را از قیمت جدا می‌کند
- مالکیت و پشتیبانی را پیش از قرارداد روشن می‌کند
- به شما اجازه می‌دهد با امتیازدهی — نه احساس — انتخاب کنید
اگر مقاله «چک لیست طراحی سایت؛ از بریف و قرارداد تا انتشار» را مسیر اجرای پروژه بدانید، این راهنما ابزار قبل از انتخاب مجری است: همان جایی که بیشترین پول با ابهام می‌سوزد.
درخواست بررسی بریف و استعلام قیمت (CTA پایانی)
اگر می‌خواهید قبل از ارسال به چند شرکت، بریف یا RFQ پروژه‌تان را جمع‌وجور و قابل‌مقایسه کنید — یا مستقیم از پونوکد پیشنهاد شفاف برای فاز ۱ بگیرید — با ما صحبت کنید:
- تلفن / واتساپ: ۰۹۹۱۵۶۱۵۹۴۶
- تلگرام: t.me/resonea
- فرم تماس: /contact یا صفحه /pricing
- خدمات مرتبط: طراحی سایت · سایت و وب‌اپ · توسعه وب اختصاصی · پنل و CRM
برای شروع، همین‌ها کافی است: نوع پروژه (سایت/نرم‌افزار)، هدف فاز ۱، وضعیت فعلی (دامنه، سایت قبلی، محتوا)، Must-have در برابر Nice-to-have، و سقف یا بازه بودجه.
سؤالات متداول
آیا باید بودجه را در RFQ بنویسیم؟ بازه یا سقف معمولاً پیشنهادهای واقعی‌تر می‌سازد. اگر نمی‌نویسید، حداقل معیار اولویت (زمان، کیفیت، مالکیت) را شفاف کنید تا مجری بداند روی چه چیزی بهینه‌سازی کند.
چند مجری برای استعلام کافی است؟ معمولاً ۳ تا ۵ پیشنهاد با RFQ یکسان بهتر از ۱۰ پیامک پراکنده است. بیش از این، زمان مقایسه را می‌سوزاند مگر پروژه بزرگ سازمانی باشد.
تفاوت این مقاله با چک‌لیست طراحی سایت پونوکد چیست؟ چک‌لیست طراحی روی مسیر بریف تا قرارداد و انتشار تمرکز دارد. این مقاله روی نوشتن استعلام قیمت و مقایسه پیشنهادهای چند مجری قبل از انتخاب است.
برای نرم‌افزار اختصاصی همان ۲۰ سؤال کافی است؟ پایه همان است؛ حتماً نقش‌ها، Workflow فاز ۱، محیط Staging و معیار پذیرش (Acceptance) را اضافه کنید. بدون این‌ها برآورد نرم‌افزار پایدار نمی‌ماند.
اگر فقط یک مجری مدنظرمان است، باز هم RFQ لازم است؟ بله — حتی برای یک مجری، RFQ داخلی جلوی تغییر محدوده بی‌صدا و اختلاف بعد از پیش‌پرداخت را می‌گیرد.
