مقایسهٔ نرم‌افزار آموزشگاه آنلاین برای تیم چندمدرسه
فاکسیمون، سپید و فرایاد را با یک سناریوی مشترک برای نقش مدرس، گزارش و خروج داده ارزیابی کنید.
مدیر آموزشگاه برای دو مدرس و یک پشتیبان دنبال سامانهٔ تازه است. هر فروشنده در جلسهٔ معرفی گزارش، دوره و مدیریت کاربر نشان می‌دهد. پرسش مدیر از جنس کار روزانه است. آیا مدرس عکاسی می‌تواند تمرین گروه خودش را ببیند و سفارش‌های گروه طراحی برایش بسته بماند؟ آیا مسئول آموزش می‌تواند بعد از پایان همکاری گزارشی بگیرد که در ابزار دیگری هم باز شود؟ برای مقایسه نرم افزار آموزشگاه آنلاین، همین پرسش‌ها را به چند آزمون تبدیل کنید و در همهٔ گزینه‌ها با دادهٔ یکسان پیش بروید.
در این مقاله سه گزینه را با یک امتیازنامه بررسی می‌کنیم. اطلاعات عمومی فاکسیمون، سپید و فرایاد کمک می‌کنند موضوع‌های مناسب دمو را پیدا کنیم. امتیاز نهایی را زمانی وارد کنید که کار را با حساب مورد نظر در پلن پیشنهادی انجام داده باشید. اگر هنوز نمی‌دانید اولویت شما مدیریت یادگیری، کلاس زنده یا ادارهٔ ثبت‌نام است، راهنمای تفاوت سامانهٔ مدیریت یادگیری، کلاس مجازی و نرم‌افزار آموزشگاه به تفکیک این نیازها کمک می‌کند.
پیش از دیدن دمو، نیاز را به نتیجه تبدیل کنید
سه همکار را دور یک جدول جمع کنید. از مدرس بخواهید یک کار پرتکرار را نام ببرد. از پشتیبان بخواهید یک پروندهٔ دشوار را تعریف کند. از مسئول مالی یا مدیر بخواهید بگوید در پایان ماه دقیقاً چه عددی لازم دارد. مثال مدرس می‌تواند «دیدن و تصحیح تمرین گروه شنبه» باشد. مثال پشتیبان «پیدا کردن علت بسته بودن دسترسی یک خریدار» است. مثال مدیر «شمار ثبت‌نام‌های دارای دسترسی معتبر در دورهٔ طراحی در پایان هفته» است.
هر نیاز را با نتیجهٔ قابل مشاهده بنویسید. اگر گفتید گزارش خوب می‌خواهیم، فروشنده ممکن است نموداری نشان دهد که عدد درخواستی شما در آن نیست. دقیق‌تر بگویید مدیر باید بتواند از فهرست ده هنرجوی فرضی تشخیص دهد هشت نفر مجوز فعال دارند و دو نفر دسترسی‌شان پایان یافته است. اگر دورهٔ دیگری هم در پنل هست، اعداد آن دوره نباید وارد گزارش شوند. حالا می‌توانید برای سه سامانه یک سؤال یکسان بپرسید.
شرط‌های ضروری را از ترجیح‌ها جدا کنید. اگر دو مدرس با اطلاعات هنرجویان متفاوت کار می‌کنند، بسته ماندن تمرین گروه دیگر می‌تواند شرط خرید باشد. ظاهر داشبورد یا تعداد قالب گزارش شاید ترجیح تیم باشد. اگر شرط ضروری درست کار نمی‌کند، امتیاز زیاد در موارد ترجیحی مشکل را حل نمی‌کند. برای هر شرط بنویسید چه کسی آن را تعیین کرده، در کدام کار استفاده می‌شود و هنگام نبودنش تیم چه گزینهٔ عملی دارد. برای فهرست کردن کارهای مرتبط، راهنمای عملیات آموزشگاه آنلاین را مرور کنید.
پیش از جلسه، نام پلن، نوع استقرار و محیط آزمایش را ثبت کنید. ممکن است دمو روی پلنی کامل‌تر از پیشنهاد خرید باشد. برای هر قابلیتی که در جلسه می‌بینید، بپرسید آیا همین رفتار در پلن مورد نظر و با نقش‌هایی که شما دارید در دسترس است. اگر برای اجرای یک مرحله به حساب داخلی فروشنده نیاز است، آن را در همان ردیف یادداشت کنید. نتیجهٔ حساب مدیر فروشنده را برای حساب مدرس مشتری به کار نبرید.
از صفحه‌های رسمی برای ساخت سؤال استفاده کنید
در معرفی عمومی فاکسیمون، دورهٔ ویدیویی، کلاس آنلاین و مدیریت دسترسی دیده می‌شود. صفحهٔ دسترسی هنرجو دربارهٔ تعیین بازهٔ مجوز و مدیریت آن توضیح می‌دهد. برای جلسهٔ خرید، همین قابلیت را با یک هنرجوی فعال و یک هنرجوی منقضی امتحان کنید. سپس یک پرسش جدا بپرسید. آیا پشتیبان می‌تواند نتیجه را در محدودهٔ پرونده ببیند و مدرس فقط وضعیت گروه خودش را بررسی کند؟ پاسخ پرسش دوم را با دو حساب جدا ثبت کنید. مدیریت دسترسی هنرجویان در فاکسیمون
سپید در وب‌سایت رسمی خود ساخت آموزشگاه آنلاین و فروش دوره را معرفی می‌کند. اگر کار روزانهٔ شما از صفحهٔ دوره تا ثبت‌نام را در بر می‌گیرد، در دمو از ساخت یک دورهٔ نمونه شروع کنید و تا دیدن وضعیت سفارش و باز شدن درس پیش بروید. بعد همان سفارش را با نقش مدرس و پشتیبان بررسی کنید. اگر برای تسویه، گزارش یا دسترسی کاربران ویژگی خاصی می‌خواهید، یک ردیف با نتیجهٔ مورد انتظار بسازید. معرفی رسمی سپید
فرایاد در صفحهٔ سامانهٔ مدیریت یادگیری، تکلیف، آزمون و گزارش پیشرفت را معرفی می‌کند. اگر آموزشگاه روی ارزیابی هنرجو حساب می‌کند، یک تکلیف ساده بسازید و نتیجه را در حساب مدرس، حساب هنرجو و گزارش مدیر ببینید. سپس بخواهید نمونهٔ خروجی همان گزارش را به شما بدهند. نمایش گزارش در پنل با توانایی بازکردن و استفاده از فایل در مقصد دو نتیجهٔ جداست. معرفی رسمی سامانهٔ مدیریت یادگیری فرایاد
| گزینه | نقطهٔ شروع بر اساس معرفی رسمی | در پایلوت چه چیزی باید روشن شود؟ |
|---|---|---|
| فاکسیمون | ارائهٔ آموزش و مدیریت دسترسی هنرجو | حدود نقش مدرس و پشتیبان، گزارش مورد نیاز و دادهٔ قابل دریافت |
| سپید | ساخت آموزشگاه و مسیر فروش دوره | وضعیت سفارش پس از پرداخت و حدود نقش تیم روی همان پرونده |
| فرایاد | مدیریت یادگیری، تکلیف و گزارش پیشرفت | جداسازی مدرس‌های دو گروه و جزئیات فایل خروجی همان گزارش |
این جدول جمع‌بندی نتیجهٔ خرید نیست. ستون دوم از معرفی عمومی آمده و ستون سوم سؤال آزمون است. برای هر سه گزینه همان سه آزمون نقش، گزارش و خروج داده را اجرا کنید، حتی اگر تبلیغ محصول روی یکی از آن‌ها بیشتر تأکید دارد. اگر یک صفحهٔ رسمی دربارهٔ رفتار مورد نیاز سکوت می‌کند، وضعیت ردیف را «نامشخص» بگذارید. اگر فروشنده می‌گوید آن رفتار در پلن دیگری ممکن است، نام پلن و تفاوت هزینه یا فرایند را کنار همان ردیف ثبت کنید.
دادهٔ مشترک را یک بار آماده کنید
دو دورهٔ فرضی با نام «طراحی مقدماتی» و «عکاسی مقدماتی» بسازید. برای هر دوره یک مدرس و یک تمرین بسازید. چند هنرجوی آزمایشی اضافه کنید. یک نفر دسترسی فعال دارد، نفر دوم پایان دسترسی را رد کرده و نفر سوم به هر دو دوره دسترسی دارد. یک سفارش فرضی لغوشده و یک ثبت‌نام دستی هم در نمونه بگذارید. تاریخ‌ها را قبل از شروع روی برگه بنویسید تا موقع مقایسه معلوم باشد کدام ردیف باید فعال دیده شود.
تا حد امکان دادهٔ شخصی واقعی وارد دمو نکنید. اسم ساختگی و شناسه‌ای ساده کافی است. اگر یک محیط به ایمیل واقعی برای تأیید نیاز دارد، از حساب‌هایی استفاده کنید که برای همین آزمایش ساخته شده‌اند. یک جدول مرجع برای حساب‌ها بسازید و در آن بنویسید هر نفر به کدام دوره مربوط است. رمز و کد ورود را در جدول شواهد ننویسید. کافی است ردیف آزمون به نام حساب آزمایشی اشاره کند.
برای هر سامانه از روز و ساعت مرجع یکسان استفاده کنید. مثلاً تاریخ پایان را نسبت به روز پایلوت تعیین کنید و هنگام آزمون تاریخ و منطقهٔ زمانی دیده‌شده را بنویسید. اگر محیط دوم را یک هفته بعد بررسی می‌کنید، وضعیت فعال و منقضی را با فاصلهٔ مشابه بازسازی کنید. در غیر این صورت ممکن است اختلاف دو گزارش به گذشت زمان مربوط باشد. از عدد کل مرجع شروع کنید و بعد سراغ تک‌تک شناسه‌ها بروید.
مسئول هر مرحله را از قبل معلوم کنید. یک نفر تنظیم اولیه را انجام دهد، دو مدرس نمونه با حساب خود وارد شوند و فردی دیگر گزارش را از روی فایل بخواند. اگر همهٔ کارها را مدیر انجام دهد، کاربر عادی و مسیر واقعی او دیده نمی‌شوند. در زمان یادگیری پنل، یک بار اجازه دهید فروشنده مسیر را نشان دهد. بار دوم همان کار را خودتان تکرار کنید و زمان تقریبی و نقطه‌های توقف را ثبت کنید.
نقش‌ها را با دو حساب مدرس امتحان کنید
با حساب مدرس طراحی وارد شوید و تمرین طراحی را باز کنید. یک پاسخ نمونه بنویسید و ببینید هنرجوی همان دوره آن را می‌بیند. سپس به دنبال تمرین عکاسی بگردید. اگر تمرین در فهرست نیست، نشانی مستقیم صفحهٔ آزمایشی را هم با همان حساب باز کنید. نتیجه را با یک جمله ثبت کنید. «در فهرست دیده نشد و نشانی مستقیم پیام محدودیت داد» از «سطح دسترسی دارد» دقیق‌تر است.
آزمون را برای پشتیبان هم انجام دهید. او باید بتواند دربارهٔ پروندهٔ هنرجوی آزمایشی توضیح دهد که مجوز فعال، منقضی یا در انتظار بررسی است. سپس بررسی کنید آیا همان حساب می‌تواند کار حساسی مثل تغییر قیمت یا گرفتن خروجی کامل هنرجویان انجام دهد. اگر سیاست آموزشگاه به او این اجازه را نمی‌دهد و عمل ممکن است، نتیجهٔ این ردیف با انتظار شما تفاوت دارد. برای فروشنده روشن کنید مشکل به کدام عمل و کدام نقش مربوط است.
یک مدرس مهمان را برای یک تمرین اضافه کنید و بعد نقش او را بردارید. صفحهٔ تازه و صفحه‌ای را که از قبل باز بوده جدا امتحان کنید. ممکن است دادهٔ پیش‌تر بارگذاری‌شده روی صفحه بماند. ببینید آیا حساب می‌تواند اطلاعات تازه بگیرد یا تغییر دیگری ذخیره کند. اگر پایان همکاری در تیم پرتکرار است، همین ردیف ممکن است برای انتخاب اهمیت بیشتری از ظاهر پنل داشته باشد.
به نام نقش اکتفا نکنید. عنوان «مدیر دوره» در دو محصول می‌تواند دامنهٔ متفاوتی داشته باشد. کار، حساب، دوره و نتیجه را ثبت کنید. اگر برای جدا کردن دو مدرس مجبورید دو فضای کاملاً مستقل بسازید، اثر این روش بر گزارش یکپارچه، قیمت و نگهداری را هم بسنجید. شاید برای دو گروه کوچک قابل اجرا باشد و برای بیست دوره بار زیادی ایجاد کند.
گزارش را با یک پروندهٔ واقعی‌نما تطبیق دهید
برای آزمایش گزارش، سؤال مشخصی بنویسید. مثلاً مدیر می‌خواهد بداند در پایان هفته چند نفر می‌توانند درس طراحی را باز کنند. فهرست مرجع مجوزها را کنار پنل باز کنید و تعداد فعال‌ها را از روی آن حساب کنید. سپس همان فیلتر را در گزارش بزنید و اختلاف را بررسی کنید. آیا گزارش نفر را می‌شمارد یا سفارش را؟ هنرجویی که دو سفارش برای یک دوره دارد ممکن است دو ردیف سفارش داشته باشد ولی فقط یک بار در شمار افراد بیاید.
تاریخ ایجاد سفارش و تاریخ فعال‌شدن دسترسی را جدا ببینید. اگر سفارش جمعه ثبت شده و دسترسی شنبه شروع می‌شود، گزارش فروش جمعه و گزارش دسترسی شنبه می‌توانند عددهای متفاوت داشته باشند. این اختلاف زمانی اشکال محسوب می‌شود که گزارش طبق تعریف خودش نتیجهٔ نادرست بدهد. اگر تعریف ستون یا بازه روشن نیست، یک سفارش مرزی بسازید و نتیجه را با فروشنده مرور کنید.
برای گزارش آموزشی، دو هنرجو را در وضعیت متفاوت بگذارید. نفر اول درس را باز کند و تمرین را تحویل دهد. نفر دوم فقط درس را باز کند. اگر گزارش هر دو را در یک وضعیت نشان می‌دهد، مشخص کنید منظور ستون چیست. ممکن است ستون بازدید باشد و برای تشخیص تحویل تمرین باید گزارش دیگری بگیرید. بررسی کنید آیا مدرس همان دادهٔ لازم را برای گروه خودش می‌بیند و مدیر می‌تواند جمع دو گروه را به‌درستی به دست آورد.
یک بار گزارش را به همکار دیگری بدهید و فقط سؤال کاری را مطرح کنید. اگر برای خواندن عدد باید کسی فیلترهای استفاده‌شده را از حافظه توضیح دهد، تنظیم‌ها را کنار فایل ثبت کنید. اگر عنوان ستون یا واحد شمارش برای نفر دوم مبهم است، از فروشنده نمونهٔ توضیح گزارش بخواهید. گزارش قابل استفاده باید برای مسئول بعدی هم قابل خواندن باشد.
خروج داده را در ابزار مقصد باز کنید
از هر گزینه یک نمونهٔ خروجی سفارش، دسترسی یا پیشرفت بگیرید. نام فایل، زمان دریافت، حساب صادرکننده و فیلترهای استفاده‌شده را ثبت کنید. سپس فایل را با ابزار معمول آموزشگاه باز کنید. در همان قدم اول ببینید متن فارسی، تاریخ‌ها و شناسه‌ها درست خوانده می‌شوند. اگر فایل در پنل نمایش داده می‌شود ولی تیم نمی‌تواند آن را دریافت کند، وضعیت دسترسی به گزارش و وضعیت خروجی را جدا بنویسید.
دو فایل را با شناسهٔ ثابت کنار هم بگذارید. مثلاً سفارش نمونه را پیدا کنید و بررسی کنید ردیف مجوز به همان سفارش اشاره می‌کند یا باید از مسیر دیگری منشأ آن را پیدا کنید. اگر اتصال فقط از روی نام هنرجو ممکن است، دو نام مشابه بسازید و ببینید خطر اشتباه چقدر است. آزمون کوچک باید همان مشکلی را آشکار کند که هنگام انتقال صدها ردیف می‌تواند رخ دهد.
یک پرونده را در مقصد آزمایشی بازسازی کنید. اگر هدف انتقال تاریخ دسترسی است، تاریخ آغاز و پایان را از خروجی بخوانید و یک ردیف نمونه وارد کنید. بعد با حساب هنرجو بررسی کنید درس در بازهٔ درست باز می‌شود. اگر هدف گزارش مالی است، عددها را با واحد درست در کاربرگ مقصد جمع کنید و نمونهٔ لغو یا برگشت را جدا ببینید. باز شدن فایل فقط مرحلهٔ اول است. به نتیجه‌ای برسید که تیم واقعاً پس از خروج نیاز دارد.
برای چند فایل حجیم دربارهٔ حدود خروج بپرسید. آیا هر دوره جدا صادر می‌شود؟ آیا می‌توان بازهٔ طولانی گرفت؟ آیا فایل فهرست تمام ردیف‌ها را دارد یا فقط صفحهٔ فعلی را؟ اگر قرار است فروشنده هنگام پایان قرارداد فایل بدهد، نوع فایل، زمان تحویل و دامنهٔ داده را در پیشنهاد ثبت کنید. برای امتیاز بالا، نمونهٔ قابل بررسی بخواهید تا شرط در حد پاسخ شفاهی نماند.
نتیجه را در یک امتیازنامهٔ قابل دفاع وارد کنید
برای هر ردیف از سه امتیاز استفاده کنید. صفر یعنی آزمون انجام شد و نتیجه با انتظار نخواند. یک یعنی کار با مسیر اضافه یا محدودیت شناخته‌شده انجام شد. دو یعنی تیم نتیجهٔ مورد انتظار را در پلن و حساب مورد نظر دید. موردی که آزمون نشده «نامشخص» می‌ماند. آن را صفر فرض نکنید، چون صفر نتیجهٔ مشاهده‌شده است. اگر همان ردیف شرط ضروری است، تصمیم نهایی را تا روشن شدن وضعیت باز نگه دارید.
| معیار نمونه | وزن | شاهد لازم | شرط ضروری نمونه |
|---|---|---|---|
| تفکیک مدرس‌های دو دوره | ۵ | آزمون حساب خود و نشانی مستقیم دورهٔ دیگر | بله |
| گزارش ثبت‌نام و مجوز | ۳ | تطبیق تعداد و دو شناسهٔ نمونه با فهرست مرجع | خیر |
| دریافت و خواندن خروجی | ۴ | فایل نمونه، شناسهٔ ثابت و بررسی در ابزار مقصد | بله |
| زمان انجام کار روزانه | ۲ | تکرار یک کار توسط همکار پس از دمو | خیر |
امتیاز هر ردیف را در وزن آن ضرب کنید. در این جدول سقف امتیاز ۲۸ است. فرض کنید یک گزینهٔ آزمایشی برای چهار ردیف به‌ترتیب دو، یک، دو و یک گرفته است. حاصل ۱۰، ۳، ۸ و ۲ می‌شود و جمع آن ۲۳ است. این عدد فقط مثال محاسبه است. اگر خروجی هنوز آزمایش نشده، حاصل سه ردیف دیگر ۱۵ از سقف ۲۰ ردیف‌های آزموده است. وضعیت شرط خروج داده همچنان باز می‌ماند و گزارش باید هر دو عدد را همراه شرط باز نشان دهد.
هنگام مقایسهٔ دو گزینه، کنار امتیاز هزینهٔ کارهای اضافه را بیاورید. فرض کنید برای تهیهٔ گزارش ماهانه در یکی از گزینه‌ها باید دو فایل را هر بار دستی به هم وصل کنید. زمان همان کار را در تمرین اندازه بگیرید و تعداد دفعات را در ماه بنویسید. سپس اشتراک، خدمات راه‌اندازی و زمان تیم را در یک بازهٔ یکسان مقایسه کنید. هزینهٔ کار اضافه را با مبلغ اشتراک جمع کنید فقط اگر نرخ زمانی را بر همان مبنا تعریف کرده باشید.
مسیر پرداخت و تحویل دسترسی را جدا اندازه بگیرید
ابتدا بنویسید پرداخت در کدام سامانه انجام می‌شود. ممکن است فروش در سایت آموزشگاه انجام شود و سامانهٔ آموزشی پس از دریافت نتیجهٔ سفارش دسترسی هنرجو را باز کند. گزینهٔ دیگری ممکن است صفحهٔ فروش و سفارش را در همان محیط ارائه دهد. در هر دو حالت، معیار مشترک این است که هنرجوی آزمایشی بعد از خرید معتبر بتواند درس درست را باز کند و پشتیبان بتواند دلیل تأخیر را پیدا کند. در جدول خرید، نام ابزار پرداخت و مسئول هر مرحله را کنار نتیجه بیاورید.
سه وضعیت را با دادهٔ آزمایشی تمرین کنید. در حالت اول نتیجهٔ موفق پرداخت می‌رسد و یک مجوز برای دوره ساخته می‌شود. در حالت دوم سفارش ناقص است و دسترسی هنوز بسته می‌ماند. در حالت سوم نتیجهٔ موفق دوباره می‌رسد و وضعیت نهایی باید همان یک مجوز معتبر باشد. اگر اتصال بیرونی وجود دارد، زمان هر مرحله و نقطهٔ مشاهدهٔ نتیجه را ثبت کنید. اگر فروشنده برای ثبت سفارش آزمایشی مسیر امن ندارد، همان ردیف را باز بگذارید و با سفارش هنرجوی واقعی تمرین نکنید.
در مسیر دستی، پشتیبان نتیجهٔ پرداخت را می‌بیند و مجوز را ثبت می‌کند. این روش را با یک نفر دیگر تکرار کنید و ببینید آیا هر دو از روی شمارهٔ سفارش به همان حساب و همان دوره می‌رسند. اگر خطای انتخاب دوره در تمرین رخ می‌دهد، مشخص کنید چه کسی می‌تواند آن را اصلاح کند و چه اطلاعاتی برای پیگیری باقی می‌ماند. زمان اصلاح را هم به هزینهٔ کار روزانه اضافه کنید. ممکن است یک فرایند دستی برای ثبت‌نام محدود مناسب باشد و در روز فروش گروهی به ظرفیت بیشتری نیاز داشته باشد.
اثر تغییر پلن و تحویل کار را قبل از خرید بررسی کنید
برای راه‌اندازی فقط هزینهٔ اشتراک را ننویسید. تعداد ساعت آموزش مدرس‌ها، انتقال درس نمونه، ساخت گزارش و تمرین پشتیبانی را هم برآورد کنید. اگر یک گزینه برای هر دوره تنظیم جدا می‌خواهد، همین تنظیم را برای دو دوره انجام دهید و زمان واقعی را یادداشت کنید. سپس مشخص کنید کدام کار فقط بار اول لازم است و کدام کار در هر دوره تکرار می‌شود. هزینهٔ راه‌اندازی و زمان ماهانه را در دو ردیف جدا بگذارید تا هنگام مقایسه دوباره شمرده نشوند.
از فروشنده بخواهید مسیر تغییر پلن را با همان نمونه توضیح دهد. فرض کنید برای سه مدرس خرید می‌کنید و ترم بعد پنج مدرس دارید. بپرسید محدودیت مربوط به تعداد حساب است یا نقش فعال، و با اضافه‌شدن دو مدرس آیا گزارش‌های قبلی و تنظیم گروه‌ها باقی می‌مانند. اگر پلن پایین‌تر برای مدتی کافی است، وضعیت دسترسی داده و خروجی هنگام برگشت به آن پلن را هم مشخص کنید. نتیجه‌ای را که فقط از گفت‌وگو به دست آمده، در ستون پاسخ فروشنده بیاورید.
در آخر یک تحویل کار کوتاه انجام دهید. از کسی که در دمو حضور نداشته بخواهید با راهنمای تیم یک حساب مدرس بسازد، گزارش نمونه را پیدا کند و محل ذخیرهٔ خروجی را نشان دهد. وقتی مجبور می‌شود برای هر گام با فروشنده تماس بگیرد، همان وابستگی را در هزینهٔ نگهداری ثبت کنید. اگر راهنما کافی است، بپرسید چه کسی بعد از تغییر پنل آن را به‌روز می‌کند. این تمرین مشخص می‌کند سامانه پس از پایان پروژهٔ راه‌اندازی چگونه وارد برنامهٔ هفتگی آموزشگاه می‌شود.
جلسهٔ تصمیم را با شواهد و شرایط باز تمام کنید
برای هر گزینه سه چیز بیاورید. کارهایی که تیم با حساب خودش انجام داده، مواردی که فقط در دمو دیده و شرط‌هایی که هنوز بازند. اگر یک فروشنده قابلیت آینده‌ای را مطرح می‌کند، آن را جدا از قابلیت فعلی ثبت کنید و با همان اطلاعات برای دورهٔ بعد برنامه بریزید. در جدول، اسم فردی که نتیجه را دیده و تاریخ آزمون را نگه دارید تا هنگام تغییر پلن یا تکرار دمو بدانید از کجا شروع کنید.
در پایان، یک همکار که در همهٔ جلسه‌ها نبوده باید بتواند از روی برگه تصمیم را بفهمد. او باید ببیند چرا کنترل نقش مدرس مهم بوده، گزارش با کدام داده تطبیق داده شده و آیا فایل خروجی در مقصد باز شده است. اگر انتخاب هنوز به یک نمونه بستگی دارد، نام نمونه و معیار قبولش را بنویسید. این روش کمک می‌کند تیم به جای تکیه بر تعداد امکانات، سامانه را بر اساس کارهایی انتخاب کند که هر هفته انجام می‌دهد.