ಹೆಲ್ಪ್‌ಡೆಸ್ಕ್ ಮತ್ತು ಟಿಕೆಟ್ ನಿರ್ವಹಣೆ

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(), ನಮ್ಮ ವಿಶ್ಲೇಷಣಾ ಬ್ರಿಡ್ಜ್ ವಿಶಿಷ್ಟ ID ಮತ್ತೆ ಓದಿದಾಗ ಅಥವಾ ನಿಮ್ಮ ಸರ್ವರ್ identify ಎಂಡ್‌ಪಾಯಿಂಟ್ ಕರೆದಾಗ.

ಇಮೇಲ್ ವಿಳಾಸದೊಂದಿಗೆ ಮಾತ್ರ

ಟಿಕೆಟ್ ಕಳುಹಿಸಿದವರಿಗೆ ಸೇರಿದೆ; ಹೆಲ್ಪ್‌ಡೆಸ್ಕ್ ಅವರನ್ನು ಇಮೇಲ್ ಮೂಲಕ ಗುರುತಿಸುತ್ತದೆ. ಒಪ್ಪಂದದ ಸಂಖ್ಯೆ ಅಲ್ಲಿ ಫಲ ನೀಡುವುದಿಲ್ಲ; ಆದ್ದರಿಂದ ಯಾವುದನ್ನೂ ಕಳುಹಿಸುವುದಿಲ್ಲ.

ತೆರೆದ ಟಿಕೆಟ್‌ಗಳಿಗೆ ಮಾತ್ರ

ಪರಿಹರಿಸಿದ ಮತ್ತು ಮುಚ್ಚಿದ ಟಿಕೆಟ್‌ಗಳನ್ನು ಬಿಡಲಾಗುತ್ತದೆ. ಯಾರೂ ಇನ್ನು ನೋಡದ ಪ್ರಕರಣದ ಟಿಪ್ಪಣಿ ಯಾರಿಗೂ ಉಪಯೋಗವಿಲ್ಲ; ಕಾರಣವಿಲ್ಲದೆ ಮುಚ್ಚಿದ ಟಿಕೆಟ್ ಮತ್ತೆ ಏಜೆಂಟ್‌ಗಳ ಗಮನಕ್ಕೆ ಬರುತ್ತದೆ.

ಕಳುಹಿಸಿದವರಿಗೆ ತೆರೆದ ಟಿಕೆಟ್ ಇಲ್ಲದಿದ್ದರೆ ವಿಫಲತೆಯಲ್ಲ, ಮುಗಿದಿದೆ ಎಂದು ಎಣಿಕೆ — ಅದು ಸಾಮಾನ್ಯ; ಮತ್ತೆ ಪ್ರಯತ್ನಿಸಿದರೂ ಬದಲಾಗುವುದಿಲ್ಲ.

4. ಏಜೆಂಟ್ ನೋಡುವುದು

ಒಂದು ಆಂತರಿಕ ಟಿಪ್ಪಣಿ: MousePlayer: <email> ಇಂದ ಸೆಷನ್ ರೆಕಾರ್ಡಿಂಗ್ ನಂತರ ಲಿಂಕ್. ಒಂದೇ ಕ್ಲಿಕ್‌ನಲ್ಲಿ ಆ ವ್ಯಕ್ತಿ ಬರೆದದ್ದರ ಪಕ್ಕದಲ್ಲೇ ಅವರು ನಿಜವಾಗಿ ಮಾಡಿದ್ದನ್ನು ವೀಕ್ಷಿಸುತ್ತಾರೆ.

ಹೆಚ್ಚು ಪ್ರಯೋಜನ ಸಿಗುವ ಸಂದರ್ಭಗಳು

“ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ” ಟಿಕೆಟ್‌ಗಳು. ಮೂರು ಸುತ್ತಿನ ಇಮೇಲ್‌ಗಳು ತಿಳಿಸಲಾಗದಿದ್ದನ್ನು ರೆಕಾರ್ಡಿಂಗ್ ಸಾಮಾನ್ಯವಾಗಿ ಇಪ್ಪತ್ತು ಸೆಕೆಂಡುಗಳಲ್ಲಿ ತೋರಿಸುತ್ತದೆ.
ಯಾರಿಂದಲೂ ಮರುಸೃಷ್ಟಿಸಲಾಗದ ಮರುಸೃಷ್ಟಿ ಹಂತಗಳು. ಅವು ಇನ್ನು ಬೇಕಿಲ್ಲ — ನಿಮ್ಮ ಬಳಿ ಸೆಷನ್ ಇದೆ.
ಕೋಪದ ಕ್ಲಿಕ್‌ಗಳು ಮತ್ತು ಫಲವಿಲ್ಲದ ಕ್ಲಿಕ್‌ಗಳು ಉತ್ಪನ್ನ ಹೀಗೆಯೇ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂದು ಭಾವಿಸಿ ಗ್ರಾಹಕರು ಎಂದಿಗೂ ಹೇಳದ ವಿಷಯಗಳು.

ಟೋಕನ್ ನಮ್ಮ ಸರ್ವರ್‌ನಿಂದ ಎಂದಿಗೂ ಹೊರಹೋಗುವುದಿಲ್ಲ

AES-256-GCM ಎನ್‌ಕ್ರಿಪ್ಷನ್‌ನೊಂದಿಗೆ ಸಂಗ್ರಹಿಸಿ ಉಳಿಸಿದ ನಂತರ ಮತ್ತೆ ತೋರಿಸುವುದಿಲ್ಲ; ಕೆಲಸ ಹೊತ್ತೊಯ್ಯುವ ಆಂತರಿಕ ಸರದಿಯಿಂದ ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಹೊರಗಿಡಲಾಗುತ್ತದೆ.

