چگونه تصمیم‌ها و اقدامات بعدی جلسه را با هوش مصنوعی استخراج کنیم؟

جلسه زمانی ارزش عملی پیدا می‌کند که نتیجه آن روشن باشد. شرکت‌کنندگان باید بدانند:

• چه تصمیمی گرفته شد؛
• چه کاری باید انجام شود؛
• مسئول هر کار چه کسی است؛
• موعد انجام آن چه زمانی است؛
• کدام موضوع هنوز نیازمند تأیید است؛
• و در جلسه بعد چه چیزی باید پیگیری شود.

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

هوش مصنوعی می‌تواند رونوشت جلسه را بررسی و مواردی مانند این‌ها را پیشنهاد کند:

• تصمیم‌های نهایی
• اقدامات بعدی
• مسئول هر اقدام
• موعد
• وضعیت
• وابستگی‌ها
• موانع
• موارد باز
• پرسش‌های نیازمند پاسخ
• موضوع جلسه بعد
• Timestamp منبع

این کار یکی از کاربردهای تحلیل محتوای صوت و ویدئو است؛ یعنی تبدیل رسانه خام به داده‌ای قابل جست‌وجو، بررسی و پیگیری.

اما این خروجی نباید بدون بازبینی به‌عنوان سند رسمی یا وظیفه قطعی ثبت شود. مدل ممکن است:

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

فرایند مناسب معمولاً چنین است:

فایل جلسه ↓ تبدیل گفتار به متن ↓ تفکیک گویندگان ↓ اصلاح نام‌ها، عددها و زمان‌ها ↓ بخش‌بندی بر اساس موضوع ↓ تشخیص پیشنهادها و تصمیم‌ها ↓ استخراج اقدامات ↓ تعیین مسئول و موعد ↓ اتصال به Timestamp ↓ بازبینی انسانی ↓ انتقال به سیستم پیگیری

جلسه را به متن قابل بررسی تبدیل کنید

فایل صوتی یا ویدئویی جلسه را در سابچین بارگذاری کنید و رونوشت فارسی زمان‌بندی‌شده دریافت کنید.

شروع تبدیل جلسه به متن

تفاوت تصمیم و اقدام بعدی چیست؟

این دو مفهوم به هم مرتبط‌اند، اما یکسان نیستند.

تصمیم

تصمیم نتیجه نهایی درباره یک موضوع است.

نمونه:

تصمیم: انتشار عمومی نسخه جدید در پانزدهم تیر انجام شود.

تصمیم لزوماً به‌تنهایی یک وظیفه اجرایی کامل نیست.

اقدام بعدی

اقدام بعدی کاری است که باید برای اجرای تصمیم یا پیشبرد موضوع انجام شود.

اقدام: تکمیل تست پرداخت پیش از انتشار

مسئول: تیم فنی

موعد: دوازدهم تیر

یک تصمیم ممکن است چند اقدام ایجاد کند:

تصمیم: انتشار در پانزدهم تیر انجام شود.

اقدامات:

• تکمیل تست فنی
• تأیید بودجه کمپین
• آماده‌سازی محتوای انتشار
• ارسال اطلاعیه به مشتریان

همچنین ممکن است اقدامی وجود داشته باشد که هنوز به یک تصمیم نهایی منجر نشده است:

اقدام: بررسی سه گزینه تأمین‌کننده و ارائه پیشنهاد در جلسه بعد

تفاوت تصمیم، پیشنهاد، نظر و تعهد

مهم‌ترین چالش استخراج خودکار، تشخیص وضعیت واقعی هر جمله است.

پیشنهاد

پیشنهاد می‌کنم انتشار را یک هفته عقب بیندازیم.

این جمله تصمیم نهایی نیست.

نظر

به نظر من، انتشار در این هفته ریسک زیادی دارد.

نظر شخصی است و الزام اجرایی ایجاد نمی‌کند.

احتمال

احتمالاً بتوانیم نسخه را تا پنجشنبه آماده کنیم.

این جمله موعد قطعی نیست.

تعهد

من نسخه اصلاح‌شده را تا پنجشنبه ارسال می‌کنم.

این جمله یک تعهد شخصی و اقدام قابل استخراج است.

درخواست

لطفاً تیم حقوقی قرارداد را بررسی کند.

ممکن است یک اقدام باشد، اما باید مشخص شود آیا تیم حقوقی درخواست را پذیرفته است یا خیر.

تصمیم

تصمیم نهایی این است که قرارداد قبل از امضا توسط تیم حقوقی بررسی شود.

این جمله تصمیم قطعی‌تری را نشان می‌دهد.

اقدام تأییدشده

تیم حقوقی بررسی قرارداد را تا پایان چهارشنبه انجام می‌دهد.

این جمله کار، مسئول و موعد را مشخص می‌کند.

یک Action Item کامل چه اجزایی دارد؟

یک اقدام استاندارد بهتر است دست‌کم این اجزا را داشته باشد:

کار + مسئول + موعد + وضعیت + منبع

در پروژه‌های پیچیده‌تر می‌توان این اطلاعات را نیز اضافه کرد:

• اولویت
• خروجی مورد انتظار
• وابستگی
• تأییدکننده
• پروژه مرتبط
• برچسب
• معیار تکمیل
• ریسک
• تاریخ ایجاد
• تاریخ آخرین تغییر

نمونه کامل:

task: "تهیه نسخه اصلاح‌شده قرارداد"
owner: "واحد حقوقی"
deadline: "چهارشنبه ۲۵ تیر"
status: "open"
priority: "high"
expectedOutput: "نسخه نهایی قابل امضا"
dependency: "دریافت بندهای مالی از واحد فروش"
sourceTimestamp: "00:38:12"
approvalStatus: "pending"

اگر مسئول یا موعد مشخص نباشد چه کنیم؟

اقدام ناقص را نباید حذف یا با اطلاعات حدسی تکمیل کرد.

نمونه:

اقدام: تهیه گزارش مقایسه رقبا

