ਹੈਲਪਡੈਸਕ & ਟਿਕਟ ਪ੍ਰਬੰਧਨ
ਰਿਕਾਰਡਿੰਗ ਉਸ ਟਿਕਟ ਉੱਤੇ ਅੰਦਰੂਨੀ ਨੋਟ ਬਣਦੀ ਹੈ ਜੋ ਏਜੰਟ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਖੁੱਲ੍ਹੀ ਹੈ — ਨਵਾਂ ਬਿਨਾਂ ਮੰਗਿਆ ਮਾਮਲਾ ਨਹੀਂ।
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 | ਅੰਦਰੂਨੀ ਐਪ ਦੀ ਕਲਾਇੰਟ ID ਅਤੇ ਕਲਾਇੰਟ ਸੀਕ੍ਰੇਟ | ਲੋੜ ਨਹੀਂ |
| Front | API ਟੋਕਨ ਅਤੇ ਟੀਮ ਮੈਂਬਰ ID | ਲੋੜ ਨਹੀਂ |
| Gorgias | ਏਜੰਟ ਈਮੇਲ ਅਤੇ API ਕੁੰਜੀ | ਲੋੜੀਂਦਾ |
Help Scout ਗੱਲ ਤੋਂ ਪਹਿਲਾਂ ਬਦਲਦਾ ਹੈ
ਕਲਾਇੰਟ ਸੀਕ੍ਰੇਟ ਸਿੱਧਾ ਨਹੀਂ ਮੰਨਦਾ। ਪੁਲ ਪਹਿਲਾਂ ਇਸ ਦੇ ਬਦਲੇ ਥੋੜ੍ਹੀ ਮਿਆਦ ਵਾਲਾ ਪਹੁੰਚ ਟੋਕਨ ਲੈਂਦਾ ਹੈ — client credentials ਪ੍ਰਵਾਹ, ਆਪਣੇ ਲਈ ਕੰਮ ਕਰਦੇ ਏਕੀਕਰਨ ਲਈ, ਵਰਤੋਂਕਾਰ ਲਈ ਨਹੀਂ। ਟੋਕਨ ਆਪਣੀ ਮਿਆਦ ਤੱਕ ਮੈਮੋਰੀ ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ; ਸੀਕ੍ਰੇਟ ਡਾਟਾਬੇਸ ਵਿੱਚ।
Front ਟਿੱਪਣੀਆਂ ਨੂੰ ਲੇਖਕ ਚਾਹੀਦਾ ਹੈ
Front ਦੀ ਟਿੱਪਣੀ ਟੀਮ ਮੈਂਬਰ ਦੇ ਨਾਮ ਉੱਤੇ ਆਉਂਦੀ ਹੈ ਅਤੇ API ਨੂੰ ਇੱਕ ਚਾਹੀਦਾ ਹੈ। ਇੱਥੇ ਏਜੰਟ ਲਈ ਲੇਬਲ ਵਾਲਾ ਖੇਤਰ ਇਹੀ ਰੱਖਦਾ ਹੈ — ਲੌਗ ਇਨ ਨਹੀਂ, ਸਿਰਫ਼ ਉਹ ID ਜਿਸ ਦਾ ਨਾਮ ਨੋਟ ਉੱਤੇ ਹੈ।
Gorgias ਨੂੰ ਇੱਕ ਦੀ ਥਾਂ ਦੋ ਸਵਾਲ ਚਾਹੀਦੇ ਹਨ
ਉਸ ਦੀ ਟਿਕਟ ਸੂਚੀ ਇਸ ਨਾਲ ਫਿਲਟਰ ਕਰਦੀ ਹੈ: customer_id ਅਤੇ ਹੋਰ ਕਿਸੇ ਨਾਲ ਨਹੀਂ — ਈਮੇਲ ਫਿਲਟਰ ਨਹੀਂ ਹੈ। ਇਸ ਲਈ ਪੁਲ ਪਹਿਲਾਂ ਗਾਹਕ ਲੱਭਦਾ ਹੈ ਅਤੇ ਫਿਰ ਟਿਕਟਾਂ ਮੰਗਦਾ ਹੈ। ਸਥਿਤੀ ਨਾਲ ਵੀ ਫਿਲਟਰ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਇਸ ਲਈ ਖੁੱਲ੍ਹੀ ਟਿਕਟ ਸਾਡੇ ਪਾਸੇ ਚੁਣੀ ਜਾਂਦੀ ਹੈ, Freshdesk ਵਾਂਗ।
ਇੱਥੇ ਦੱਸੇ ਸਾਰੇ ਟ੍ਰੇਡਮਾਰਕ ਆਪਣੇ ਮਾਲਕਾਂ ਦੇ ਹਨ। MousePlayer ਦਾ ਇਨ੍ਹਾਂ ਪ੍ਰਦਾਤਾਵਾਂ ਨਾਲ ਕੋਈ ਵਪਾਰਕ ਸੰਬੰਧ ਨਹੀਂ ਹੈ।