تصویر شاخص مقاله قرارداد طراحی سایت؛ ۱۰ بند ضروری که پیش از امضا باید چک کنید
مقاله۱۱ دقیقه مطالعه

قرارداد طراحی سایت؛ ۱۰ بند ضروری که پیش از امضا باید چک کنید

قرارداد طراحی سایت چه بندهایی لازم دارد؟ از شرح کار و پرداخت مرحله‌ای تا مالکیت دامنه، هاست و سورس‌کد؛ چک‌لیست عملی را پیش از امضا بخوانید و ضرر نکنید.

م
تیم مای طرح
تحریریه مای طرح

قرارداد طراحی سایت مهم‌ترین سندی است که پیش از شروع پروژه امضا می‌کنید و بیشتر اختلاف‌های میان کارفرما و طراح، از بندهایی شروع می‌شود که یا نوشته نشده‌اند یا مبهم نوشته شده‌اند. در این مقاله فهرست عملی بندهایی را مرور می‌کنیم که هر قرارداد طراحی سایت باید داشته باشد، همراه با نمونهٔ جمله‌بندی و نشانه‌های خطر. این متن راهنمایی تجربی برای آماده شدن است، نه مشاورهٔ حقوقی؛ نسخهٔ نهایی قرارداد را حتماً یک وکیل یا مشاور حقوقی بررسی کند.

چرا قرارداد طراحی سایت مکتوب و دقیق لازم است؟

طراحی سایت پروژه‌ای چندهفته‌ای است که در آن دو طرف مدام تصمیم می‌گیرند: چه صفحه‌هایی ساخته شود، ظاهر چطور باشد، محتوا را چه کسی بدهد و کار چه زمانی «تمام‌شده» حساب شود. وقتی این تصمیم‌ها فقط در پیام‌ها و تماس‌های تلفنی پراکنده باشد، دیر یا زود برداشت‌ها از هم فاصله می‌گیرد. رایج‌ترین موقعیت‌های اختلاف این‌ها هستند:

  • گسترش تدریجی کار: کارفرما امکانی را «بدیهی» می‌داند و طراح آن را خارج از توافق.
  • تأخیر: هر طرف دیگری را مقصر عقب افتادن پروژه می‌داند.
  • پرداخت: معلوم نیست قسط بعدی دقیقاً با چه تحویلی سررسید می‌شود.
  • مالکیت: دامنه یا هاست به نام طراح ثبت شده و پس از پایان همکاری، کارفرما به سایت خودش دسترسی ندارد.

قرارداد خوب قرار نیست بی‌اعتمادی نشان دهد؛ برعکس، با روشن کردن انتظارات، همکاری را آرام‌تر می‌کند. یک طراح حرفه‌ای معمولاً از قرارداد دقیق استقبال می‌کند، چون از او هم محافظت می‌کند.

چک‌لیست سریع بندهای قرارداد

پیش از رفتن سراغ جزئیات، این جدول را کنار پیش‌نویس قراردادتان بگذارید و بند به بند تیک بزنید:

بند چه چیزی را مشخص می‌کند نشانهٔ خطر
شرح کار صفحات، امکانات و موارد خارج از کار عبارت‌های کلی مثل «سایت کامل»
تحویل‌دادنی‌ها فایل‌ها، دسترسی‌ها، مستندات و آموزش فقط «تحویل سایت» بدون جزئیات
زمان‌بندی مراحل و تاریخ هر مرحله فقط تاریخ پایان کل پروژه
پرداخت مبلغ هر قسط و شرط سررسید آن پرداخت کامل پیش از شروع کار
اصلاحات تعداد دور اصلاح در هر مرحله «اصلاحات نامحدود» یا اصلاً نبودن این بند
محتوا مسئول تهیهٔ متن و تصویر و مهلت آن سکوت دربارهٔ محتوا
مالکیت دامنه، هاست، سورس‌کد، لایسنس‌ها ثبت دامنه یا هاست به نام طراح
پشتیبانی و گارانتی مدت رفع اشکال رایگان و خدمات بعدی نبود تعریف «اشکال»
محرمانگی حفاظت از اطلاعات دو طرف نبود بند یا بند یک‌طرفه
فسخ شرایط خروج و تسویهٔ کار انجام‌شده نبود بند فسخ

