Helpdesk & ລະບົບ ticket
ການບັນທຶກຈະຢູ່ເປັນບັນທຶກຂໍ້ຄວາມພາຍໃນໃນ ticket ທີ່ພະນັກງານເປີດຢູ່ແລ້ວ - ບໍ່ແມ່ນກໍລະນີໃໝ່ທີ່ບໍ່ມີໃຜຮ້ອງຂໍ.
1. ຄຳຖາມທີ່ຄຸນສົມບັດນີ້ຕ້ອງຕອບກ່ອນ
ticket ໃດ?
ການສ້າງ ticket ສຳລັບທຸກເຊດຊັນທີ່ລະບຸແລ້ວຈະເປັນສະແປມ: ທີມຊ່ວຍເຫຼືອຈະພົບກໍລະນີທີ່ບໍ່ມີໃຜເປີດ. ການເພີ່ມບັນທຶກຂໍ້ຄວາມໃນທຸກ ticket ທີ່ຄົນນັ້ນເຄີຍຂຽນກໍເປັນສະແປມ ແຕ່ຊ້າກວ່າ.
ດັ່ງນັ້ນ: ບັນທຶກຂໍ້ຄວາມພາຍໃນໃນ ticket ທີ່ຍັງເປີດແລະໃໝ່ສຸດຂອງຜູ້ສົ່ງ. ຖ້າບໍ່ມີ ticket ເປີດ ຈະບໍ່ເກີດຫຍັງເລີຍ. ດັ່ງນັ້ນຈະບໍ່ສ້າງກໍລະນີທີ່ລູກຄ້າບໍ່ໄດ້ເລີ່ມ ແລະ ພະນັກງານຈະພົບການບັນທຶກໃນບ່ອນທີ່ກຳລັງເບິ່ງຢູ່ແລ້ວ.
ພາຍໃນ, ບໍ່ເຄີຍສາທາລະນະ. ລິ້ງນຳໄປ MousePlayer. ລູກຄ້າບໍ່ຄວນເຫັນມັນ ແລະ ເຖິງເຫັນກໍຕິດຕາມລິ້ງບໍ່ໄດ້.
2. Zendesk Support ແລະ Freshdesk
ຮອງຮັບທັງສອງ ແລະ ແກ້ວຽກດຽວກັນດ້ວຍວິທີຕ່າງກັນ. ທ່ານບໍ່ຕ້ອງໃສ່ໃຈສ່ວນນັ້ນ - ແຕ່ມັນອະທິບາຍວ່າເປັນຫຍັງຟອມຈຶ່ງຖາມສິ່ງທີ່ຕ່າງກັນເລັກນ້ອຍ.
| Zendesk Support | Freshdesk | |
|---|---|---|
| ໂດເມນຍ່ອຍ | acme ຈາກ acme.zendesk.com | acme ຈາກ acme.freshdesk.com |
| ອີເມວພະນັກງານ | ຕ້ອງໃຊ້ - Zendesk ເຂົ້າລະບົບເປັນ email/token | ບໍ່ຕ້ອງໃຊ້, ປະໄວ້ວ່າງ |
| API token | Admin Center → Apps and integrations → APIs | ການຕັ້ງຄ່າໂປຣໄຟລ໌ |
| ບັນທຶກຂໍ້ຄວາມຈະເປັນ | ຄຳເຫັນພາຍໃນໃນ ticket | ບັນທຶກຂໍ້ຄວາມສ່ວນຕົວໃນ ticket |
ວາງ URL ທັງໝົດໃນຊ່ອງໂດເມນຍ່ອຍກໍໄດ້ຖ້າງ່າຍກວ່າ - ພວກເຮົາຕັດໃຫ້ເຫຼືອສ່ວນທີ່ຕ້ອງການ ດັ່ງນັ້ນ https://acme.zendesk.com/agent/tickets/1 ຈະເປັນ acme.
3. ເມື່ອໃດທີ່ເຮັດວຽກ
ໃນເວລາທີ່ເຊດຊັນຖືກລະບຸ - ເມື່ອເວັບໄຊເອີ້ນ MousePlayer.setUserId(), ເມື່ອຂົວເຊື່ອມວິເຄາະອ່ານ distinct ID ກັບມາ ຫຼື ເມື່ອເຊີບເວີຂອງທ່ານເອີ້ນ identify endpoint.
ສະເພາະມີອີເມວ
ticket ເປັນຂອງຜູ້ສົ່ງ ແລະ helpdesk ຮູ້ຈັກຜູ້ສົ່ງດ້ວຍອີເມວ. ເລກສັນຍາຈະບໍ່ນຳໄປໃສ ຈຶ່ງບໍ່ສົ່ງຫຍັງ.
ສະເພາະ ticket ທີ່ຍັງເປີດ
ຂ້າມ ticket ທີ່ແກ້ໄຂແລ້ວແລະປິດແລ້ວ. ບັນທຶກຂໍ້ຄວາມໃນກໍລະນີທີ່ບໍ່ມີໃຜເບິ່ງອີກບໍ່ຊ່ວຍໃຜ ແລະ ຈະດຶງ ticket ທີ່ປິດແລ້ວກັບມາໃຫ້ພະນັກງານເຫັນໂດຍບໍ່ມີເຫດຜົນ.
ຖ້າຜູ້ສົ່ງບໍ່ມີ ticket ເປີດ ຈະນັບວ່າສຳເລັດ ບໍ່ແມ່ນລົ້ມເຫຼວ - ເປັນກໍລະນີປົກກະຕິ ແລະ ລອງໃໝ່ກໍບໍ່ປ່ຽນຫຍັງ.
4. ສິ່ງທີ່ພະນັກງານເຫັນ
ໜຶ່ງບັນທຶກຂໍ້ຄວາມພາຍໃນ: MousePlayer: ການບັນທຶກເຊດຊັນຈາກ <email> ຕາມດ້ວຍລິ້ງ. ຄລິກດຽວກໍເບິ່ງສິ່ງທີ່ຄົນນັ້ນເຮັດຈິງ ຄຽງກັບສິ່ງທີ່ເຂົາຂຽນກ່ຽວກັບມັນ.
ບ່ອນທີ່ສິ່ງນີ້ມີປະໂຫຍດ
- ticket ແບບ “ໃຊ້ບໍ່ໄດ້”. ການບັນທຶກມັກສະແດງໃນຊາວວິນາທີເຖິງສິ່ງທີ່ອີເມວສາມຮອບບອກບໍ່ໄດ້.
- ຂັ້ນຕອນສ້າງບັນຫາຄືນທີ່ບໍ່ມີໃຜເຮັດໄດ້. ບໍ່ຈຳເປັນຕ້ອງໃຊ້ມັນອີກ - ທ່ານມີເຊດຊັນແລ້ວ.
- ການຄລິກດ້ວຍຄວາມຫງຸດຫງິດແລະການຄລິກທີ່ບໍ່ຕອບສະໜອງ ທີ່ລູກຄ້າບໍ່ເຄີຍກ່າວເຖິງ ເພາະຄິດວ່າຜະລິດຕະພັນເຮັດວຽກແບບນັ້ນ.
token ບໍ່ອອກຈາກເຊີບເວີເດັດຂາດ
ເກັບແບບເຂົ້າລະຫັດ AES-256-GCM, ບໍ່ສະແດງອີກຫຼັງບັນທຶກ ແລະ ຕັ້ງໃຈບໍ່ໃສ່ໃນຄິວພາຍໃນທີ່ສົ່ງວຽກ.
5. Help Scout, Front ແລະ Gorgias
ອີກສາມ helpdesk. ທັງສາມເພີ່ມບັນທຶກຂໍ້ຄວາມພາຍໃນໃນການສົນທະນາທີ່ເປີດ ແລະ ທັງສາມເຮັດດ້ວຍວິທີຕ່າງກັນ.
| ທ່ານລະບຸ | ໂດເມນຍ່ອຍ | |
|---|---|---|
| Help Scout | client ID ແລະ client secret ຂອງແອັບພາຍໃນ | ບໍ່ຕ້ອງໃຊ້ |
| Front | API token ແລະ ID ສະມາຊິກທີມ | ບໍ່ຕ້ອງໃຊ້ |
| Gorgias | ອີເມວພະນັກງານ ແລະ ກະແຈ API | ຕ້ອງໃຊ້ |
Help Scout ແລກກ່ອນເລີ່ມສື່ສານ
ມັນບໍ່ຮັບ client secret ໂດຍກົງ. ຂົວເຊື່ອມຈະແລກເປັນ access token ອາຍຸສັ້ນກ່ອນ - ເປັນ client credentials flow ສຳລັບການເຊື່ອມຕໍ່ທີ່ດຳເນີນການເພື່ອຕົນເອງ ແທນຜູ້ໃຊ້. token ຢູ່ໃນໜ່ວຍຄວາມຈຳຕາມອາຍຸຂອງມັນ; secret ຢູ່ໃນຖານຂໍ້ມູນ.
ຄຳເຫັນ Front ຕ້ອງມີຜູ້ຂຽນ
ຄຳເຫັນໃນ Front ປາກົດໃນນາມສະມາຊິກທີມ ແລະ API ບັງຄັບໃຫ້ລະບຸ. ນັ້ນຄືຄ່າໃນຊ່ອງທີ່ລະບຸວ່າພະນັກງານໃນທີ່ນີ້ - ບໍ່ແມ່ນການເຂົ້າລະບົບ, ພຽງ ID ທີ່ບັນທຶກຂໍ້ຄວາມໃຊ້ຊື່ຂອງມັນ.
Gorgias ຕ້ອງຖາມສອງຄັ້ງແທນໜຶ່ງ
ລາຍການ ticket ຂອງມັນກອງດ້ວຍ customer_id ເທົ່ານັ້ນ - ບໍ່ມີຕົວກອງອີເມວ. ດັ່ງນັ້ນຂົວເຊື່ອມຊອກຫາລູກຄ້າກ່ອນ ແລ້ວຂໍ ticket ຂອງເຂົາເປັນຂັ້ນທີສອງ. ມັນຍັງກອງຕາມສະຖານະບໍ່ໄດ້ ຈຶ່ງເລືອກ ticket ເປີດຝັ່ງພວກເຮົາ ຄືກັບທີ່ເຮັດສຳລັບ Freshdesk ຢູ່ແລ້ວ.
ເຄື່ອງໝາຍການຄ້າທັງໝົດທີ່ລະບຸໃນທີ່ນີ້ເປັນຂອງເຈົ້າຂອງແຕ່ລະລາຍ. MousePlayer ບໍ່ມີຄວາມສຳພັນທາງທຸລະກິດກັບຜູ້ໃຫ້ບໍລິການເຫຼົ່ານີ້.