مسئول: مشخص نشده

موعد: مشخص نشده

وضعیت: نیازمند تکمیل

این خروجی مفیدتر از آن است که مدل به‌صورت خودکار یک مسئول یا موعد بسازد.

چه جمله‌هایی نشانه تصمیم هستند؟

مدل می‌تواند از عبارت‌های زبانی و زمینه گفت‌وگو کمک بگیرد.

نشانه‌های رایج:

• تصمیم گرفتیم...
• جمع‌بندی این است که...
• توافق شد...
• تصویب شد...
• نهایی شد...
• قرار شد...
• نتیجه این بخش...
• پس انجام می‌دهیم...
• گزینه نهایی...
• همه موافق‌اند که...
• این مورد تأیید شد...
• با این برنامه جلو می‌رویم...

اما وجود این عبارت‌ها به‌تنهایی کافی نیست.

مثلاً:

قرار بود نسخه دوشنبه منتشر شود، اما بعد تصمیم گرفتیم آن را به پنجشنبه منتقل کنیم.

اگر مدل فقط عبارت «قرار بود» را ببیند، ممکن است تاریخ قبلی را تصمیم نهایی ثبت کند. به همین دلیل باید ادامه گفت‌وگو و جمع‌بندی آخر بررسی شود.

چه جمله‌هایی نشانه اقدام هستند؟

نشانه‌های رایج:

• من انجام می‌دهم...
• تیم ما آماده می‌کند...
• لطفاً ارسال کنید...
• باید بررسی شود...
• مسئول این کار...
• تا روز... تحویل می‌دهیم...
• پیگیری با...
• این موضوع به... واگذار شد...
• برای جلسه بعد...
• لازم است...
• وظیفه تیم...
• نتیجه را اعلام می‌کنیم...

نمونه:

مریم تا سه‌شنبه پیش‌نویس گزارش را آماده می‌کند.

خروجی:

task: "آماده‌سازی پیش‌نویس گزارش"
owner: "مریم"
deadline: "سه‌شنبه"

اقدام صریح و اقدام ضمنی

اقدام صریح

علی، لطفاً تا فردا فهرست مشتریان را ارسال کن.

علی: حتماً، تا ظهر می‌فرستم.

کار، مسئول، موعد و پذیرش روشن‌اند.

اقدام ضمنی

ما هنوز آمار فروش خرداد را نداریم.

مدیر فروش: بررسی می‌کنم.

ممکن است اقدام چنین باشد:

بررسی وضعیت آمار فروش خرداد

اما موعد و خروجی مشخص نیستند.

در این حالت بهتر است وضعیت چنین ثبت شود:

task: "بررسی وضعیت آمار فروش خرداد"
owner: "مدیر فروش"
deadline: null
confidenceStatus: "implicit"
requiresConfirmation: true

آیا هر جمله دارای «باید» یک اقدام است؟

خیر.

ما باید تجربه مشتری را بهتر کنیم.

این جمله یک هدف یا جهت کلی است، نه Action Item قابل پیگیری.

برای تبدیل‌شدن به اقدام باید مشخص‌تر شود:

تیم تجربه مشتری تا پایان ماه، سه مشکل اصلی فرایند ثبت‌نام را شناسایی و گزارش کند.

یک اقدام مناسب باید تا حد امکان قابل مشاهده و قابل تکمیل باشد.

معیارهای یک اقدام قابل پیگیری

اقدام خوب معمولاً:

• با یک فعل عملی شروع می‌شود؛
• خروجی مشخص دارد؛
• مسئول دارد؛
• موعد دارد؛
• محدوده آن روشن است؛
• امکان تشخیص تکمیل‌شدن دارد.

نمونه ضعیف:

موضوع قیمت‌گذاری بررسی شود.

نمونه بهتر:

تیم محصول سه مدل قیمت‌گذاری رقبا را بررسی کند و تا پایان یکشنبه جدول مقایسه ارائه دهد.

مرحله اول: جلسه را برای استخراج بهتر طراحی کنید

کیفیت استخراج فقط به مدل وابسته نیست. نحوه برگزاری جلسه نیز اهمیت دارد.

پیش از جلسه بهتر است این موارد مشخص باشند:

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

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

دستور جلسه تصمیم‌محور

به‌جای:

بررسی وضعیت محصول

بنویسید:

۱. بررسی آمادگی نسخه ۲. تصمیم درباره تاریخ انتشار ۳. تعیین مسئول تست نهایی ۴. تعیین برنامه اطلاع‌رسانی

این ساختار به مدل و شرکت‌کنندگان کمک می‌کند بدانند چه خروجی‌ای انتظار می‌رود.

مرحله دوم: جلسه را باکیفیت ضبط کنید

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

مهم‌ترین عوامل:

• میکروفون نزدیک
• نویز کم
• صحبت‌نکردن هم‌زمان
• صدای واضح
• کانال جدا برای گویندگان
• اینترنت پایدار
• سطح صدای مناسب

در جلسه حضوری، یک لپ‌تاپ در انتهای میز معمولاً صدای همه افراد را با کیفیت برابر ثبت نمی‌کند.

در جلسه آنلاین، بهتر است هر فرد از هدست یا میکروفون مستقل استفاده کند.

برای جزئیات بیشتر، مقاله چه عواملی بر دقت تبدیل صوت فارسی به متن تأثیر می‌گذارند؟ را بخوانید.

مرحله سوم: ضبط و تحلیل جلسه را اطلاع‌رسانی کنید

شرکت‌کنندگان باید بدانند:

• جلسه ضبط می‌شود؛
• رونوشت و خلاصه تولید خواهد شد؛
• چه افرادی به فایل دسترسی دارند؛
• اقدامات استخراج‌شده کجا ثبت می‌شوند؛
• داده چه مدت نگهداری می‌شود؛
• آیا سرویس شخص ثالث استفاده می‌شود؛
• چگونه می‌توان خطا را اصلاح کرد.

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