در ادامه هر بند را با جزئیات بیشتری بررسی می‌کنیم.

شرح کار و تحویل‌دادنی‌ها: پایهٔ هر قرارداد طراحی سایت

شرح کار (Scope) را فهرست‌وار بنویسید

به‌جای «طراحی سایت شرکتی»، فهرست صفحه‌ها و امکانات را بنویسید؛ مثلاً: صفحهٔ اصلی، درباره ما، سه صفحهٔ خدمات، وبلاگ، تماس با ما، فرم درخواست مشاوره با ارسال به ایمیل، نسخهٔ موبایل واکنش‌گرا و سئوی پایه (عنوان و توضیحات متا، نقشهٔ سایت). اگر سایت چندزبانه، فروشگاهی یا دارای پنل کاربری است، دقیقاً بنویسید چه چیزی شامل می‌شود. پلتفرم ساخت هم باید در همین بند بیاید؛ اینکه سایت با وردپرس ساخته می‌شود یا با کدنویسی اختصاصی، روی هزینه، نگهداری و مالکیت اثر مستقیم دارد. اگر هنوز بین این دو مردد هستید، مقالهٔ طراحی سایت با وردپرس یا کدنویسی کمکتان می‌کند.

موارد خارج از کار را هم صریح بنویسید

بندی با عنوان «خارج از محدودهٔ قرارداد» اختلاف‌های زیادی را پیش از وقوع حل می‌کند. مواردی مثل تولید محتوای متنی، عکاسی، خرید دامنه و هاست، تبلیغات، سئوی مستمر پس از تحویل یا اتصال به نرم‌افزار حسابداری، اگر در قیمت نیست، باید اینجا نام برده شود.

تحویل‌دادنی‌ها را ملموس کنید

در پایان پروژه دقیقاً چه چیزی به شما تحویل داده می‌شود؟ یک فهرست خوب معمولاً شامل این موارد است:

  • سایت راه‌اندازی‌شده روی دامنه و هاست کارفرما
  • نام کاربری و رمز مدیر اصلی سایت، هاست و پایگاه داده
  • سورس‌کد و فایل‌های طراحی (مثلاً فایل Figma)، طبق آنچه دربارهٔ مالکیت توافق شده
  • فهرست قالب، افزونه‌ها و سرویس‌های پولی به کار رفته و وضعیت لایسنس آن‌ها
  • یک نسخه بکاپ کامل هنگام تحویل
  • جلسه یا ویدئوی آموزش کار با پنل مدیریت

زمان‌بندی، مایلستون‌ها و پرداخت مرحله‌ای در قرارداد طراحی سایت

پروژه را به مراحل قابل‌تحویل بشکنید

تاریخ پایان به‌تنهایی کافی نیست. پروژه را به چند مایلستون تقسیم کنید که هرکدام خروجی قابل‌دیدن دارد، مثلاً:

  1. نیازسنجی و نقشهٔ صفحات (Sitemap)
  2. طراحی رابط کاربری صفحهٔ اصلی و تأیید آن
  3. طراحی سایر صفحات
  4. پیاده‌سازی و راه‌اندازی روی نسخهٔ آزمایشی
  5. تست، اصلاحات نهایی و انتقال به دامنهٔ اصلی

برای هر مرحله مدت کار طراح و مدت بررسی و پاسخ کارفرما را جداگانه بنویسید. بسیاری از تأخیرها از سمت کارفرماست، مثلاً دیر رسیدن محتوا یا تأییدها. بندی بنویسید که اگر پاسخ کارفرما دیر رسید، زمان‌بندی به همان اندازه جابه‌جا شود، و اگر طراح بدون دلیل موجه عقب افتاد، چه پیامدی دارد.

هر قسط را به یک تحویل گره بزنید

