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