مرحله چهارم: در ابتدای جلسه گویندگان را مشخص کنید

هر شرکت‌کننده بهتر است نام و نقش خود را بیان کند:

من نیما احمدی، مدیر محصول هستم.

من سارا رضایی، مدیر بازاریابی هستم.

در جلسه آنلاین، نام نمایشی افراد نیز باید صحیح باشد.

خروجی خودکار ممکن است ابتدا فقط چنین باشد:

• گوینده ۱
• گوینده ۲
• گوینده ۳

این برچسب‌ها باید به نام یا نقش واقعی تبدیل شوند تا مسئول اقدامات اشتباه ثبت نشود.

مرحله پنجم: تصمیم‌ها را در جلسه صریح بیان کنید

پس از پایان هر موضوع، مدیر جلسه می‌تواند جمع‌بندی کند:

جمع‌بندی این بخش:

تاریخ انتشار پانزدهم تیر است.

تیم فنی تست نهایی را تا دوازدهم تیر تمام می‌کند.

تیم بازاریابی کمپین را تا چهاردهم تیر آماده می‌کند.

این کار سه مزیت دارد:

• ابهام شرکت‌کنندگان کاهش می‌یابد؛
• رونوشت ساختار روشن‌تری پیدا می‌کند؛
• استخراج خودکار دقیق‌تر می‌شود.

مرحله ششم: پذیرش مسئولیت را روشن کنید

درخواست یک کار با پذیرفتن آن یکسان نیست.

نمونه مبهم:

مدیرعامل: علی، این موضوع را پیگیری کن.

مشخص نیست علی شنیده یا پذیرفته است.

نسخه روشن‌تر:

مدیرعامل: علی، بررسی قرارداد را تا چهارشنبه انجام می‌دهی؟

علی: بله، نسخه اصلاح‌شده را تا پایان چهارشنبه ارسال می‌کنم.

اکنون کار، مسئول، موعد و تأیید روشن‌اند.

مرحله هفتم: فایل را به متن تبدیل کنید

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

خروجی مناسب:

speaker: "مدیر فنی"
text: "تست پرداخت را تا پایان پنجشنبه کامل می‌کنیم."
startTime: "00:24:18"
endTime: "00:24:24"

Timestamp برای بررسی اقدام و بازگشت به زمینه اصلی ضروری است.

برای راهنمای کامل، مقاله چگونه جلسه را به متن و صورت‌جلسه تبدیل کنیم؟ را بخوانید.

مرحله هشتم: رونوشت را پیش از تحلیل اصلاح کنید

در اولویت بازبینی قرار دهید:

• نام افراد
• نقش‌ها
• تصمیم‌ها
• مسئولیت‌ها
• عددها
• موعدها
• تاریخ‌ها
• جمله‌های منفی
• نام پروژه و محصول
• صحبت‌های هم‌زمان

نمونه خطای پرریسک:

گفتار: بودجه هنوز تأیید نشده است.

رونوشت اشتباه: بودجه تأیید شده است.

مدل ممکن است بر اساس رونوشت اشتباه، تصمیم مالی نادرستی استخراج کند.

مرحله نهم: جلسه را به بخش‌های موضوعی تقسیم کنید

نمونه:

۱. وضعیت توسعه ۲. تست پرداخت ۳. بودجه کمپین ۴. تاریخ انتشار ۵. اقدامات تیم‌ها

بخش‌بندی باعث می‌شود:

• تصمیم هر موضوع جدا بررسی شود؛
• نتیجه اولیه با نتیجه نهایی مخلوط نشود؛
• اقدامات مشابه ادغام شوند؛
• Timestamp دقیق‌تر باشد.

مرحله دهم: نامزدهای تصمیم را استخراج کنید

در این مرحله تمام جمله‌هایی که احتمال دارد تصمیم باشند علامت‌گذاری می‌شوند.

نمونه:

candidate:
  text: "بهتر است انتشار را یک هفته عقب بیندازیم."
  type: "proposal"
  speaker: "مدیر بازاریابی"
  timestamp: "00:18:20"
candidate:
  text: "پس تاریخ نهایی انتشار پانزدهم تیر است."
  type: "decision"
  speaker: "مدیرعامل"
  timestamp: "00:27:44"

در مرحله بعد، مدل یا بازبین باید مشخص کند کدام مورد نهایی است.

مرحله یازدهم: وضعیت هر نامزد را تعیین کنید

وضعیت‌های پیشنهادی:

• proposal
• opinion
• question
• tentative
• approved
• rejected
• superseded
• pending_approval

معادل فارسی:

• پیشنهاد
• نظر
• پرسش
• موقت
• تأییدشده
• ردشده
• جایگزین‌شده
• در انتظار تأیید

مثال:

text: "انتشار تا پایان هفته انجام شود."
status: "superseded"
replacedBy: "انتشار در پانزدهم تیر انجام شود."

این ساختار مانع می‌شود تصمیم اولیه به‌عنوان نتیجه نهایی نمایش داده شود.

مرحله دوازدهم: اقدام‌های مرتبط با هر تصمیم را استخراج کنید

از هر بخش بررسی شود:

• چه کاری باید انجام شود؟
• چه کسی آن را پذیرفت؟
• چه موعدی گفته شد؟
• خروجی چیست؟
• چه وابستگی‌ای دارد؟
• آیا اقدام قطعی است؟

نمونه گفت‌وگو:

مدیر محصول: برای انتشار، متن صفحه قیمت باید اصلاح شود.

مدیر بازاریابی: من نسخه جدید را تا دوشنبه آماده می‌کنم.

مدیر محصول: پس از تأیید حقوقی، آن را منتشر می‌کنیم.

خروجی:

task: "آماده‌سازی نسخه جدید متن صفحه قیمت"
owner: "مدیر بازاریابی"
deadline: "دوشنبه"
dependency: "تأیید واحد حقوقی"
status: "open"

مرحله سیزدهم: موعدها را استاندارد کنید

موعد ممکن است نسبی بیان شود:

• فردا
• هفته بعد
• تا آخر ماه
• پنجشنبه
• قبل از انتشار

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

نمونه:

deadlineText: "پنجشنبه آینده"
deadlineDate: "2026-06-25"
meetingDate: "2026-06-22"

اگر تاریخ دقیق با اطمینان قابل تعیین نیست:

deadlineText: "هفته آینده"
deadlineDate: null
requiresConfirmation: true

مدل نباید بر اساس حدس، یک روز مشخص انتخاب کند.

مرحله چهاردهم: مسئول را استاندارد کنید

مسئول ممکن است به شکل‌های مختلف بیان شود:

• علی
• تیم فنی
• واحد حقوقی
• من
• ما
• بچه‌های محصول

در خروجی باید به شناسه یا عنوان ثابت تبدیل شود:

owner:
  type: "team"
  id: "engineering"
  displayName: "تیم فنی"

ضمیرهایی مانند «من» یا «ما» فقط با توجه به گوینده قابل تفسیرند.

مدیر بازاریابی: من تا فردا نسخه نهایی را ارسال می‌کنم.

خروجی:

owner: "مدیر بازاریابی"

مرحله پانزدهم: اقدامات تکراری را ادغام کنید

ممکن است یک اقدام چند بار در جلسه بیان شود:

باید تست پرداخت تمام شود.

تیم فنی تا پنجشنبه تست را کامل می‌کند.

پس تست پرداخت پیش از انتشار بسته شود.

این موارد احتمالاً یک اقدام‌اند، نه سه وظیفه جدا.

خروجی ادغام‌شده:

task: "تکمیل تست پرداخت"
owner: "تیم فنی"
deadline: "پنجشنبه"
sourceTimestamps:
  - "00:14:20"
  - "00:24:18"
  - "00:31:10"

مرحله شانزدهم: اقدامات متناقض را علامت‌گذاری کنید

نمونه:

مدیر فنی: رفع خطا تا سه‌شنبه ممکن نیست.

مدیر محصول: پس موعد را پنجشنبه بگذاریم.

مدیرعامل: نه، نسخه باید چهارشنبه آماده باشد.

خروجی نباید بدون توضیح یکی از تاریخ‌ها را انتخاب کند.

task: "رفع خطای پرداخت"
deadlineCandidates:
  - value: "پنجشنبه"
    speaker: "مدیر محصول"
  - value: "چهارشنبه"
    speaker: "مدیرعامل"
status: "requires_confirmation"

اگر بخش پایانی تصمیم نهایی را روشن کرده باشد، وضعیت می‌تواند تأییدشده شود.

مرحله هفدهم: موارد باز را جدا کنید

همه موضوعات به تصمیم نمی‌رسند.

openItem:
  topic: "بودجه کمپین"
  question: "آیا بودجه تکمیلی تأیید می‌شود؟"
  owner: "مدیرعامل"
  followUp: "اعلام نتیجه پس از بررسی مالی"
  deadline: null

موارد باز ممکن است شامل این‌ها باشند:

• سؤال بی‌پاسخ
• تصمیم نیازمند تأیید
• مسئول نامشخص
• موعد نامشخص
• وابستگی حل‌نشده
• اختلاف‌نظر
• اطلاعات ناقص
• موضوع جلسه بعد

مرحله هجدهم: هر نتیجه را به منبع وصل کنید

نمونه خروجی:

تصمیم: انتشار عمومی در پانزدهم تیر انجام شود. منبع: [00:27:44]

اقدام: تکمیل تست پرداخت مسئول: تیم فنی موعد: پنجشنبه منبع: [00:24:18]

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

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

مرحله نوزدهم: اقدامات را بازبینی کنید

بازبین باید برای هر اقدام پاسخ دهد:

• آیا واقعاً کاری تعیین شده است؟
• آیا اقدام پذیرفته شده؟
• مسئول درست است؟
• موعد درست است؟
• وضعیت قطعی یا موقت است؟
• خروجی مورد انتظار روشن است؟
• آیا اقدام تکراری است؟
• آیا تصمیم بعدی آن را لغو کرده است؟
• آیا اطلاعاتی توسط مدل ساخته شده است؟
• آیا Timestamp صحیح است؟

مرحله بیستم: خروجی را برای تأیید ارسال کنید

پیش از انتقال به سیستم وظایف، اقدامات می‌توانند برای صاحبان آن‌ها ارسال شوند.

نمونه وضعیت:

پیشنهادشده توسط هوش مصنوعی ↓ بررسی دبیر جلسه ↓ تأیید مسئول ↓ ثبت در سیستم

این فرایند به‌خصوص برای جلسه‌های رسمی و بین‌تیمی اهمیت دارد.

مرحله بیست‌ویکم: اقدام تأییدشده را وارد ابزار پیگیری کنید

سیستم مقصد می‌تواند یکی از این‌ها باشد:

• مدیریت پروژه
• ابزار وظایف
• CRM
• سیستم تیکت
• تقویم
• ایمیل
• داشبورد داخلی

هر وظیفه بهتر است شامل این اطلاعات باشد:

title: "تکمیل تست پرداخت"
details: "تست سناریوهای پرداخت و ثبت نتیجه"
owner: "تیم فنی"
dueDate: "2026-06-25"
priority: "high"
sourceMeeting: "جلسه برنامه‌ریزی انتشار"
sourceTimestamp: "00:24:18"
sourceUrl: "/meetings/release-planning?t=1458"
approvalStatus: "approved"

آیا اقدامات باید خودکار ثبت شوند؟

ثبت کاملاً خودکار برای همه جلسه‌ها مناسب نیست.

ثبت خودکار ممکن است مناسب باشد اگر

• فرایند تکراری و کم‌ریسک است؛
• قالب اقدام ثابت است؛
• مسئولان از قبل تعریف شده‌اند؛
• تأیید بعدی وجود دارد؛
• امکان اصلاح و حذف ساده است.

تأیید انسانی لازم‌تر است اگر