منطقی‌ترین ساختار پرداخت، پیش‌پرداخت برای شروع کار و بقیه به صورت اقساطی است که هرکدام پس از تأیید یک مایلستون سررسید می‌شود. نمونهٔ جمله‌بندی: «قسط دوم پس از تأیید کتبی طراحی صفحهٔ اصلی توسط کارفرما پرداخت می‌شود.» به این نکته‌ها هم توجه کنید:

  • تعریف «تأیید»: تأیید از چه راهی اعلام می‌شود (ایمیل، پیام‌رسان مشخص) و اگر کارفرما در مهلت معین پاسخ نداد چه می‌شود.
  • قسط آخر: بهتر است پس از راه‌اندازی روی دامنهٔ اصلی و تحویل دسترسی‌ها پرداخت شود، نه پیش از آن.
  • مالیات و هزینه‌های جانبی: روشن کنید مبلغ قرارداد شامل مالیات و عوارض قانونی (در صورت شمول) هست یا نه؛ این موضوع را با حسابدار خودتان هم بررسی کنید چون قواعدش ممکن است تغییر کند.
  • هزینه‌های شخص ثالث: دامنه، هاست، لایسنس قالب و افزونه جزو مبلغ است یا کارفرما جداگانه می‌پردازد؟

برای برآورد اولیهٔ بودجه و آشنایی با بسته‌ها می‌توانید تعرفه‌های طراحی سایت را ببینید.

دفعات اصلاح و درخواست تغییر را از هم جدا کنید

«اصلاحات نامحدود» جذاب به نظر می‌رسد، اما معمولاً یا عملاً اجرا نمی‌شود یا پروژه را بی‌پایان می‌کند. بهتر است قرارداد دو مفهوم را از هم جدا کند:

  • اصلاح (Revision): تغییر در چارچوب همان چیزی که توافق شده؛ مثل عوض کردن رنگ یک بخش یا جابه‌جایی چیدمان. تعداد دور‌های اصلاح در هر مرحله (مثلاً دو دور برای طراحی صفحهٔ اصلی) را مشخص کنید.
  • درخواست تغییر (Change Request): اضافه کردن چیزی که در شرح کار نبوده؛ مثل صفحهٔ جدید، زبان دوم یا یک امکان تازه. بنویسید این درخواست‌ها چطور ثبت، قیمت‌گذاری و به زمان‌بندی اضافه می‌شوند.

یک نکتهٔ کاربردی: همهٔ بازخوردهای هر دور را یک‌جا و در یک فهرست بفرستید، نه تکه‌تکه. هم کار طراح ساده‌تر می‌شود و هم شمارش دور‌ها شفاف می‌ماند.

محتوای سایت با کیست؟

یکی از دلایل رایج توقف پروژه‌ها، آماده نبودن محتواست. قرارداد باید روشن کند:

  • متن صفحه‌ها را چه کسی می‌نویسد و اگر با طراح است، ویرایش و تأیید آن چطور انجام می‌شود.
  • تصاویر از کجا می‌آید: عکس‌های خود کارفرما، عکاسی سفارشی یا بانک‌های تصویری با مجوز استفاده.
  • مسئولیت حق نشر تصاویر و متن‌هایی که کارفرما تحویل می‌دهد با خود کارفرماست؛ و طراح هم متعهد می‌شود از تصاویر و فونت‌های بدون مجوز استفاده نکند.
  • مهلت تحویل محتوا و اینکه اگر محتوا نرسید، طراح با متن نمونه جلو می‌رود یا کار متوقف می‌شود.

اگر قرار است سایت از ابتدا برای جستجو بهینه باشد، بنویسید که محتوای هر صفحه با در نظر گرفتن کلمات کلیدی تهیه می‌شود یا این کار جزو خدمات جداگانه است.

مالکیت سورس‌کد، دامنه، هاست و حساب‌ها

این بند شاید مهم‌ترین بند برای آیندهٔ کسب‌وکار شما باشد، چون پس از پایان همکاری هم اثرش باقی می‌ماند.

دامنه

دامنه باید به نام و با مشخصات خود کارفرما ثبت شود. برای دامنه‌های ‎.ir این یعنی ثبت با حساب کاربری خود کارفرما در ایرنیک؛ روال و شرایط به‌روز را از سایت رسمی ایرنیک بررسی کنید. اگر طراح دامنه را برای شما ثبت می‌کند، در قرارداد بنویسید که به نام کارفرما ثبت و اطلاعات حساب تحویل داده می‌شود. حساب کاربری دامنه را با ایمیل و شمارهٔ موبایلی بسازید که در اختیار خود مجموعه است، نه یک کارمند یا پیمانکار.

