وبلاگ
راهاندازی مرکز تماس برای شرکت؛ IVR، صف تماس، ضبط و گزارشگیری
فرض کنید ساعت ۱۰ صبح است و سه مشتری تقریباً همزمان با شرکت تماس میگیرند: یکی میخواهد درباره خرید سؤال کند، دیگری برای پشتیبانی تماس گرفته و سومی پیگیر یک سفارش قبلی است. در سیستم تلفنی معمولی، تماسها ممکن است روی یک یا چند داخلی زنگ بخورند، مشتری چند بار منتقل شود و مدیر در پایان روز فقط بداند «تماس زیاد بود». در یک مرکز تماس درست طراحیشده، هر تماس مسیر مشخص دارد: خوشامدگویی، انتخاب واحد، ورود به صف، اتصال به اپراتور مناسب، ثبت نتیجه، ضبط بر اساس سیاست سازمان و در نهایت تبدیل شدن به دادهای که مدیر بتواند از آن تصمیم بگیرد.
راه اندازی مرکز تماس صرفاً نصب یک نرمافزار یا خرید چند هدست نیست. اگر IVR بیش از حد پیچیده باشد، صف بدون منطق توزیع تماس طراحی شود، ضبط بدون سیاست نگهداری روشن فعال شود یا شبکه در ساعات شلوغ افت کند، تجربه مشتری بدتر میشود؛ حتی اگر تجهیزات گران باشند. این مقاله مسیر طراحی را از دید کسبوکار و اجرا کنار هم میگذارد تا قبل از خرید، دقیقاً بدانید چه چیزهایی باید در Scope پروژه تعریف شوند.
|
پاسخ سریع: برای راه اندازی مرکز تماس حرفهای باید مسیر تماس، IVR، صف و سیاست توزیع، تعداد تماس همزمان، ضبط و مدت نگهداری، گزارشهای مدیریتی، امنیت شبکه و سناریوی پشتیبان از ابتدا طراحی شوند. انتخاب سرور، گیتوی، تلفن IP یا هدست بعد از این نیازسنجی انجام میشود؛ نه برعکس. |
اگر پروژه شما وارد مرحله طراحی یا اجرا شده است، مشخصات تعداد اپراتورها و حجم تماس را برای راه اندازی مرکز تماس ارسال کنید تا معماری اولیه متناسب با شرایط مجموعه بررسی شود.
مرکز تماس چه تفاوتی با تلفن عادی شرکت دارد؟
تلفن عادی شرکت معمولاً برای «برقرار شدن تماس» طراحی شده است؛ شماره زنگ میخورد، یک نفر پاسخ میدهد و در صورت نیاز تماس را به داخلی دیگری منتقل میکند. مرکز تماس برای «مدیریت فرآیند تماس» ساخته میشود. یعنی سیستم میداند تماس از کدام مسیر وارد شده، در کدام صف قرار گرفته، چند ثانیه منتظر مانده، کدام اپراتور پاسخ داده، نتیجه چه بوده و در صورت تعریف سازمان چه بخشی از مکالمه باید ثبت و نگهداری شود.
تفاوت مهم دیگر، قابلیت اندازهگیری است. وقتی واحد فروش میگوید «مشتریها زیاد منتظر میمانند»، مدیر به جای حدس میتواند زمان انتظار، نرخ پاسخگویی، تماسهای رهاشده و ساعات اوج را ببیند. اگر بخش پشتیبانی با تماسهای تکراری روبهروست، میتوان مسیر IVR، مهارت اپراتورها یا فرآیند CRM را بررسی کرد. به همین دلیل مرکز تماس VoIP یک ابزار مدیریتی است، نه فقط یک تلفن پیشرفته.
|
موضوع |
تلفن عادی شرکت |
مرکز تماس VoIP |
|
مسیریابی |
زنگ مستقیم روی یک یا چند داخلی |
IVR، صف، گروه، مهارت و ساعات کاری |
|
انتظار مشتری |
اغلب بدون جایگاه و سیاست روشن |
پیام انتظار، موسیقی، اعلام وضعیت و سیاست Overflow |
|
گزارش |
محدود به تاریخچه تماس |
KPI، صف، اپراتور، تماس رهاشده و ساعات اوج |
|
ضبط |
اغلب دستی یا محدود |
قابل تعریف بر اساس صف/کاربر/سیاست سازمان |
|
توسعه |
وابسته به ظرفیت فیزیکی سیستم |
قابل توسعه با کاربران، شعب، Softphone و یکپارچهسازی |
گیت وی گرند استریم مدل HT818 کد 17807
380,000,000 ریال
گیت وی ویپ گرنداستریم HT841 کد 17799
330,000,000 ریال
گیت وی ویپ گرنداستریم HT881 کد 17803
490,000,000 ریالاجزای اصلی مرکز تماس
مرکز تماس از چند لایه تشکیل میشود و ضعف هر لایه میتواند کل تجربه را خراب کند. سرور یا IP-PBX منطق تماس را اجرا میکند؛ خطوط شهری، SIP Trunk یا گیتوی مسیر ارتباط با شبکه مخابراتی را فراهم میکنند؛ تلفن IP، Softphone و هدست ابزار اپراتور هستند؛ شبکه و برق کیفیت پایه را میسازند؛ و نرمافزار گزارش و CRM تماس را به فرآیند کسبوکار متصل میکند.
|
جزء |
نقش در مرکز تماس |
سؤال تصمیمگیری |
|
IP-PBX / سرور |
ثبت داخلیها، IVR، صف، ضبط، گزارش و مسیر تماس |
چند تماس همزمان و چند اپراتور در اوج داریم؟ |
|
خط / SIP / Gateway |
ورود و خروج تماس از شبکه مخابراتی |
چند کانال همزمان و چه مسیر پشتیبانی لازم است؟ |
|
تلفن IP / Softphone / هدست |
ابزار روزانه اپراتور |
اپراتور ثابت است یا دورکار؟ کیفیت هدست و کنترل تماس چه سطحی لازم است؟ |
|
شبکه / PoE / روتر |
حمل Voice و تأمین ارتباط پایدار |
VLAN، QoS، UPS و لینک جایگزین داریم؟ |
|
ضبط / Storage |
نگهداری فایل و دسترسی کنترلشده |
چه تماسهایی و برای چه مدت نگهداری شوند؟ |
|
گزارش / CRM |
دید مدیریتی و ثبت نتیجه تماس |
مدیر دقیقاً چه KPI و چه گردش کاری میخواهد؟ |
برای بررسی سرویسهای موجود سایت و مسیرهای اجرایی مرتبط، مشاهده تجهیزات مرتبط با مرکز تماس میتواند نقطه شروع مناسبی برای هماهنگی نیازسنجی باشد.
نقشه اجرای پیشنهادی مرکز تماس از نظر اجرایی بهتر است به چند خروجی قابل تحویل تقسیم شود:
- نیازسنجی: تعداد اپراتورها، واحدها، تماس همزمان، خطوط، ساعات کاری و سناریوهای خارج از ساعت ثبت شود.
- طراحی Call Flow: مسیر تماس ورودی، IVR، صف، انتقال، Callback یا Overflow روی فلوچارت مشخص شود.
- ارزیابی زیرساخت: شبکه، اینترنت، برق، رک، سوئیچ، فایروال و ذخیرهسازی بررسی شوند.
- پیادهسازی Pilot: یک صف و چند اپراتور با تماس واقعی آزمایش شوند تا کیفیت صدا و گردش کار سنجیده شود.
- راهاندازی کامل: کاربران، صفها، ضبط، گزارش، دسترسیها و یکپارچهسازیها فعال شوند.
- تست سناریو: ساعات کاری، قطع اینترنت، اشغال اپراتورها، انتقال، تماس رهاشده و بازیابی تنظیمات آزمایش شوند.
- تحویل و آموزش: دسترسی مدیر، مستندات، Backup، آموزش اپراتور و برنامه پشتیبانی تحویل شود.
طراحی IVR و منوی صوتی
IVR اولین نقطه تماس مشتری با سازمان است؛ بنابراین هر گزینه باید یک هدف واقعی داشته باشد. منویی که پنج سطح پشت سر هم دارد یا از عبارتهای طولانی و اداری استفاده میکند، مشتری را خسته میکند. در اغلب شرکتها، منوی اولیه بهتر است کوتاه باشد و مسیرهای پرتکرار مانند فروش، پشتیبانی و امور مشتریان را زود در دسترس قرار دهد.
طراحی خوب IVR از روی ساختار سازمانی کپی نمیشود؛ از روی نیت تماسگیرنده ساخته میشود. ممکن است شرکت هفت واحد داخلی داشته باشد، اما مشتری فقط سه کار اصلی انجام دهد. در این حالت سه مسیر روشن بهتر از هفت گزینهای است که مخاطب باید نام واحدهای سازمانی را حدس بزند. ساعات غیرکاری، تعطیلات، مسیر اپراتور، تکرار پیام و خطای انتخاب هم باید از ابتدا تعیین شوند.
- پیام خوشامدگویی کوتاه و قابل فهم باشد و نام شرکت را روشن اعلام کند.
- گزینههای اصلی براساس پرتقاضاترین دلیل تماس مرتب شوند، نه چارت سازمانی.
- برای عدم انتخاب، انتخاب اشتباه و ساعات غیرکاری مسیر مشخص تعریف شود.
- اگر مشتری از منو وارد صف شد، دوباره مجبور به شنیدن پیامهای غیرضروری نشود.
- هر تغییر IVR با تماس واقعی از موبایل، خط ثابت و مسیرهای مختلف تست شود.
برای فایل صوتی IVR نیز فقط «صدای زیبا» کافی نیست. سرعت خواندن، وضوح اعداد، فاصله بین گزینهها، موسیقی انتظار و سطح صدا باید در تلفن واقعی شنیده شوند. بهتر است نسخه نهایی پیامها با تاریخ و متن مصوب نگهداری شود تا در تغییرات بعدی مشخص باشد کدام فایل در سیستم فعال است.
صف تماس و توزیع بین اپراتورها
سیستم صف تماس زمانی مفید است که قواعد آن با ظرفیت واقعی تیم هماهنگ باشند. هدف فقط نگه داشتن مشتری پشت خط نیست؛ باید تماس در کوتاهترین زمان ممکن به اپراتوری برسد که توان پاسخگویی دارد. برای تیم کوچک، توزیع چرخشی یا زنگ همزمان ممکن است کافی باشد. در تیمهای بزرگتر میتوان از سیاستهای مبتنی بر کمترین تماس پاسخدادهشده، کمترین زمان از تماس قبلی یا مهارت استفاده کرد.
|
سیاست نمونه |
کاربرد مناسب |
ریسک اگر اشتباه استفاده شود |
|
Ring All |
تیم کوچک با چند اپراتور همسطح |
زنگ مداوم برای همه و کاهش تمرکز |
|
Round Robin |
تقسیم نسبتاً متوازن بین اپراتورها |
مهارت و اولویت مشتری را در نظر نمیگیرد |
|
Least Recent / Fewest Calls |
توازن بار کاری در تیم مشابه |
اگر بعضی اپراتورها تخصص متفاوت دارند، کیفیت پاسخ ممکن است افت کند |
|
Skill-based / Priority |
فروش تخصصی، VIP یا پشتیبانی سطحبندیشده |
نیازمند داده و نگهداری دقیق مهارتها و اولویتها |
علاوه بر استراتژی توزیع، باید درباره Timeout، حداکثر طول صف، تماس رهاشده، Overflow و Callback تصمیم گرفته شود. مثلاً اگر همه اپراتورها بیش از حد مشخصی درگیر باشند، تماس میتواند به صف دوم، صندوق صوتی یا درخواست تماس مجدد هدایت شود. این تصمیمها باید قبل از اجرا با مدیر فروش یا پشتیبانی نهایی شوند؛ چون تنظیم فنی بدون سیاست کسبوکار فقط صفی طولانی و بیهدف میسازد.
ضبط مکالمه و الزامات نگهداری
ضبط مکالمات شرکت میتواند برای کنترل کیفیت، آموزش، رسیدگی به اختلافات یا ثبت تعاملات مهم مفید باشد؛ اما از همان روز اول باید مشخص شود «چه چیزی»، «برای چه مدت» و «در اختیار چه کسی» نگهداری میشود. فعال کردن ضبط برای همه تماسها بدون سیاست نگهداری، خیلی زود هم فضای ذخیرهسازی را مصرف میکند و هم ریسک دسترسی غیرضروری به فایلهای صوتی را بالا میبرد.
در پلتفرمهایی مانند Asterisk، ضبط میتواند در سطح تماس و با ابزارهایی مانند MixMonitor انجام شود؛ اما طراحی عملی فقط به فعالکردن Recording ختم نمیشود. نامگذاری فایل، محل Storage، Backup، حذف دورهای، دسترسی مدیران، لاگ دانلود و رفتار ضبط هنگام Transfer باید تست شوند. برای برآورد فضا، به جای استفاده از یک عدد ثابت، چند روز نمونه ضبط واقعی بگیرید و «میانگین حجم فایل در دقیقه × مجموع دقیقه ضبطشده × مدت نگهداری» را محاسبه کنید.
از نظر محرمانگی نیز سیاست سازمان، قراردادها و الزامات قانونی مرتبط با ضبط تماس باید قبل از بهرهبرداری بررسی شوند. در صورت نیاز، اطلاعرسانی مناسب به تماسگیرنده و محدود کردن دسترسی به فایلها در فرآیند تعریف شود. این مقاله توصیه حقوقی نیست؛ هدف آن این است که موضوع ضبط از یک گزینه نرمافزاری به یک فرآیند کنترلشده تبدیل شود.
- مدت نگهداری مشخص: مثلاً بر اساس نوع صف یا نیاز عملیاتی، نه «برای همیشه».
- سطوح دسترسی: اپراتور، سرپرست، مدیر و ادمین لزوماً نباید دسترسی یکسان داشته باشند.
- Backup و Restore تستشده: فایل ضبطشده بدون برنامه بازیابی، آرشیو قابل اتکا نیست.
- حذف امن و دورهای: تاریخ انقضا و مسئول اجرای حذف مشخص باشد.
- آزمون Transfer: ضبط قبل و بعد از انتقال تماس و کنفرانس بررسی شود.
گزارشها و KPIهای مهم
گزارش خوب باید به یک سؤال مدیریتی پاسخ دهد. داشبوردی با دهها نمودار زمانی ارزش دارد که مدیر بداند کدام عدد را برای چه تصمیمی میبیند. برای مرکز تماس فروش، نرخ پاسخ و تماسهای از دسترفته مهم است؛ برای پشتیبانی، زمان انتظار، مدت رسیدگی و حل مسئله در تماس اول اهمیت بیشتری پیدا میکند. KPIها باید با هدف واحد تعریف شوند و بهتنهایی برای قضاوت عملکرد یک اپراتور استفاده نشوند.
|
KPI |
تعریف ساده |
کاربرد مدیریتی |
|
Service Level |
درصد تماسهایی که در زمان هدف پاسخ داده میشوند |
آیا ظرفیت صف با انتظار مورد قبول هماهنگ است؟ |
|
ASA |
میانگین زمان تا پاسخ اپراتور |
کشف ساعات اوج و کمبود ظرفیت |
|
Abandonment Rate |
درصد تماسهایی که پیش از پاسخ قطع میشوند |
بررسی طول صف، IVR و تجربه انتظار |
|
AHT |
میانگین زمان رسیدگی شامل مکالمه و کار پس از تماس |
برنامهریزی نیروی انسانی و فرآیند |
|
FCR |
درصد مسائلی که در اولین تماس حل میشوند |
کیفیت پاسخ، دانش اپراتور و فرآیند پشتیبانی |
|
Occupancy / Utilization |
سهم زمانی که اپراتور درگیر تماس و کار مرتبط است |
تشخیص فشار بیش از حد یا ظرفیت بلااستفاده |
مثال: بالا بودن AHT همیشه بد نیست. اگر تیم پشتیبانی مسئله پیچیدهای را در تماس اول حل میکند، کاهش اجباری مدت تماس ممکن است FCR را خراب کند و باعث تماس مجدد شود. به همین دلیل KPIها باید کنار هم خوانده شوند. مدیر بهتر است یک داشبورد محدود با چند شاخص اصلی داشته باشد و گزارش عمیقتر را برای تحلیل دورهای نگه دارد.
زیرساخت شبکه و امنیت
مرکز تماس VoIP به همان اندازه که نرمافزاری است، به شبکه وابسته است. اگر Packet Loss، Jitter یا تأخیر در ساعات شلوغ بالا برود، اپراتور و مشتری آن را به شکل صدای رباتی، قطعووصلی یا تأخیر مکالمه حس میکنند. بنابراین پیش از مهاجرت باید مسیر کابل، سوئیچ، ظرفیت uplink، اینترنت، روتر، فایروال و برق اضطراری در شرایط واقعی تست شوند.
در شبکههای شرکتی، جداکردن Voice در VLAN مناسب، استفاده از QoS در نقاطی که واقعاً ازدحام وجود دارد و مانیتورینگ لینکها میتواند مدیریت تماس را قابل پیشبینیتر کند. اگر اپراتورها دورکار هستند، کیفیت و امنیت مسیر بیرون شرکت نیز باید بخشی از طراحی باشد. بازکردن مستقیم پنل مدیریتی یا SIP به اینترنت با رمز ساده، راهحل مناسبی برای دسترسی از راه دور نیست؛ استفاده از VPN، محدودیت IP، SBC یا روش امن متناسب با معماری باید بررسی شود.
- برای اکانتهای SIP رمزهای قوی و غیرتکراری تعریف شود و حسابهای بلااستفاده غیرفعال شوند.
- دسترسی مدیریتی PBX فقط برای افراد مشخص و ترجیحاً از مسیر امن محدود شود.
- فایروال، لاگ و هشدار تلاشهای ناموفق ورود فعال و دورهای بررسی شوند.
- Backup تنظیمات، فایلهای IVR و اطلاعات صف روی مقصدی جدا از سرور اصلی نگهداری شود.
- UPS برای سوئیچ، روتر، سرور و گیتوی بر اساس زمان موردنیاز طراحی شود.
- سناریوی قطع اینترنت یا SIP Trunk از قبل مشخص و در زمان تحویل آزمایش شود.
در پروژههای تهران که بخشی از پشتیبانی حضوری است، داشتن مستندات شبکه، IPها، VLANها، نسخه تنظیمات و لیست تجهیزات باعث میشود عیبیابی وابسته به حافظه یک تکنسین نباشد. پشتیبانی ریموت نیز زمانی امن و سریع است که دسترسی آن از قبل طراحی شده باشد، نه اینکه هنگام خرابی برای اولین بار پورت جدیدی روی اینترنت باز شود.
هزینه و زمان اجرا
هزینه راه اندازی مرکز تماس از تعداد صندلی بیشتر به «تعداد تماس همزمان و پیچیدگی فرآیند» وابسته است. دو شرکت با ده اپراتور میتوانند بودجه کاملاً متفاوتی داشته باشند: یکی فقط یک صف فروش و ضبط محدود میخواهد؛ دیگری چند برند، چند شعبه، CRM، داشبورد سرپرست، ضبط طولانی، لینک پشتیبان و SLA نیاز دارد. برای همین مقایسه پیشفاکتور باید بر اساس Scope یکسان انجام شود.
سناریو | Scope معمول | زمان برنامهریزی اولیه* | هزینهسازهای اصلی |
تیم کوچک ۳ تا ۵ اپراتور | یک یا دو صف، IVR کوتاه، گزارش پایه، ضبط انتخابی | حدود ۲ تا ۴ روز کاری | سرور/سرویس، خطوط، هدست یا تلفن، نصب و آموزش |
تیم ۱۰ تا ۳۰ اپراتور | چند صف، گزارش سرپرست، ضبط گسترده، CRM یا API | حدود ۵ تا ۱۰ روز کاری | ظرفیت سرور، Storage، لایسنس، شبکه، یکپارچهسازی و تست |
مرکز تماس چندشعبهای/حساس | افزونگی، چند لینک، SLA، امنیت و مانیتورینگ | از ۲ هفته به بالا | Failover، سرور/Storage افزونه، لینک پشتیبان، مانیتورینگ و پشتیبانی |
*این زمانها فقط برای برنامهریزی اولیهاند و تعهد زمان تحویل نیستند. وضعیت شبکه موجود، آماده بودن خطوط، فرآیند تأیید فایلهای صوتی، یکپارچهسازی CRM و نیاز به تجهیزات میتواند زمان را تغییر دهد.
برای قیمتگذاری شفاف، پیشفاکتور را به ردیفهای مشخص تقسیم کنید: نیازسنجی و طراحی، IP-PBX یا سرویس ابری، خطوط و گیتوی، تلفن و هدست، شبکه و PoE، ذخیرهسازی ضبط، لایسنس و ماژولها، اتصال CRM، اجرای فنی، آموزش، مستندات و پشتیبانی. اگر یک پیشنهاد فقط یک عدد نهایی با عنوان «راهاندازی کامل» دارد، مقایسه آن با پیشنهاد دیگر دشوار خواهد بود.
CTA بریف: برای دریافت طراحی اولیه، تعداد اپراتورها، تعداد تماس همزمان در ساعات شلوغ، صفهای موردنیاز، نوع خطوط فعلی، مدت نگهداری ضبط و گزارشهایی را که مدیر لازم دارد ارسال کنید. این اطلاعات برای برآورد بسیار مهمتر از تعداد کل کارکنان شرکت است.
سوالات متداول
نه. بسته به معماری میتوان از Softphone روی کامپیوتر، تلفن IP یا ترکیبی از هر دو استفاده کرد. برای اپراتورهایی که ساعات زیادی تماس دارند، کیفیت هدست و راحتی کار معمولاً مهمتر از امکانات تزئینی تلفن است.
مبنای درست، تعداد تماسهای همزمان ورودی و خروجی است، نه فقط تعداد اپراتورها. اگر در اوج ۸ تماس همزمان دارید، مسیر مخابراتی باید ظرفیت آن را با حاشیه مناسب پوشش دهد. نوع خط آنالوگ، SIP یا سرویسدهنده نیز روی طراحی اثر دارد.
عدد ثابت وجود ندارد. منوی اول باید کوتاه و مبتنی بر پرتقاضاترین هدف تماس باشد. اگر گزینهها زیاد هستند، بهتر است طراحی چندمرحلهای فقط زمانی استفاده شود که واقعاً مسیر مشتری را سادهتر کند، نه اینکه چارت سازمانی را به تلفن منتقل کند.
به فرمت صوتی، تعداد تماس، مدت متوسط مکالمه و سیاست نگهداری وابسته است. بهترین روش این است که چند روز نمونه واقعی ضبط شود و متوسط حجم فایل در دقیقه اندازهگیری شود؛ سپس ظرفیت دوره نگهداری و Backup محاسبه شود.
اگر فرآیند فروش یا پشتیبانی وابستگی جدی به CRM دارد، بهتر است از ابتدا در معماری دیده شود؛ اما برای تیم کوچک میتوان ابتدا Call Flow و صف پایدار را راهاندازی و یکپارچهسازی را مرحله بعد انجام داد، به شرطی که API و مسیر توسعه از ابتدا بررسی شده باشد.
معمولاً Service Level، ASA، تماسهای رهاشده، AHT، حجم تماس به تفکیک ساعت و عملکرد صفها نقطه شروع خوبی هستند. KPI نهایی باید با هدف کسبوکار تعریف شود و صرفاً برای رتبهبندی اپراتورها استفاده نشود.
پاسخ به معماری بستگی دارد. مرکز تلفن On-Premise میتواند تماس داخلی را داخل شبکه حفظ کند، اما SIP Trunk، سرویس ابری یا اپراتورهای دورکار به لینک ارتباطی وابستهاند. مسیر پشتیبان و سناریوی Failover باید پیش از تحویل تست شود.
جمعبندی
مرکز تماس خوب از «سفر تماس» شروع میشود، نه از فهرست تجهیزات. وقتی IVR کوتاه و هدفمند، صف متناسب با ظرفیت تیم، سیاست ضبط روشن، KPIهای قابل استفاده، شبکه پایدار و دسترسی امن کنار هم قرار بگیرند، تماس از یک اتفاق روزمره به فرآیندی قابل اندازهگیری تبدیل میشود. نتیجه این طراحی میتواند تجربه منظمتر مشتری و دید دقیقتر مدیر از عملکرد تیم باشد.
برای شروع، تعداد اپراتورها، تعداد تماس همزمان در اوج، واحدهای پاسخگو، نوع خطوط، نیاز به ضبط و گزارشهای مدیریتی را در یک برگه جمع کنید. همین دادهها مشخص میکنند مرکز تماس شما به چه ظرفیت، صف، Storage، شبکه و سطح پشتیبانی نیاز دارد.
برای بررسی معماری و اجرای پروژه در تهران یا پشتیبانی ریموت، مشخصات فوق را ارسال کنید و درخواست راه اندازی مرکز تماس را ثبت کنید.