• اقدام مالی است؛
• مسئولیت میان تیم‌ها توزیع می‌شود؛
• موعد حساس است؛
• تصمیم حقوقی یا مدیریتی است؛
• اطلاعات محرمانه وجود دارد؛
• مدل در تشخیص فارسی یا گویندگان خطا دارد.

قالب پیشنهادی خروجی جلسه

عنوان جلسه:
تاریخ:
شرکت‌کنندگان:
هدف:

خلاصه:
...

تصمیم‌های تأییدشده:
1.
2.

اقدامات بعدی:
| اقدام | مسئول | موعد | وضعیت | منبع |
|---|---|---|---|---|

موارد نیازمند تأیید:
1.
2.

موضوعات باز:
1.
2.

تصمیم‌های ردشده یا جایگزین‌شده:
1.
2.

نمونه کامل

عنوان: جلسه برنامه‌ریزی انتشار نسخه جدید

تصمیم‌های تأییدشده:

• انتشار عمومی در پانزدهم تیر انجام شود.
• انتشار فقط پس از تکمیل تست پرداخت انجام شود.

اقدامات:

| اقدام | مسئول | موعد | وضعیت | منبع | |---|---|---|---|---| | تکمیل تست پرداخت | تیم فنی | ۱۲ تیر | باز | 00:24:18 | | آماده‌سازی کمپین | تیم بازاریابی | ۱۴ تیر | باز | 00:31:05 | | تأیید بودجه | مدیرعامل | مشخص نشده | نیازمند تکمیل | 00:35:42 |

موارد باز:

• مبلغ نهایی بودجه کمپین مشخص نشده است.
• تاریخ انتشار نسخه iOS نیازمند تأیید است.

پیشنهاد ردشده:

• انتشار در پایان هفته جاری

قالب JSON پیشنهادی

{
  "meetingId": "release-planning-2026-06-22",
  "decisions": [
    {
      "id": "decision-01",
      "text": "انتشار عمومی در پانزدهم تیر انجام شود.",
      "status": "approved",
      "sourceTimestamp": 1664,
      "sourceSegmentIds": ["seg-184", "seg-185"],
      "reviewStatus": "approved"
    }
  ],
  "actionItems": [
    {
      "id": "action-01",
      "task": "تکمیل تست پرداخت",
      "owner": {
        "type": "team",
        "name": "تیم فنی"
      },
      "deadlineText": "دوازدهم تیر",
      "deadlineDate": "2026-07-03",
      "status": "open",
      "sourceTimestamp": 1458,
      "reviewStatus": "pending"
    }
  ],
  "openItems": [
    {
      "topic": "بودجه کمپین",
      "question": "مبلغ بودجه تکمیلی چقدر است؟",
      "owner": "مدیرعامل",
      "deadlineDate": null
    }
  ]
}

نمونه دستور برای استخراج تصمیم‌ها

این رونوشت جلسه را بررسی کن و فقط تصمیم‌های نهایی را استخراج کن.

قواعد:

• پیشنهاد، نظر، احتمال و سؤال را تصمیم در نظر نگیر.
• اگر تصمیمی در ادامه تغییر کرده، فقط نسخه نهایی را در بخش تصمیم‌های تأییدشده قرار بده.
• تصمیم‌های ردشده یا جایگزین‌شده را جدا نمایش بده.
• متن تصمیم، گوینده تأییدکننده و Timestamp را ذکر کن.
• اطلاعاتی خارج از رونوشت اضافه نکن.
• موارد مبهم را با وضعیت «نیازمند تأیید» ثبت کن.

نمونه دستور برای استخراج اقدامات

از این رونوشت، اقدامات بعدی جلسه را استخراج کن.

برای هر اقدام این فیلدها را ارائه بده:

• شرح کار
• مسئول
• موعد
• خروجی مورد انتظار
• وابستگی
• وضعیت قطعیت
• Timestamp منبع

قواعد:

• هدف کلی را Action Item محسوب نکن.
• مسئول یا موعد نامشخص را حدس نزن.
• درخواست پذیرفته‌نشده را با وضعیت «پیشنهادی» ثبت کن.
• اقدامات تکراری را ادغام کن.
• اگر چند موعد متناقض وجود دارد، آن را علامت بزن.
• فقط اطلاعات موجود در رونوشت را استفاده کن.

نمونه دستور ترکیبی

از این جلسه خروجی ساختاریافته زیر را تهیه کن:

۱. خلاصه مدیریتی ۲. تصمیم‌های تأییدشده ۳. تصمیم‌های ردشده یا جایگزین‌شده ۴. اقدامات بعدی ۵. مسئول و موعد هر اقدام ۶. موارد نیازمند تأیید ۷. پرسش‌های باز ۸. ریسک‌ها و وابستگی‌ها

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

چگونه کیفیت استخراج را ارزیابی کنیم؟

فقط روان‌بودن خروجی کافی نیست.

پوشش تصمیم‌ها

چه تعداد از تصمیم‌های واقعی پیدا شده‌اند؟

دقت تصمیم‌ها

چه تعداد از موارد استخراج‌شده واقعاً تصمیم بوده‌اند؟

پوشش اقدامات

آیا Action Item مهمی حذف شده است؟

صحت مسئول

آیا کار به فرد یا تیم درست نسبت داده شده است؟

صحت موعد

آیا موعد درست و قطعی است؟

وضعیت تصمیم

آیا پیشنهاد، تصمیم موقت و تصمیم نهایی از هم جدا شده‌اند؟

صحت Timestamp

آیا منبع به بخش درست اشاره می‌کند؟

نرخ اقدام ناقص

چه تعداد اقدام بدون مسئول، موعد یا خروجی روشن‌اند؟

زمان بازبینی

اصلاح خروجی چقدر زمان می‌برد؟

مجموعه ارزیابی

برای ارزیابی منصفانه، از جلسه‌های واقعی استفاده کنید:

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

جدول ارزیابی نمونه