هاست و سرور

حساب هاست یا سرور هم بهتر است به نام کارفرما باشد و دسترسی مدیر کامل در اختیار او قرار گیرد. اگر سایت روی سرور طراح میزبانی می‌شود، شرایط انتقال به هاست دیگر و تحویل بکاپ کامل در صورت پایان همکاری را بنویسید.

سورس‌کد، فایل‌های طراحی و لایسنس‌ها

روشن کنید پس از تسویهٔ کامل، مالکیت یا حق استفادهٔ نامحدود از سورس‌کد و فایل‌های طراحی به کارفرما منتقل می‌شود. دو استثنای رایج را هم در نظر بگیرید: کتابخانه‌ها و ماژول‌هایی که طراح در پروژه‌های مختلف استفاده می‌کند (که معمولاً فقط حق استفاده منتقل می‌شود) و قالب‌ها و افزونه‌های تجاری که لایسنسشان تابع شرایط سازندهٔ اصلی است. همچنین بنویسید که آیا طراح می‌تواند نمونه‌کار را در نمونه‌کارها یا رزومهٔ خودش نمایش دهد یا نه.

پشتیبانی، دورهٔ گارانتی و محرمانگی

دورهٔ گارانتی رفع اشکال

پس از تحویل، معمولاً یک دورهٔ مشخص تعیین می‌شود که طی آن اشکال‌های فنی ناشی از کار طراح رایگان برطرف می‌شود. کلید این بند، تعریف «اشکال» است: رفتاری که با شرح کار توافق‌شده مطابقت ندارد. امکانات جدید، تغییر سلیقه‌ای در طراحی یا مشکلاتی که از دست‌کاری افراد دیگر یا نصب افزونهٔ جدید توسط کارفرما ایجاد شده، معمولاً شامل گارانتی نیست. مدت دوره، راه اعلام اشکال و زمان پاسخ‌گویی را بنویسید.

پشتیبانی پس از گارانتی

بعد از دورهٔ گارانتی، به‌روزرسانی، بکاپ و رفع مشکلات چه می‌شود؟ اگر قرارداد پشتیبانی جداگانه‌ای در کار است، به آن ارجاع دهید یا دست‌کم نحوهٔ محاسبهٔ هزینهٔ خدمات بعدی را مشخص کنید. برای سایت‌های وردپرسی این موضوع اهمیت بیشتری دارد، چون بدون به‌روزرسانی منظم امنیت سایت به‌مرور کاهش می‌یابد.

محرمانگی

در طول پروژه، طراح به اطلاعاتی مثل فهرست مشتریان، قیمت‌ها، دسترسی‌ها و برنامه‌های تجاری شما دسترسی پیدا می‌کند. بند محرمانگی باید مشخص کند چه اطلاعاتی محرمانه است، طراح نمی‌تواند آن را افشا یا برای کار دیگری استفاده کند، و این تعهد پس از پایان قرارداد هم باقی است. این بند بهتر است دوطرفه باشد، چون اطلاعات و روش‌های کاری طراح هم نیاز به حفاظت دارد.

فسخ قرارداد و تسویه در میانهٔ کار

هیچ‌کس با فکر جدایی قرارداد امضا نمی‌کند، اما بند فسخ دقیقاً برای روزی است که همکاری به هر دلیلی ادامه پیدا نمی‌کند. این موارد را روشن کنید:

  • موارد فسخ: در چه شرایطی هر طرف حق فسخ دارد؛ مثلاً تأخیر طولانی بدون دلیل موجه، عدم پرداخت قسط سررسیدشده یا عدم تحویل محتوا در مدت طولانی.
  • روش اعلام: فسخ به صورت کتبی و با چه مهلت اطلاع قبلی اعلام می‌شود.
  • تسویهٔ کار انجام‌شده: بر اساس مایلستون‌های تحویل‌شده، کارفرما هزینهٔ کدام بخش‌ها را می‌پردازد و طراح کدام مبالغ را باید بازگرداند.
  • تحویل در زمان فسخ: فایل‌ها، سورس‌کد و دسترسی‌های مربوط به بخش‌های پرداخت‌شده تحویل کارفرما شود.
  • حل اختلاف: پیش از مراجعه به مراجع قانونی، مذاکره یا داوری از طریق فرد یا نهاد مورد توافق چطور انجام می‌شود. سازوکار دقیق این بند را با وکیل خود تنظیم کنید.

