دموی زیبا کار خودش را می‌کند: اتاق جلسه ساکت می‌شود، انگشت‌ها روی صفحه‌نمایش می‌لغزند، و کسی می‌گوید «همین را می‌خواهیم.» مشکل از آن لحظه شروع نمی‌شود. مشکل وقتی شروع می‌شود که قرارداد امضا شده، پیش‌پرداخت رفته، و نسخهٔ واقعی — با دادهٔ کثیف، نقش‌های مبهم، و استثناءهای نانوشته — جای آن اسلاید روان را می‌گیرد. آن‌وقت است که می‌فهمید چیزی که خریده‌اید «محصول» نبوده؛ یک روایت پالیش‌شده از محصول بوده است.
این یادداشت برای دو تصویر آشناست: امیرحسین، مالک کسب‌وکار متوسط که بعد از یک دموی درخشان نرم‌افزار سفارش می‌دهد و سه ماه بعد هنوز منتظر همان جریان ساده‌ای است که در جلسه دید؛ و سارا/رضا، مدیران مقیاس‌پذیر که تیم فروش‌شان با دموی براق قرارداد می‌بندد، ولی عملیات هر هفته با شکاف بین «آنچه نشان داده شد» و «آنچه واقعاً تحویل می‌شود» می‌جنگد. گرین‌لبز استودیوی تحویل محصول دیجیتال، اتوماسیون و هوش مصنوعی است؛ نه فروشگاه اسلاید و نه پیمانکار ویترین. هدف این متن قانع‌کردن با ترس نیست. هدف این است که بفهمید دمو کجا ابزار کشف است، و کجا ابزار فریب ناخواسته — و چطور قبل از امضا، مرز واقعیت را بکشید.
دمو دقیقاً چه چیزی را نشان می‌دهد؛ و چه چیزی را پنهان می‌کند
دمو، در بهترین حالت، یک برش کنترل‌شده از تجربه است: دادهٔ تمیز، مسیر خوش‌بینانه، کاربر ایده‌آل، و اینترنتی که قطع نمی‌شود. در بدترین حالت، دمو یک تئاتر است — کلیک‌هایی ازپیش‌تمرین‌شده روی ماک یا روی محیطی که با محیط تولید شما هیچ نسبتی ندارد.
سه لایه معمولاً در دمو دیده نمی‌شوند و بعد از قرارداد ظاهر می‌شوند:
داده. در دمو همهٔ فیلدها پرند، هیچ رکورد تکراری نیست، و گزارش‌ها یک‌کلیکه‌اند. در واقعیت، داده بین اکسل، واتساپ و سه سامانهٔ قدیمی پخش است. مهاجرت، پاک‌سازی و تعریف «منبع حقیقت» بخش بزرگی از کار است — و در دمو جایی ندارد.
استثناءها. دمو مسیر اصلی را نشان می‌دهد. کسب‌وکار ایرانی پر از استثناء است: مشتری ویژه، انبار دوم، کمیسیون متفاوت، روز تعطیل، و توافق شفاهی مدیر فروش. هر استثناء منطق، آزمایش و نگهداری می‌آورد. دمویی که فقط مسیر شاد را نشان دهد، نصف محصول را پنهان کرده است.
مالکیت و عملیات. دمو معمولاً یک نفر را پشت سیستم می‌نشاند که همه‌چیز را بلد است. بعد از تحویل، نقش‌ها، دسترسی‌ها، آموزش، و کسی که بک‌لاگ را اولویت می‌دهد تعیین می‌کنند سیستم زنده می‌ماند یا یتیم می‌شود. موضوعی که در پروژه‌ات تمام شده؛ پس چرا هنوز کسی جوابگو نیست؟ باز شده، دقیقاً همین شکاف مالکیت است — فقط این بار از درِ دمو وارد می‌شود.
پس پرسش درست بعد از دمو این نیست که «زیبا بود یا نبود؟» پرسش این است: کدام بخش از آنچه دیدم محصول آماده است، کدام بخش ماک، کدام بخش وعدهٔ فاز بعد، و کدام بخش فقط برای جلسه ساخته شده؟
دو تصویر؛ امیرحسین و سارا/رضا
امیرحسین؛ دموی براق، قرارداد عجله‌ای
امیرحسین حدود بیست تا چهل نفر نیرو دارد. فروشندهٔ نرم‌افزار در چهل دقیقه پنل سفارش، موجودی و گزارش هفتگی را نشان می‌دهد. همه‌چیز روان است. امیرحسین خسته از اکسل و واتساپ است؛ قرارداد را همان هفته می‌بندد.
سه ماه بعد: ورود دادهٔ قدیمی نیمه‌کاره است، گزارش هفتگی با تعریف مالی شرکت جور درنمی‌آید، و فروشنده‌ها هنوز سفارش را در چت ثبت می‌کنند چون مسیر واقعی‌شان در دمو نبود. آنچه در جلسه «آماده» به‌نظر می‌رسید، در عمل یک اسکلت به‌علاوهٔ چند صفحهٔ خوش‌رنگ بوده است.
برای امیرحسین نقطهٔ عطف عاقلانه این است: قبل از امضا، یک جریان باریک واقعی را روی دادهٔ خودش — حتی ناقص — ببیند؛ معیار نودروزه بنویسد؛ و بپرسد اگر استثناء X پیش آمد، سیستم چه می‌کند. دموی عمومی روی دیتای دمو، برای تصمیم خرید کافی نیست. اگر پیمانکار از نشان‌دادن مسیر واقعی طفره رفت، احتمال زیاد دارید ویترین بخرید نه محصول. منطق انتخاب بین ساخت و خرید را در نرم‌افزار سفارشی برای کسب‌وکار ایرانی دیده‌اید؛ اینجا همان منطق روی دروازهٔ فروش اعمال می‌شود.
سارا و رضا؛ دمو برای بستن، واقعیت برای سوختن
سارا تجربه و محصول را جلو می‌برد؛ رضا عملیات و داده را. تیم فروش شریک جدید با دموی خیره‌کننده قرارداد سازمانی می‌بندد. اسلایدها وعدهٔ یکپارچگی CRM، پورتال مشتری و داشبورد واحد می‌دهند. سارا در جلسهٔ فنی می‌پرسد APIها کجایند و مهاجرت داده چه‌قدر طول می‌کشد؛ جواب‌ها مبهم‌اند ولی فشار «فرصت از دست می‌رود» امضا را جلو می‌اندازد.
نود روز بعد: پورتال هست، اما نصف فیلدها دستی پر می‌شوند؛ داشبورد زیباست، اما منبع داده شبانه و ناقص است؛ و تیم عملیات دو سیستم موازی نگه می‌دارد چون به نسخهٔ جدید اعتماد ندارد. بودجهٔ «فاز یک» تمام شده و «فاز دو» — جایی که یکپارچگی واقعی قرار بود بیاید — در صف انتظار است.
برای سارا و رضا، دمو باید سند کشف باشد نه ابزار بستن معامله. هر ادعای یکپارچگی باید به قرارداد فنی وصل شود: سیستم مبدأ، روش همگام‌سازی، فرکانس، مسئولیت خطا، و معیار پذیرش. اگر دمو فقط UI نشان می‌دهد و معماری را پشت شعار «ما وصل می‌کنیم» می‌گذارد، شما در حال خرید امید هستید نه محصول. و اگر هم‌زمان چند پیمانکار جدا برای وب، داده و پشتیبانی دارید، هزینهٔ هماهنگی را هم حساب کنید؛ موضوعی که در چند ایجنسی، یک دردسر باز شده است.
نشانه‌هایی که دمو دارد جای محصول را می‌گیرد
مسیر فقط روی دادهٔ دمو کار می‌کند. وقتی می‌پرسید «همین را روی خروجی اکسل ما نشان بدهید» و جواب «بعد از قرارداد» است، دارید ماک پیشرفته می‌خرید.
فاز دو همان جایی است که ارزش واقعی قرار دارد. اگر ارزش اصلی — اتصال حسابداری، نقش‌های پیچیده، یا گزارش تصمیم‌ساز — به فاز بعد پرتاب شده، دمو فقط قلاب فروش است. فاز دو در بسیاری از پروژه‌های ایرانی یا دیر می‌آید یا هیچ‌وقت شروع نمی‌شود.
استثناءها «بعداً تنظیم می‌شود». کسب‌وکار بدون استثناء وجود ندارد. پیمانکاری که استثناء را جزئی می‌داند، یا دامنه را نشناخته یا عمداً کم‌برآورد می‌کند.
هیچ معیار پذیرشی روی میز نیست. «مشابه دمو تحویل می‌دهیم» معیار نیست. معیار یعنی: زمان ثبت سفارش، درصد خطای موجودی، یا تعداد کلیک تا گزارش هفتگی — روی نقش واقعی و دادهٔ واقعی.
مالک داخلی نامشخص است. اگر بعد از تحویل کسی مسئول پذیرش، آموزش و اولویت بک‌لاگ نباشد، حتی محصول درست هم یتیم می‌شود. دمو این خلأ را نشان نمی‌دهد؛ سازمان شما باید قبل از امضا پرش کند.
طراحی فقط پوسته‌ای است. رابط زیبا بدون نقشهٔ نقش‌ها، وضعیت‌ها و خطاها، همان چیزی است که در خدمات طراحی باید از روز اول از ویترین جدا شود: تجربه برای کار واقعی، نه برای اسکرین‌شات لینکدین.
دموی سالم چه شکلی است
دموی سالم دروغ نمی‌گوید؛ مرز می‌کشد.
برچسب صریح روی هر بخش. این صفحه آمادهٔ تولید است؛ این ماک؛ این در بک‌لاگ فاز یک؛ این وابسته به یکپارچه‌سازی شماست. شفافیت، فروش را ضعیف نمی‌کند؛ اعتماد را می‌سازد.
یک جریان واقعی با دادهٔ نزدیک به واقعیت. حتی اگر ناقص باشد. دیدن اصطکاک واقعی بهتر از دیدن روان‌بودن ساختگی است. اگر مهاجرت داده سخت است، همان سختی را زود نشان دهید.
معیار پذیرش پیش از امضا. سه تا پنج شاخص قابل اندازه‌گیری برای نود روز اول. بدون این‌ها، اختلاف بعد از تحویل به سلیقه تبدیل می‌شود.
نقشهٔ یکپارچگی روی میز. نه شعار. فهرست سیستم‌ها، API یا فایل، جهت داده، و مسئول خطا. اگر نرم‌افزار و وب سفارشی می‌خرید، این نقشه بخشی از کشف است نه هدیهٔ بعد از واریز.
مالک و مسیر نگهداری. چه کسی داخل سازمان شما محصول را زنده نگه می‌دارد؟ چه قراردادی برای تغییر و پشتیبانی هست؟ دموی بدون پاسخ به نگهداری، فقط روز اول را می‌فروشد.
همین روح در راهنمای محتوای مفید و مردم‌محور گوگل برای وب دیده می‌شود: ارزش برای کاربر واقعی، نه نمایش برای جلسه. محصولی که فقط برای دمو پالیش شده، دقیقاً ضد آن اصل است. در طراحی تجربه هم پژوهش‌های Nielsen Norman Group دربارهٔ آزمایش با کاربران واقعی یادآوری می‌کند که اصطکاک واقعی فقط با داده و نقش واقعی آشکار می‌شود — نه با کلیک روی مسیر ازپیش‌تعیین‌شده.
کی دمو را جدی بگیرید؛ و کی عقب بکشید
جدی بگیرید وقتی: دامنه باریک است، دادهٔ نمونه نزدیک به واقعیت است، معیار نودروزه نوشته شده، و پیمانکار خودش محدودیت‌ها را بلند می‌گوید. آن دمو ابزار هم‌ترازی است.
عقب بکشید وقتی: فشار «امروز امضا کنید»، وعده‌های فاز‌دویی که ارزش اصلی‌اند، یا امتناع از نشان‌دادن مسیر روی دادهٔ شما، فضای جلسه را پر کرده. آن دمو ابزار بستن است نه کشف.
برای امیرحسین، یک هفته تأخیر در امضا و یک جلسهٔ فنی روی دادهٔ خودش، اغلب ارزان‌تر از سه ماه دوباره‌کاری است. برای سارا و رضا، بندهای پذیرش و نقشهٔ یکپارچگی در قرارداد، ارزان‌تر از نگه‌داشتن دو سیستم موازی تا پایان سال است.
اگر لایهٔ هوشمند یا چت در دمو برق می‌زند ولی داده و فرایند لرزان است، همان هشدار چت‌بات سفارشی اینجاست: ویترین هوشمند روی اسکلت سست، فقط هزینه را جلو می‌اندازد.
هزینهٔ پنهان شکاف دمو و واقعیت
شکاف دمو و محصول فقط یک نارضایتی احساسی نیست؛ بودجه را جابه‌جا می‌کند — اغلب بدون اینکه در پیشنهاد اولیه دیده شود.
دوباره‌کاری روی داده. وقتی مهاجرت و پاک‌سازی در دمو نبوده، فاز اول عملاً دو بار ساخته می‌شود: یک‌بار روی دادهٔ تمیز فرضی، یک‌بار روی واقعیت. تیم شما هم‌زمان باید سیستم قدیم را زنده نگه دارد؛ یعنی هزینهٔ موازی، نه جایگزین.
آموزش روی مسیری که عوض می‌شود. اگر رابط دمو با نسخهٔ تحویل‌شده فرق کند، آموزش اول سوخته است. نیروی فروش یا عملیات که یک‌بار مسیر اشتباه یاد گرفته، دیرتر به سیستم جدید اعتماد می‌کند و به اکسل برمی‌گردد.
اعتبار داخلی خریدار. مدیری که با دموی زیبا هیئت‌مدیره را قانع کرده، وقتی واقعیت لنگ می‌زند، بودجهٔ فازهای بعدی را سخت‌تر می‌گیرد. شکاف دمو، سرمایهٔ سیاسی داخل سازمان را هم می‌سوزاند — چیزی که در اسلاید قیمت نیست.
قفل شدن به پیمانکار غلط. هرچه بیشتر روی اسکلت ناقص ساخته باشید، تعویض شریک گران‌تر می‌شود. دموی فریبنده گاهی همان قلاب قفل‌شدن است: بعد از امضا می‌فهمید خروج دشوارتر از ماندن است.
عدد ثابت برای «هزینهٔ شکاف دمو» وجود ندارد؛ و کسانی که یک رقم جادویی می‌فروشند معمولاً دامنه را پنهان می‌کنند. آنچه باید بپرسید این است: اگر مسیر واقعی روی دادهٔ ما دو برابر دمو طول بکشد، کدام بند قرارداد جلو شما را می‌گیرد — و کدام بند فقط حس خوب جلسه را حفظ می‌کند؟ همان منطقی که در بحث هزینه سئو در ایران برای پیشنهاد ارزان دیده می‌شود، اینجا هم صادق است: ارزان‌ترین دمو، گاهی گران‌ترین تعهد است.
جمع‌بندی عملی قبل از امضا
۱. از پیمانکار بخواهید سه برچسب بزند: آماده، ماک، فاز بعد.
۲. یک جریان باریک را روی دادهٔ نزدیک به واقعیت ببینید — نه فقط دیتای دمو.
۳. سه معیار پذیرش نودروزه بنویسید و در قرارداد بیاورید.
۴. نقشهٔ یکپارچگی و مسئول خطا را مکتوب کنید.
۵. مالک داخلی محصول را قبل از واریز مشخص کنید.
۶. هر ارزشی که به «فاز دو» پرتاب شده را با دیدهٔ شک نگاه کنید.
دموی زیبا مشتری را قانع می‌کند؛ محصول واقعی را عملیات، داده و مالکیت می‌سازند. اگر بعد از جلسه فقط حس خوب دارید و سند هم‌ترازی ندارید، هنوز خرید نکرده‌اید — فقط متقاعد شده‌اید. متقاعدشدن شروع ماجراست؛ تحویل، تمام‌کردن آن است.
گرین‌لبز وقتی وارد پروژه می‌شود، از کشف جریان و معیار شروع می‌کند نه از اسلاید براق. اگر برای ساخت و تحویل محصول دیجیتال به‌جای ویترین به شریک تحویل‌محور نیاز دارید، همان‌جا گفت‌وگو را از مرز واقعیت آغاز کنید — قبل از اینکه دمو جای محصول را بگیرد.