| معیار | نتیجه | |---|---| | تصمیم‌های واقعی | ۱۲ | | تصمیم‌های پیدا‌شده | ۱۱ | | تصمیم نادرست | ۲ | | اقدامات واقعی | ۱۸ | | اقدامات پیدا‌شده | ۱۵ | | مسئول اشتباه | ۲ | | موعد اشتباه | ۳ | | اقدام تکراری | ۱ | | زمان بازبینی | ۱۲ دقیقه |

خطاهای پرریسک

این خطاها باید جداگانه ثبت شوند:

• مسئول اشتباه
• موعد اشتباه
• مبلغ اشتباه
• تبدیل پیشنهاد به تصمیم
• حذف کلمه منفی
• ثبت تصمیم لغوشده
• ساخت اقدام خیالی
• حذف وابستگی مهم
• افشای اطلاعات محرمانه
• انتقال خودکار وظیفه نادرست

چگونه دقت را افزایش دهیم؟

تصمیم‌ها را صریح جمع‌بندی کنید

در پایان هر موضوع بگویید:

تصمیم نهایی این بخش...

مسئول را نام ببرید

به‌جای:

این کار انجام شود.

بگویید:

تیم فنی این کار را انجام دهد.

موعد را روشن بیان کنید

به‌جای:

در اولین فرصت

بگویید:

تا پایان چهارشنبه

خروجی مورد انتظار را مشخص کنید

نسخه اصلاح‌شده قرارداد ارسال شود.

پذیرش مسئول را ثبت کنید

مسئول تأیید کند که کار را پذیرفته است.

جمع‌بندی پایانی داشته باشید

پنج دقیقه آخر جلسه را به مرور تصمیم‌ها و اقدامات اختصاص دهید.

واژه‌نامه سازمانی بسازید

شامل:

• نام افراد
• تیم‌ها
• پروژه‌ها
• محصولات
• اصطلاح‌های تخصصی
• اختصارها

خروجی را به Timestamp وصل کنید

بازبینی را سریع‌تر می‌کند.

نقش خلاصه در استخراج اقدامات

خلاصه جلسه می‌تواند محل خوبی برای نمایش اقدامات باشد، اما بهتر است Action Item مستقیماً از رونوشت استخراج شود.

مسیر ضعیف:

رونوشت ↓ خلاصه بسیار کوتاه ↓ استخراج اقدامات

در این مسیر ممکن است اقدام‌های کم‌تکرار حذف شوند.

مسیر بهتر:

رونوشت کامل ↓ استخراج مستقیم تصمیم و اقدام ↓ خلاصه مدیریتی ↓ ترکیب خروجی‌ها

آیا مدل باید اقدام ضمنی را استخراج کند؟

به کاربرد بستگی دارد.

رویکرد محافظه‌کارانه

فقط اقدام‌های صریح و پذیرفته‌شده استخراج شوند.

مناسب برای:

• جلسه رسمی
• هیئت‌مدیره
• تعهدهای مالی
• وظایف بین‌سازمانی

رویکرد گسترده

اقدام‌های ضمنی نیز پیشنهاد شوند، اما با وضعیت جداگانه.

status: "suggested"
requiresConfirmation: true

مناسب برای:

• جلسه تیمی
• ایده‌پردازی
• مرور داخلی
• یادداشت شخصی

استخراج تصمیم در جلسه‌های چندمرحله‌ای

گاهی تصمیم در یک جمله مشخص بیان نمی‌شود.

مثال:

مدیر محصول: نسخه هنوز دو خطای مهم دارد.

مدیر فنی: تا دوشنبه رفع نمی‌شوند.

مدیر بازاریابی: کمپین را می‌توانیم یک هفته عقب ببریم.

مدیرعامل: خوب، با همین برنامه جلو برویم.

جمله آخر بدون زمینه معنای روشنی ندارد. مدل باید بفهمد «همین برنامه» به تأخیر کمپین و انتشار اشاره دارد.

در چنین مواردی:

• چند Segment باید کنار هم تحلیل شوند؛
• مرجع ضمیر مشخص شود؛
• تصمیم به زمینه متصل بماند؛
• خروجی با اطمینان پایین‌تر علامت‌گذاری شود.

اقدامات چندمسئولی

گاهی یک اقدام چند مالک دارد:

تیم محصول و حقوقی تا چهارشنبه شرایط استفاده را نهایی کنند.

ساختار:

owners:
  - "تیم محصول"
  - "واحد حقوقی"

اما وجود چند مسئول می‌تواند مسئولیت را مبهم کند. بهتر است یک مالک اصلی و مشارکت‌کنندگان مشخص شوند:

primaryOwner: "تیم محصول"
contributors:
  - "واحد حقوقی"

اقدامات وابسته

بعد از تأیید بودجه، تیم بازاریابی کمپین را فعال می‌کند.

خروجی:

task: "فعال‌سازی کمپین"
owner: "تیم بازاریابی"
dependency: "تأیید بودجه"
status: "blocked"

ثبت وابستگی مانع می‌شود اقدام زودتر از زمان مناسب پیگیری شود.

اقدامات تکرارشونده

تیم فروش هر دوشنبه گزارش هفتگی را ارسال کند.

ساختار:

task: "ارسال گزارش هفتگی فروش"
owner: "تیم فروش"
recurrence: "weekly"
day: "monday"

برای ایجاد وظیفه تکرارشونده باید الگوی تکرار نیز تأیید شود.

تصمیم‌های مشروط

اگر تست امنیت تأیید شود، نسخه پنجشنبه منتشر می‌شود.

این یک تصمیم مشروط است:

decision: "انتشار نسخه در پنجشنبه"
condition: "تأیید تست امنیت"
status: "conditional"

نباید به‌عنوان انتشار قطعی ثبت شود.

تصمیم‌های موقت

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

ساختار:

decision: "حفظ موقت قیمت‌گذاری فعلی"
status: "temporary"
reviewTrigger: "آماده‌شدن گزارش مالی"