پیش از امضا این کارها را انجام دهید

  • مشخصات کامل دو طرف، مبلغ به عدد و حروف و تاریخ‌ها را کنترل کنید.
  • هر وعدهٔ شفاهی مهمی که در جلسه‌ها داده شده، باید در متن قرارداد یا پیوست آن آمده باشد.
  • شرح کار، زمان‌بندی و فهرست تحویل‌دادنی‌ها را به‌عنوان پیوست امضاشده ضمیمه کنید. اگر بریف طراحی سایت نوشته‌اید، همان را پایهٔ شرح کار قرار دهید.
  • متن نهایی را پیش از امضا به وکیل یا مشاور حقوقی بسپارید؛ به‌ویژه بندهای مالکیت، فسخ و حل اختلاف.

سؤالات متداول

آیا برای یک سایت ساده هم قرارداد کتبی لازم است؟

بله. حتی در پروژهٔ کوچک، یک قرارداد کوتاه با شرح کار، مبلغ، زمان‌بندی، مالکیت دامنه و هاست و دورهٔ گارانتی از بیشتر سوءتفاهم‌ها جلوگیری می‌کند. قرارداد لازم نیست طولانی باشد؛ باید دقیق باشد.

پیش‌پرداخت طراحی سایت معمولاً چقدر است؟

عدد ثابت و قانونی برای آن وجود ندارد و به توافق دو طرف و اندازهٔ پروژه بستگی دارد. مهم‌تر از درصد پیش‌پرداخت این است که بقیهٔ مبلغ به مایلستون‌های مشخص و قابل‌دیدن گره خورده باشد و قسط آخر پس از تحویل کامل پرداخت شود.

اگر طراح دامنه را به نام خودش ثبت کرده باشد چه کنم؟

ابتدا به‌صورت کتبی انتقال دامنه به نام خودتان را درخواست کنید. روال انتقال به نوع دامنه و ثبت‌کننده بستگی دارد و باید آن را از مرجع ثبت همان دامنه (برای ‎.ir، سایت ایرنیک) پیگیری کنید. در قراردادهای بعدی، این بند را از ابتدا بنویسید.

آیا می‌توانم از نمونه‌قراردادهای آماده در اینترنت استفاده کنم؟

نمونه‌قراردادها برای شروع و فهرست کردن بندها مفیدند، اما معمولاً با جزئیات پروژهٔ شما هماهنگ نیستند. از آن‌ها به‌عنوان پیش‌نویس استفاده کنید، شرح کار و زمان‌بندی را اختصاصی بنویسید و نسخهٔ نهایی را به وکیل بسپارید.

پس از پایان دورهٔ گارانتی، رفع اشکال رایگان است؟

معمولاً نه، مگر اینکه قرارداد پشتیبانی جداگانه داشته باشید یا در قرارداد اصلی چیز دیگری توافق شده باشد. به همین دلیل بهتر است پیش از امضا، شرایط و هزینهٔ خدمات پس از تحویل را هم بپرسید.

قرارداد روشن، پروژه را از همان روز اول قابل‌پیش‌بینی می‌کند. اگر برای تعریف شرح کار، مراحل و تحویل‌دادنی‌های پروژهٔ خود کمک می‌خواهید، در جلسهٔ مشاورهٔ رایگان مای طرح می‌توانیم آن را با هم مرور کنیم؛ صفحهٔ خدمات طراحی سایت را ببینید یا مستقیم از ثبت سفارش اقدام کنید.

م
تیم مای طرح
تحریریه مای طرح

عضو تیم متخصص مای طرح با سال‌ها تجربه در حوزه دیجیتال مارکتینگ و طراحی وب.

مقاله قبلی
چک لیست سئو ۱۴۰۵؛ ممیزی گام‌به‌گام سایت با اولویت‌بندی
مقاله بعدی
تبلیغات گوگل ادز؛ راهنمای کامل از مزایده تا ردیابی تبدیل