ہیلپ ڈیسک ٹکٹنگ سسٹم کیسے بنائیں: ٹکٹس، اسٹیٹسز، تفویض اور ای میل
ہیلپ ڈیسک ٹکٹنگ سسٹم بکھری ہوئی درخواستوں — ای میلز، پیغامات، راہداری میں “ایک چھوٹا سوال” — کو ٹکٹس میں بدلتا ہے: ہر مسئلے کا ایک ریکارڈ، جس کا ایک مالک، ایک اسٹیٹس، ایک ترجیح اور مکمل گفتگو ہو۔ اسے بنانے کے لیے آپ کو ٹکٹ بنانے کا طریقہ، فلٹرز کے ساتھ ایک مشترکہ قطار، تفویض، ایک ایسا سلسلہ جو عوامی جوابات کو نجی نوٹس سے الگ رکھے، اور اطلاعات درکار ہیں تاکہ کوئی انتظار میں نہ رہ جائے۔ AI ایپ بلڈر اندرونی IT، HR یا فیسیلیٹیز ڈیسک کا ایک مضبوط پہلا ورژن ایک دوپہر میں بنا سکتا ہے۔ گاہکوں کے لیے سپورٹ، جس میں ای میل تھریڈنگ، جوابی اہداف اور رپورٹنگ ہو، زیادہ توجہ مانگتی ہے — اور یہیں قائم شدہ ہیلپ ڈیسک پروڈکٹس اپنی فیس کماتی ہیں۔
سسٹم کو کیا چاہیے
ڈیٹا
| ٹیبل | اہم فیلڈز |
|---|---|
| ٹکٹس | نمبر، موضوع، درخواست کنندہ، زمرہ، ترجیح، اسٹیٹس، تفویض شدہ شخص، ٹیم، تخلیق کا وقت، پہلا جواب، حل ہونے کا وقت |
| پیغامات | ٹکٹ، مصنف، متن، عوامی جواب یا اندرونی نوٹ، منسلکات، بھیجنے کا وقت |
| درخواست کنندگان | نام، ای میل، تنظیم یا شعبہ |
| ایجنٹس | نام، ای میل، ٹیم، کردار (ایجنٹ، لیڈ، ایڈمن) |
| زمرے | نام، ڈیفالٹ ٹیم، ڈیفالٹ ترجیح |
| تیار جوابات | عنوان، متن، زمرہ |
| سرگرمی کا لاگ | ٹکٹ، کس نے، کیا بدلا، کب |
پہلا جواب اور حل ہونے کے ٹائم اسٹیمپس شروع ہی سے محفوظ کریں۔ ہر رپورٹ انہی پر بنتی ہے، اور انہیں بعد میں دوبارہ بنایا نہیں جا سکتا۔
صفحات
- درخواست کنندہ: زمرے اور منسلکات کے ساتھ “درخواست جمع کریں” فارم، “میری درخواستیں” کی فہرست، اور ہر ٹکٹ کا سلسلہ۔
- ایجنٹ: قطار (میرے ٹکٹس، غیر تفویض شدہ، تمام کھلے)، فلٹرز اور تلاش، اور ٹکٹ کا صفحہ جہاں جواب، نوٹ، اسٹیٹس، ترجیح اور تفویض کے کنٹرولز ہوں۔
- ایڈمن: زمرے، ٹیمیں، ایجنٹس، تیار جوابات، اور ایک سادہ رپورٹ۔
اجازتیں
درخواست کنندگان صرف اپنے ٹکٹس اور عوامی جوابات دیکھیں۔ ایجنٹس اپنی ٹیم کے ٹکٹس اور اندرونی نوٹس دیکھیں۔ لیڈز اور ایڈمنز سب کچھ دیکھیں اور ترتیبات سنبھالیں۔ اندرونی نوٹس کا گاہک تک پہنچنا ہیلپ ڈیسک کی کلاسک تباہی ہے، اس لیے اسے سرور پر نافذ کریں، صرف ٹیب چھپا کر نہیں۔ دیکھیں کردار پر مبنی رسائی۔
فیصلے اور سمجھوتے
فارم، ای میل یا دونوں
ویب فارم سب سے سادہ ہے اور صاف ڈیٹا دیتا ہے: زمرہ، ترجیح اور لازمی فیلڈز۔ ای میل وصولی — لوگ support@ کو لکھیں اور ٹکٹ بن جائے — وہ ہے جو گاہک توقع کرتے ہیں، مگر اس کے لیے ایسا ای میل فراہم کنندہ درکار ہے جو پیغامات وصول کرے اور آپ کی ایپ کو بھیجے، اور تھریڈنگ تاکہ جوابات درست ٹکٹ سے جڑیں (عموماً موضوع میں ٹکٹ نمبر یا ایک منفرد ری پلائی ایڈریس)۔ فارم سے آغاز کریں؛ ورک فلو ثابت ہونے کے بعد ای میل شامل کریں۔ اپنی ایپ سے ای میل بھیجنا باہر جانے والے حصے کو بیان کرتا ہے۔
تفویض
آپشنز: ایجنٹس غیر تفویض شدہ قطار سے چنیں؛ ٹیم کے اندر راؤنڈ رابن؛ یا زمرے کے لحاظ سے تفویض۔ چھوٹی ٹیموں کے لیے قطار سے چننا کام کرتا ہے۔ جب ٹکٹس بغیر مالک کے پڑے رہنے لگیں تو خودکار تفویض مددگار ہوتی ہے۔
ترجیحات اور جوابی اہداف
دو یا تین ترجیحات طے کریں، ہر ایک کے لیے پہلے جواب کا ہدف (“فوری: 1 گھنٹہ، عام: 1 کاروباری دن”)۔ ہر ٹکٹ پر باقی وقت دکھانا کسی ماہانہ رپورٹ سے زیادہ مفید ہے جسے کوئی نہیں پڑھتا۔ کاروباری اوقات حساب مشکل کر دیتے ہیں — جلد طے کریں کہ اہداف رات اور ہفتے کے آخر کو شمار کرتے ہیں یا نہیں۔
ضم کرنا اور ڈپلیکیٹس
ایک ہی مسئلہ تین بار رپورٹ ہونا عام ہے۔ “ٹکٹ # میں ضم کریں” کا عمل ایجنٹس کو ایک ہی بات بار بار لکھنے سے بچاتا ہے؛ اسے جلد بنانا فائدہ مند ہے۔
ایک کارآمد پہلا پرامپٹ
60 افراد کی کمپنی کے لیے ایک اندرونی IT ہیلپ ڈیسک بنائیں۔ ملازمین ایک فارم سے درخواست جمع کرتے ہیں: موضوع، زمرہ (hardware، software، access، network، other)، ترجیح (کم، عام، فوری)، تفصیل اور منسلکات۔ ہر ٹکٹ کو ایک نمبر ملے اور اسٹیٹسز new، open، waiting on requester، resolved، closed ہوں۔ IT ایجنٹس کو ایک قطار دکھے جس میں غیر تفویض شدہ، میرے، اور تمام کھلے کے ٹیبز ہوں، زمرے، ترجیح اور اسٹیٹس کے فلٹرز اور تلاش۔ ٹکٹ کا صفحہ سلسلہ دکھائے جس میں عوامی جوابات اور اندرونی نوٹس واضح طور پر الگ ہوں؛ ملازمین کبھی اندرونی نوٹس نہ دیکھیں۔ ایجنٹس تفویض، اسٹیٹس اور ترجیح بدل سکیں، تیار جوابات استعمال کر سکیں، اور ڈپلیکیٹس ضم کر سکیں۔ پہلے جواب اور حل ہونے کے اوقات ٹریک کریں اور ہر ٹکٹ پر آخری اپ ڈیٹ کے بعد کا وقت دکھائیں۔ ملازمین کے لیے “میری درخواستیں” کا صفحہ ہو۔ کردار: ملازم، ایجنٹ، ایڈمن۔ سب کچھ ایک ڈیٹا بیس میں محفوظ کریں۔ سادہ، گھنا اور تیز انٹرفیس — سجاوٹ سے زیادہ رفتار۔
تعمیر کے مراحل
- ٹکٹ ماڈل اور فارم۔ جمع کریں، فہرست بنائیں، ٹکٹ کھولیں، جواب دیں۔
- قطار اور فلٹرز۔ غیر تفویض شدہ، میرے، تمام کھلے؛ فلٹر اور تلاش؛ ترجیح اور عمر کے لحاظ سے ترتیب۔
- کردار اور لاگ ان۔ درخواست کنندہ، ایجنٹ، ایڈمن — نوٹس درخواست کنندگان سے سرور پر چھپے ہوں۔
- تفویض، اسٹیٹس اور ترجیح کے کنٹرولز، ہر تبدیلی کے سرگرمی لاگ کے ساتھ۔
- اطلاعات۔ عوامی جوابات پر درخواست کنندہ کو اور نئی تفویض پر ایجنٹ کو اپنے ای میل فراہم کنندہ کے ذریعے ای میل۔
- تیار جوابات اور ضم کرنا۔
- جوابی اہداف اور ایک بنیادی رپورٹ: عمر کے لحاظ سے کھلے ٹکٹس، پہلے جواب کا وقت، ہر زمرے کے ٹکٹس۔
- ای میل وصولی، باقی کام چلنے کے بعد، تھریڈنگ کی بھرپور جانچ کے ساتھ۔
- ایک ٹیم کے ساتھ دو ہفتے کا پائلٹ سب کو منتقل کرنے سے پہلے۔
عام غلطیاں
- اندرونی نوٹس درخواست کنندگان کو نظر آنا کیونکہ وہ صرف انٹرفیس میں چھپائے گئے تھے۔
- بہت زیادہ اسٹیٹسز اور زمرے۔ ایجنٹس وہ پہلا منتخب کرتے ہیں جو قریب لگے۔ ہر ایک میں زیادہ سے زیادہ پانچ سے شروع کریں۔
- پہلے جواب اور حل کے لیے ٹائم اسٹیمپس نہ ہونا۔ جس دن کوئی پوچھے “کیا ہم تیز ہو رہے ہیں؟” آپ کو وہ اعداد چاہئیں ہوں گے۔
- ای میل کے جوابات تھریڈ ہونے کے بجائے نئے ٹکٹ بنانا۔ فون کی میل ایپ سے جواب دے کر جانچیں، جو اکثر موضوع بدل دیتی ہے۔
- سب کو تفویض، کسی کی ذمہ داری نہیں۔ ہر ٹکٹ کا ایک تفویض شدہ شخص؛ باقیوں کے لیے واچرز استعمال کریں۔
- منسلکات کے عوامی URLs۔ خرابی کے پیغامات کے اسکرین شاٹس میں اکثر نجی ڈیٹا ہوتا ہے۔ فائلیں نجی رکھیں اور صرف انہی کو دیں جو ٹکٹ دیکھ سکتے ہیں۔
کب تیار پروڈکٹ بہتر انتخاب ہے
ای میل، چیٹ اور سوشل چینلز پر گاہکوں کی سپورٹ کے لیے — جوابی اہداف کا ٹریکنگ، اطمینان کے سروے، میکروز، رپورٹنگ اور انضمام کے ساتھ — مخصوص ہیلپ ڈیسک پروڈکٹ تقریباً ہمیشہ بہتر سرمایہ کاری ہے۔ ان پروڈکٹس نے ای میل تھریڈنگ، اسپیم، روٹنگ اور رپورٹنگ پر برسوں کام کیا ہے، اور یہ وہ حصہ نہیں جو آپ کے کاروبار کو منفرد بناتا ہے۔ ہمارا Zendesk کے متبادل گائیڈ آپشنز کا موازنہ کرتا ہے۔
کسٹم بلڈ اندرونی ڈیسکس (IT، HR، فیسیلیٹیز، مالی درخواستیں)، ایسے مخصوص ورک فلو جہاں ٹکٹ دراصل ایک مقررہ مراحل والا کام ہو، اور ان ٹیموں کے لیے موزوں ہے جو درخواستوں کو اپنے پہلے سے موجود دوسرے ڈیٹا سے جوڑنا چاہتی ہیں۔ یہ ان صورتوں میں فی ایجنٹ قیمت سے بھی بچاتا ہے جہاں بہت سے لوگ کبھی کبھار ٹکٹس سنبھالتے ہیں۔ زیادہ وسیع زمرے کے لیے اندرونی ٹول گائیڈ دیکھیں۔
Mythex کے ساتھ بنانا
Mythex پر آپ چیٹ میں ہیلپ ڈیسک بیان کرتے ہیں، لائیو پریویو میں جائزہ لیتے ہیں، اور اپنی ٹیم کے لیے شائع کرتے ہیں۔ ڈیٹا محفوظ کرنے کی ضرورت ہو تو ٹکٹس ایجنٹ کے شامل کردہ Postgres ڈیٹا بیس میں رہتے ہیں، اور منسلکات پروجیکٹ کی فائل اسٹوریج میں جاتے ہیں۔ درخواست کنندگان اور ایجنٹس کے لاگ ان، اور تمام ای میل اندر اور باہر، آپ کے اپنے فراہم کنندگان استعمال کرتے ہیں — Mythex میں اینڈ یوزر لاگ ان یا ای میل کی کوئی بلٹ ان پروڈکٹ نہیں ہے؛ ای میل بھیجنے کی ریسیپی اس طریقے کو دکھاتی ہے۔ ٹیم کے ساتھی مشترکہ ورک اسپیس کے ذریعے مدد کر سکتے ہیں، Mythex پر فی سیٹ فیس کے بغیر۔
ابتدائی پرامپٹ کے لیے اندرونی درخواست قطار یا بگ ٹریکر ٹیمپلیٹس آزمائیں، اور ہیلپ ڈیسک کو نالج بیس کے ساتھ جوڑیں تاکہ عام سوالات کے جواب خود ہو جائیں۔
سوالات
ٹکٹنگ سسٹم کے بنیادی فیچرز کیا ہیں؟
ٹکٹ بنانے کا طریقہ (فارم یا ای میل)، اسٹیٹس اور ترجیح کے ساتھ ایک مشترکہ قطار، کسی ایجنٹ کو تفویض، عوامی جوابات اور نجی نوٹس کے ساتھ گفتگو کا سلسلہ، اور تلاش۔ باقی سب — جوابی اہداف، تیار جوابات، رپورٹس — انہی پر کھڑا ہوتا ہے۔
کیا ایک کسٹم ہیلپ ڈیسک ای میل سے ٹکٹ وصول کر سکتا ہے؟
ہاں، لیکن اس کے لیے ایسا ای میل فراہم کنندہ درکار ہے جو میل وصول کر سکے اور ہر پیغام کو ویب ہُک کے ذریعے آپ کی ایپ کو بھیجے۔ جوابات میں ٹکٹ کا حوالہ ہونا چاہیے تاکہ وہ نئے ٹکٹ بنانے کے بجائے درست ٹکٹ سے جڑیں۔
کیا اندرونی IT یا HR ہیلپ ڈیسک بنایا جائے یا خریدا جائے؟
اندرونی درخواستوں کی ڈیسکس کسٹم بلڈ کے لیے موزوں ہیں: حجم متوقع ہوتا ہے، زمرے آپ کی کمپنی کے مخصوص ہوتے ہیں، اور آپ کنٹرول کرتے ہیں کون کیا دیکھے۔ بڑے پیمانے پر گاہکوں کی سپورٹ عموماً ایک مخصوص پروڈکٹ کا جواز رکھتی ہے۔
ٹکٹس کے کون سے اسٹیٹسز ہونے چاہئیں؟
مختصر رکھیں: نیا، کھلا، گاہک کا انتظار، حل شدہ اور بند زیادہ تر ٹیموں کے لیے کافی ہیں۔ “ہولڈ پر” صرف اس صورت میں شامل کریں جب آپ اکثر کسی تیسرے فریق کا انتظار کرتے ہوں۔ ہر اضافی اسٹیٹس ایک اور چیز ہے جسے ایجنٹ غلط طریقے سے سیٹ کرتے ہیں۔