تصمیم نیازمند تأیید بیرونی

در صورت تأیید هیئت‌مدیره، قرارداد امضا می‌شود.

ساختار:

decision: "امضای قرارداد"
status: "pending_external_approval"
approver: "هیئت‌مدیره"

حریم خصوصی و امنیت

تصمیم‌ها و اقدامات ممکن است اطلاعات حساسی را فشرده و آشکار کنند:

• برنامه محصول
• اخراج یا استخدام
• بودجه
• قرارداد
• اطلاعات مشتری
• مسائل حقوقی
• تصمیم‌های مدیریتی

کنترل‌های پیشنهادی:

• سطح دسترسی مطابق فایل اصلی
• رمزگذاری
• ثبت دسترسی
• محدودیت اشتراک
• حذف اطلاعات شخصی غیرضروری
• سیاست نگهداری
• نسخه عمومی و داخلی جدا
• عدم ارسال خودکار به افراد نامرتبط

خلاصه یا Action Item نباید سطح دسترسی گسترده‌تری از جلسه اصلی داشته باشد.

استفاده مسئولانه برای ارزیابی کارکنان

خروجی جلسه ممکن است نشان دهد چه کسی تعهدی پذیرفته یا کاری را تکمیل نکرده است. این داده نباید بدون بررسی به‌عنوان ابزار قطعی ارزیابی عملکرد استفاده شود.

دلایل:

• گوینده ممکن است اشتباه تشخیص داده شده باشد؛
• وظیفه در جلسه دیگری تغییر کرده باشد؛
• موعد موقت بوده باشد؛
• زمینه یا وابستگی حذف شده باشد؛
• فرد مسئول اصلی نبوده باشد.

برای تصمیم‌های منابع انسانی، بازبینی، شفافیت و امکان اعتراض ضروری است.

فرایند پیشنهادی جلسه‌های هفتگی

جلسه ↓ رونویسی ↓ خلاصه موضوعی ↓ استخراج تصمیم‌ها ↓ استخراج اقدامات ↓ تأیید مسئولان ↓ ثبت در ابزار پروژه ↓ مرور در جلسه بعد

در جلسه بعد، اقدامات قبلی باید با وضعیت جدید مرور شوند:

• انجام‌شده
• در حال انجام
• مسدود
• لغوشده
• منتقل‌شده

فرایند پیشنهادی جلسه فروش

نیاز مشتری ↓ اعتراض‌ها ↓ تعهدهای فروشنده ↓ تعهدهای مشتری ↓ اقدام بعدی ↓ تاریخ پیگیری ↓ ثبت در CRM

خروجی نمونه:

customerNeed: "گزارش‌گیری چندسطحی"
sellerCommitment: "ارسال نمونه داشبورد"
owner: "کارشناس فروش"
deadline: "فردا"
nextMeeting: "هفته آینده"

فرایند پیشنهادی جلسه پروژه

وضعیت ↓ مانع ↓ تصمیم ↓ تغییر محدوده ↓ اقدام ↓ مسئول ↓ موعد ↓ وابستگی

تغییر محدوده پروژه بهتر است جدا از Action Item معمولی ثبت شود.

فرایند پیشنهادی هیئت‌مدیره

برای جلسه هیئت‌مدیره:

• تصمیم‌های رسمی
• آرای مخالف
• شروط
• مسئول اجرا
• موعد گزارش
• موارد محرمانه
• تأیید صورت‌جلسه

باید با دقت بیشتری بازبینی شوند. خروجی هوش مصنوعی فقط پیش‌نویس است و جای فرایند رسمی تصویب را نمی‌گیرد.

چک‌لیست پیش از جلسه

• هدف جلسه مشخص است.
• تصمیم‌های موردنیاز فهرست شده‌اند.
• دستور جلسه آماده است.
• شرکت‌کنندگان مطلع‌اند.
• رضایت ضبط مشخص است.
• ابزار ضبط آزمایش شده است.
• قالب خروجی انتخاب شده است.
• مسئول بازبینی تعیین شده است.
• سیستم مقصد وظایف مشخص است.

چک‌لیست هنگام جلسه

• گویندگان خود را معرفی کرده‌اند.
• تصمیم‌ها صریح جمع‌بندی می‌شوند.
• مسئول هر کار نام برده می‌شود.
• مسئولیت پذیرفته می‌شود.
• موعد روشن بیان می‌شود.
• خروجی مورد انتظار مشخص است.
• موارد باز جدا می‌شوند.
• تصمیم تغییرکرده دوباره جمع‌بندی می‌شود.
• پنج دقیقه پایانی به مرور اقدامات اختصاص دارد.

چک‌لیست رونوشت

• نام گویندگان درست است.
• عددها و تاریخ‌ها بررسی شده‌اند.
• جمله‌های منفی صحیح‌اند.
• نام پروژه و محصول درست است.
• بخش‌های نامفهوم مشخص‌اند.
• صحبت هم‌زمان بررسی شده است.
• Timestampها حفظ شده‌اند.
• موضوعات جلسه بخش‌بندی شده‌اند.

چک‌لیست استخراج

• تصمیم با پیشنهاد اشتباه نشده است.
• تصمیم نهایی از نسخه‌های قبلی جداست.
• اقدام واقعاً قابل اجراست.
• مسئول حدس زده نشده است.
• موعد حدس زده نشده است.
• اقدام‌های تکراری ادغام شده‌اند.
• تناقض‌ها علامت‌گذاری شده‌اند.
• وابستگی‌ها ثبت شده‌اند.
• موارد باز حذف نشده‌اند.
• هر مورد منبع زمانی دارد.

چک‌لیست تأیید و انتقال

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

اشتباهات رایج

استفاده مستقیم از خلاصه کوتاه

Action Itemهای کم‌تکرار ممکن است حذف شوند.

تبدیل پیشنهاد به تصمیم

عبارت «بهتر است» الزاماً به معنای توافق نیست.

تعیین مسئول از روی حدس