5. Help Scout, Front ಮತ್ತು Gorgias

ಇನ್ನೂ ಮೂರು ಹೆಲ್ಪ್‌ಡೆಸ್ಕ್‌ಗಳು. ಮೂರೂ ತೆರೆದ ಸಂಭಾಷಣೆಗೆ ಆಂತರಿಕ ಟಿಪ್ಪಣಿ ಸೇರಿಸುತ್ತವೆ; ತಲುಪುವ ವಿಧಾನಗಳು ವಿಭಿನ್ನ.

	ನೀವು ನೀಡುವುದು	ಉಪಡೊಮೇನ್
Help Scout	ಆಂತರಿಕ ಆ್ಯಪ್‌ನ ಕ್ಲೈಂಟ್ ID ಮತ್ತು ಕ್ಲೈಂಟ್ ಸೀಕ್ರೆಟ್	ಅಗತ್ಯವಿಲ್ಲ
Front	API ಟೋಕನ್ ಮತ್ತು ಸಹೋದ್ಯೋಗಿ ID	ಅಗತ್ಯವಿಲ್ಲ
Gorgias	ಏಜೆಂಟ್ ಇಮೇಲ್ ಮತ್ತು API ಕೀ	ಅಗತ್ಯ

Help Scout ಮಾತನಾಡುವ ಮೊದಲು ವಿನಿಮಯ ಮಾಡುತ್ತದೆ

ಕ್ಲೈಂಟ್ ಸೀಕ್ರೆಟ್ ಅನ್ನು ನೇರವಾಗಿ ಸ್ವೀಕರಿಸುವುದಿಲ್ಲ. ಮೊದಲು ಬ್ರಿಡ್ಜ್ ಅದನ್ನು ಅಲ್ಪಾವಧಿಯ ಆಕ್ಸೆಸ್ ಟೋಕನ್‌ಗೆ ವಿನಿಮಯ ಮಾಡುತ್ತದೆ — ಬಳಕೆದಾರರ ಪರವಾಗಲ್ಲದೆ ತನ್ನದೇ ಪರವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಏಕೀಕರಣದ ಕ್ಲೈಂಟ್ ಕ್ರೆಡೆನ್ಷಿಯಲ್ಸ್ ಕ್ರಮ. ಟೋಕನ್ ಅದರ ಅವಧಿಯವರೆಗೆ ಮೆಮೊರಿಯಲ್ಲಿ ಇರುತ್ತದೆ; ಸೀಕ್ರೆಟ್ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಉಳಿಯುತ್ತದೆ.

Front ಕಾಮೆಂಟ್‌ಗಳಿಗೆ ಲೇಖಕರು ಬೇಕು

Front ನಲ್ಲಿ ಕಾಮೆಂಟ್ ಸಹೋದ್ಯೋಗಿಯ ಹೆಸರಿನಲ್ಲಿ ಕಾಣುತ್ತದೆ; API ಗೆ ಅದು ಅಗತ್ಯ. ಇಲ್ಲಿ ಏಜೆಂಟ್ ಎಂದು ಲೇಬಲ್ ಮಾಡಿದ ಫೀಲ್ಡ್ ಅದನ್ನೇ ಹೊಂದಿದೆ — ಲಾಗಿನ್ ಅಲ್ಲ, ಟಿಪ್ಪಣಿಯಲ್ಲಿ ಯಾರ ಹೆಸರು ಬರಬೇಕೋ ಅವರ ID ಮಾತ್ರ.

Gorgias ಗೆ ಒಂದರ ಬದಲಿಗೆ ಎರಡು ಪ್ರಶ್ನೆಗಳು ಬೇಕು

ಅದರ ಟಿಕೆಟ್ ಪಟ್ಟಿಯು ಈ ಆಧಾರದಲ್ಲಿ ಮಾತ್ರ ಫಿಲ್ಟರ್ ಮಾಡುತ್ತದೆ: customer_id ; ಇಮೇಲ್ ಫಿಲ್ಟರ್ ಇಲ್ಲ. ಆದ್ದರಿಂದ ಬ್ರಿಡ್ಜ್ ಮೊದಲು ಗ್ರಾಹಕರನ್ನು ಹುಡುಕಿ ನಂತರ ಅವರ ಟಿಕೆಟ್ ಕೇಳುತ್ತದೆ. ಸ್ಥಿತಿಯಿಂದಲೂ ಫಿಲ್ಟರ್ ಮಾಡಲಾಗುವುದಿಲ್ಲ; ಹೀಗಾಗಿ Freshdesk ಗೆ ಮಾಡುವಂತೆಯೇ ತೆರೆದ ಟಿಕೆಟ್ ನಮ್ಮ ಕಡೆ ಆಯ್ಕೆಮಾಡಲಾಗುತ್ತದೆ.

ಇಲ್ಲಿ ಉಲ್ಲೇಖಿಸಿದ ಎಲ್ಲ ಟ್ರೇಡ್‌ಮಾರ್ಕ್‌ಗಳು ಅವುಗಳ ಮಾಲೀಕರಿಗೆ ಸೇರಿವೆ. MousePlayer ಈ ಪೂರೈಕೆದಾರರೊಂದಿಗೆ ವ್ಯಾಪಾರ ಸಂಬಂಧ ಹೊಂದಿಲ್ಲ.

ನಾವು ಹೇಗೆ ಸಹಾಯ ಮಾಡಬಹುದು?