ହେଲ୍ପଡେସ୍କ୍ & ଟିକେଟ୍ ପରିଚାଳନା
ରେକର୍ଡିଂ ଆପଣଙ୍କ କର୍ମୀ ପୂର୍ବରୁ ଖୋଲିଥିବା ଟିକେଟ୍ରେ ଆଭ୍ୟନ୍ତରୀଣ ଟିପ୍ପଣୀ ଭାବେ ପହଞ୍ଚେ - କେହି ମାଗିନଥିବା ନୂଆ ମାମଲା ଭାବେ ନୁହେଁ।
1. ଏହି ବୈଶିଷ୍ଟ୍ୟ ପ୍ରଥମେ ଉତ୍ତର ଦେବାକୁ ପଡ଼ିଥିବା ପ୍ରଶ୍ନ
କେଉଁ ଟିକେଟ୍?
ପ୍ରତି ଚିହ୍ନଟ ସେସନ୍ ପାଇଁ ଟିକେଟ୍ ସୃଷ୍ଟି କଲେ ଅନାବଶ୍ୟକ ଭିଡ଼ ହେବ: ସହାୟତା ଦଳ କେହି ଖୋଲିନଥିବା ମାମଲା ପାଇବ। ସେହି ବ୍ୟକ୍ତିଙ୍କ ସମସ୍ତ ପୁରୁଣା ଟିକେଟ୍ରେ ଟିପ୍ପଣୀ ଯୋଡ଼ିବା ମଧ୍ୟ ସେହିପରି, କେବଳ ଧୀର।
ତେଣୁ: ପ୍ରେରକଙ୍କ ସବୁଠାରୁ ନୂଆ ଖୋଲା ଟିକେଟ୍ରେ ଆଭ୍ୟନ୍ତରୀଣ ଟିପ୍ପଣୀ। ଖୋଲା ଟିକେଟ୍ ନଥିଲେ କିଛି ହୁଏ ନାହିଁ। ତେଣୁ ଗ୍ରାହକ ଆରମ୍ଭ କରିନଥିବା ମାମଲା କେବେ ସୃଷ୍ଟି କରୁନାହୁଁ, ଆଉ କର୍ମୀ ଯେଉଁଠି ଦେଖୁଛନ୍ତି ଠିକ୍ ସେଠାରେ ରେକର୍ଡିଂ ପାଆନ୍ତି।
ଆଭ୍ୟନ୍ତରୀଣ, କେବେ ସାର୍ବଜନୀନ ନୁହେଁ। ଲିଙ୍କ୍ MousePlayer କୁ ନେଏ। ଗ୍ରାହକ ତାହା ଦେଖିବା ଉଚିତ ନୁହେଁ, ଆଉ ଯାଇପାରିବେ ମଧ୍ୟ ନାହିଁ।
2. Zendesk Support ଓ Freshdesk
ଉଭୟ ସମର୍ଥିତ ଓ ସମାନ କାମ ଭିନ୍ନ ଭାବେ କରନ୍ତି। ଆପଣଙ୍କୁ ସେଥିପାଇଁ ଚିନ୍ତା ନାହିଁ - କିନ୍ତୁ ଫର୍ମ କାହିଁକି କିଛି ଭିନ୍ନ ତଥ୍ୟ ମାଗେ ବୁଝାଏ।
| Zendesk Support | Freshdesk | |
|---|---|---|
| ସବଡୋମେନ୍ | acme acme.zendesk.com ରୁ | acme acme.freshdesk.com ରୁ |
| କର୍ମୀଙ୍କ ଇମେଲ୍ | ଦରକାର - Zendesk ଏହିଭଳି ସାଇନ୍ ଇନ୍ କରେ: email/token | ଦରକାର ନାହିଁ, ଖାଲି ରଖନ୍ତୁ |
| API ଟୋକେନ୍ | Admin Center → Apps and integrations → APIs | ଆପଣଙ୍କ ପ୍ରୋଫାଇଲ୍ ସେଟିଂସ୍ |
| ଟିପ୍ପଣୀ ହୁଏ | ଟିକେଟ୍ରେ ଆଭ୍ୟନ୍ତରୀଣ ମନ୍ତବ୍ୟ | ଟିକେଟ୍ରେ ବ୍ୟକ୍ତିଗତ ଟିପ୍ପଣୀ |
ସହଜ ଲାଗିଲେ ସବଡୋମେନ୍ ଫିଲ୍ଡରେ ସମ୍ପୂର୍ଣ୍ଣ URL ଲଗାନ୍ତୁ - ଆମେ ଦରକାର ଅଂଶ ରଖୁ, ତେଣୁ https://acme.zendesk.com/agent/tickets/1 ଏଥିରେ ବଦଳେ: acme।
3. କେବେ ଚାଲେ
ସେସନ୍ ଚିହ୍ନଟ ମୁହୂର୍ତ୍ତରେ - ସାଇଟ୍ ଏହା ଡାକିଲେ MousePlayer.setUserId(), ବିଶ୍ଳେଷଣ ବ୍ରିଜ୍ distinct ID ପଢ଼ିଲେ କିମ୍ବା ସର୍ଭର୍ identify ଏଣ୍ଡପଏଣ୍ଟ୍ ଡାକିଲେ।
କେବଳ ଇମେଲ୍ ଠିକଣା ସହ
ଟିକେଟ୍ ପ୍ରେରକଙ୍କର, ଆଉ ହେଲ୍ପଡେସ୍କ୍ ତାଙ୍କୁ ଇମେଲ୍ରେ ଚିହ୍ନେ। ଚୁକ୍ତି ସଂଖ୍ୟା ସେଠାରେ ମେଳେ ନାହିଁ, ତେଣୁ କିଛି ପଠାଯାଏ ନାହିଁ।
କେବଳ ଖୋଲା ଟିକେଟ୍ ପାଇଁ
ସମାଧାନ ଓ ବନ୍ଦ ଟିକେଟ୍ ଛାଡ଼ିଦିଆଯାଏ। କେହି ଆଉ ଦେଖୁନଥିବା ମାମଲାରେ ଟିପ୍ପଣୀ କାହାକୁ ସାହାଯ୍ୟ କରେ ନାହିଁ, ଆଉ ବିନା କାରଣରେ ବନ୍ଦ ଟିକେଟ୍ କର୍ମୀଙ୍କ ଦୃଷ୍ଟିକୁ ଫେରାଇବ।
ପ୍ରେରକଙ୍କ ଖୋଲା ଟିକେଟ୍ ନଥିଲେ ଏହା ବିଫଳ ବଦଳରେ ସମାପ୍ତ ଗଣାଯାଏ - ଏହା ସାଧାରଣ କଥା, ପୁଣି ଚେଷ୍ଟା କଲେ କିଛି ବଦଳିବ ନାହିଁ।
4. କର୍ମୀ କଣ ଦେଖନ୍ତି
ଗୋଟିଏ ଆଭ୍ୟନ୍ତରୀଣ ଟିପ୍ପଣୀ: MousePlayer: <email> ଙ୍କ ସେସନ୍ ରେକର୍ଡିଂ ତାପରେ ଲିଙ୍କ୍। ଗୋଟିଏ କ୍ଲିକ୍ରେ ବ୍ୟକ୍ତି ଯାହା ଲେଖିଲେ ତାହା ପାଖରେ ପ୍ରକୃତରେ କଣ କଲେ ଦେଖୁଛନ୍ତି।
କେଉଁଠି ଏହାର ମୂଲ୍ୟ ଅଛି
- “କାମ କରୁନାହିଁ” ଟିକେଟ୍। ତିନି ଥର ଇମେଲ୍ରେ ଯାହା ଜଣାପଡ଼େ ନାହିଁ, ରେକର୍ଡିଂ ସାଧାରଣତଃ କୋଡ଼ିଏ ସେକେଣ୍ଡ୍ରେ ଦେଖାଏ।
- କେହି ପୁଣି କରିପାରୁନଥିବା ପଦକ୍ଷେପ। ଆଉ ତାହା ଦରକାର ନାହିଁ - ସେସନ୍ ଆପଣଙ୍କ ପାଖରେ ଅଛି।
- କ୍ରୋଧପୂର୍ଣ୍ଣ କ୍ଲିକ୍ ଓ ପ୍ରତିକ୍ରିୟାହୀନ କ୍ଲିକ୍ ଯାହା ଗ୍ରାହକ କେବେ କହନ୍ତି ନାହିଁ, କାରଣ ଉତ୍ପାଦ ଏମିତି କାମ କରେ ବୋଲି ଭାବନ୍ତି।
ଟୋକେନ୍ କେବେ ଆମ ସର୍ଭର୍ ବାହାରକୁ ଯାଏ ନାହିଁ
AES-256-GCM ଏନକ୍ରିପ୍ଟ୍ ଭାବେ ରଖାଯାଏ, ସେଭ୍ ପରେ ପୁଣି ଦେଖାଯାଏ ନାହିଁ ଓ କାମ ଥିବା ଆଭ୍ୟନ୍ତରୀଣ ଧାଡ଼ିରୁ ଜାଣିଶୁଣି ବାହାରେ ରହେ।
5. Help Scout, Front ଓ Gorgias
ଆଉ ତିନିଟି ହେଲ୍ପଡେସ୍କ୍। ତିନୋଟି ଖୋଲା କଥାବାର୍ତ୍ତାରେ ଆଭ୍ୟନ୍ତରୀଣ ଟିପ୍ପଣୀ ଯୋଡ଼ନ୍ତି ଓ ତିନୋଟି ଭିନ୍ନ ଉପାୟରେ ତାହା କରନ୍ତି।
| ଆପଣ ଦିଅନ୍ତି | ସବଡୋମେନ୍ | |
|---|---|---|
| Help Scout | ଆଭ୍ୟନ୍ତରୀଣ ଆପ୍ର client ID ଓ client secret | ଦରକାର ନାହିଁ |
| Front | API ଟୋକେନ୍ ଓ teammate ID | ଦରକାର ନାହିଁ |
| Gorgias | କର୍ମୀଙ୍କ ଇମେଲ୍ ଓ API ଚାବି | ଦରକାର |
Help Scout କଥା ହେବା ପୂର୍ବରୁ ବିନିମୟ କରେ
client secret ସିଧା ଗ୍ରହଣ କରେ ନାହିଁ। ବ୍ରିଜ୍ ପ୍ରଥମେ ତାହାକୁ ସ୍ୱଳ୍ପକାଳୀନ access token ରେ ବଦଳାଏ - ଏହା client credentials flow, ବ୍ୟବହାରକାରୀ ପରିବର୍ତ୍ତେ ନିଜ ପାଇଁ କାମ କରୁଥିବା ସମନ୍ୱୟ ପାଇଁ। ଟୋକେନ୍ ତାହାର ଅବଧି ପାଇଁ ମେମୋରିରେ ରହେ; secret ଡାଟାବେସ୍ରେ ରହେ।
Front ମନ୍ତବ୍ୟରେ ଲେଖକ ଦରକାର
Front ରେ ମନ୍ତବ୍ୟ ଜଣେ ସହକର୍ମୀଙ୍କ ନାମରେ ଦେଖାଯାଏ, ଆଉ API ତାହା ମାଗେ। କର୍ମୀ ପାଇଁ ଚିହ୍ନିତ ଫିଲ୍ଡରେ ସେହି ତଥ୍ୟ ରହେ - ଲଗଇନ୍ ନୁହେଁ, କେବଳ ଯାହାଙ୍କ ନାମରେ ଟିପ୍ପଣୀ ରହିବ ସେହି ID।
Gorgias କୁ ଗୋଟିଏ ପରିବର୍ତ୍ତେ ଦୁଇଟି ପ୍ରଶ୍ନ ଦରକାର
ତାହାର ଟିକେଟ୍ ତାଲିକା କେବଳ ଏହାରେ ଫିଲ୍ଟର୍ କରେ: customer_id ଅନ୍ୟ କିଛିରେ ନୁହେଁ - ଇମେଲ୍ ଫିଲ୍ଟର୍ ନାହିଁ। ତେଣୁ ବ୍ରିଜ୍ ପ୍ରଥମେ ଗ୍ରାହକ ଖୋଜେ, ତାପରେ ତାଙ୍କ ଟିକେଟ୍ ମାଗେ। ସ୍ଥିତି ଅନୁସାରେ ମଧ୍ୟ ଫିଲ୍ଟର୍ କରିପାରେ ନାହିଁ, ତେଣୁ Freshdesk ପରି ଆମ ପଟେ ଖୋଲା ଟିକେଟ୍ ବାଛାଯାଏ।
ଏଠାରେ ଥିବା ସମସ୍ତ ଟ୍ରେଡ୍ମାର୍କ୍ ସେମାନଙ୍କ ସମ୍ବନ୍ଧିତ ମାଲିକଙ୍କର। ଏହି ପ୍ରଦାନକାରୀଙ୍କ ସହ MousePlayer ର କୌଣସି ବ୍ୟବସାୟିକ ସମ୍ପର୍କ ନାହିଁ।