حضور فرد در بحث به معنای مالکیت کار نیست.

تبدیل زمان تقریبی به موعد قطعی

«احتمالاً تا پنجشنبه» با «تا پنجشنبه» متفاوت است.

نادیده‌گرفتن تصمیم نهایی

نتیجه اولیه ممکن است در ادامه تغییر کند.

ثبت چند وظیفه تکراری

یک اقدام که چند بار تکرار شده، چند وظیفه ایجاد می‌کند.

حذف اقدامات ناقص

اقدام بدون موعد باید برای تکمیل علامت‌گذاری شود، نه اینکه ناپدید شود.

انتقال خودکار بدون تأیید

وظیفه اشتباه وارد سیستم پروژه می‌شود.

نبود Timestamp

بازبینی و حل اختلاف دشوار می‌شود.

نادیده‌گرفتن ضمیرها

«من انجام می‌دهم» بدون شناخت گوینده قابل استفاده نیست.

نادیده‌گرفتن شرط

تصمیم مشروط به‌عنوان تصمیم قطعی ثبت می‌شود.

نداشتن سطح دسترسی

اطلاعات حساس جلسه از طریق وظایف افشا می‌شوند.

جمع‌بندی

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

یک فرایند مناسب شامل این مراحل است:

• تعیین هدف و دستور جلسه
• ضبط باکیفیت و اطلاع‌رسانی
• تبدیل گفتار به متن
• اصلاح گویندگان، نام‌ها، عددها و تاریخ‌ها
• بخش‌بندی موضوعی
• استخراج نامزدهای تصمیم
• تفکیک پیشنهاد، نظر، تصمیم و تعهد
• انتخاب تصمیم نهایی
• استخراج اقدام، مسئول و موعد
• ثبت شرط، وابستگی و موارد باز
• اتصال هر نتیجه به Timestamp
• بازبینی انسانی
• تأیید صاحبان وظایف
• انتقال خروجی تأییدشده به سیستم پیگیری
• مرور وضعیت در جلسه بعد

Action Item مناسب باید تا حد امکان دارای این اجزا باشد:

کار مشخص + مسئول مشخص + موعد مشخص + خروجی مورد انتظار + وضعیت + منبع زمانی

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

استخراج تصمیم و اقدام را از رونوشت دقیق آغاز کنید

فایل جلسه را در سابچین به متن تبدیل کنید و رونوشت زمان‌بندی‌شده را برای تهیه صورت‌جلسه و اقدامات بعدی آماده سازید.

شروع تبدیل جلسه به متن

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

چگونه اقدامات جلسه را با هوش مصنوعی استخراج کنیم؟

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

تفاوت تصمیم و Action Item چیست؟

تصمیم نتیجه نهایی درباره یک موضوع است. Action Item کاری است که باید برای اجرای تصمیم یا پیگیری موضوع انجام شود.

آیا هر پیشنهاد یک تصمیم محسوب می‌شود؟

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

یک اقدام کامل چه اطلاعاتی دارد؟

شرح کار، مسئول، موعد، وضعیت، خروجی مورد انتظار و Timestamp منبع.

اگر مسئول مشخص نشده باشد چه کنیم؟

مسئول را حدس نزنید. اقدام را با وضعیت «نیازمند تعیین مسئول» ثبت کنید.

اگر موعد گفته نشده باشد چه کنیم؟

فیلد موعد را خالی یا نامشخص نگه دارید و آن را برای تکمیل علامت‌گذاری کنید.

آیا اقدام‌های ضمنی نیز باید استخراج شوند؟

می‌توان آن‌ها را پیشنهاد کرد، اما بهتر است وضعیت «ضمنی» یا «نیازمند تأیید» داشته باشند.

چگونه تصمیم نهایی را از پیشنهادهای قبلی تشخیص دهیم؟

بخش پایانی موضوع، جمله‌های جمع‌بندی، تأیید افراد تصمیم‌گیر و تغییرهای بعدی را بررسی کنید.

Timestamp چه کاربردی دارد؟

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

آیا می‌توان اقدامات را مستقیم به ابزار مدیریت پروژه منتقل کرد؟

از نظر فنی بله، اما برای موارد رسمی بهتر است ابتدا دبیر جلسه و مسئول اقدام آن را تأیید کنند.

آیا هوش مصنوعی می‌تواند مسئول هر اقدام را تشخیص دهد؟

اگر نام گویندگان و جمله پذیرش مسئولیت روشن باشد، می‌تواند پیشنهاد دهد. در گفت‌وگوی مبهم احتمال خطا بیشتر است.

چگونه موعدهای نسبی مانند «فردا» را ثبت کنیم؟

تاریخ جلسه را مبنا قرار دهید و تاریخ دقیق را همراه با عبارت اصلی ذخیره کنید. اگر ابهام وجود دارد، تأیید انسانی لازم است.

آیا خلاصه جلسه برای استخراج Action Item کافی است؟

همیشه نه. خلاصه ممکن است بعضی اقدامات را حذف کند. بهتر است اقدامات مستقیماً از رونوشت کامل استخراج شوند.

آیا مدل می‌تواند تصمیم‌های تغییرکرده را تشخیص دهد؟

می‌تواند پیشنهاد دهد، اما باید نسخه‌های اولیه، ردشده و نهایی جدا ثبت و بازبینی شوند.

چه جلسه‌هایی به کنترل دقیق‌تری نیاز دارند؟

جلسه‌های مالی، حقوقی، منابع انسانی، هیئت‌مدیره، قرارداد و تصمیم‌های دارای مسئولیت رسمی.

منابع و مطالعه بیشتر

• Zoom Support — تولید خلاصه جلسه بر پایه داده تبدیل گفتار به متن
• Zoom Support — پیشنهاد و مدیریت وظایف از خلاصه و رونوشت جلسه
• Microsoft Learn — دریافت خلاصه، Action Item و Mentionهای جلسه
• Otter Help — مدیریت Action Item و مشاهده محل آن در رونوشت