ਬੇਨਤੀ ਸੰਖੇਪ ਅਤੇ ਵਰਗੀਕਰਨ (ਟਿਕਟ ਟ੍ਰਾਈਜ)

ਲਾਭ:

• ਲੰਬੇ ਅਤੇ ਖਿੰਡੇ ਹੋਏ ਗਾਹਕਾਂ ਦੀਆਂ ਬੇਨਤੀਆਂ ਨੂੰ ਢਾਂਚਾਗਤ, ਕਾਰਵਾਈਯੋਗ ਸਾਰਾਂਸ਼ਾਂ ਵਿੱਚ ਬਦਲਣ ਦੀ ਸਮਰੱਥਾ
• ਇੱਕ ਨਿਸ਼ਚਤ ਸਕੀਮਾ ਦੇ ਨਾਲ ਸ਼੍ਰੇਣੀ, ਜ਼ਰੂਰੀਤਾ ਅਤੇ ਗਾਹਕ ਭਾਵਨਾ ਦੇ ਅਨੁਸਾਰ ਬੇਨਤੀਆਂ ਨੂੰ ਸ਼੍ਰੇਣੀਬੱਧ ਕਰਨ ਦੀ ਸਮਰੱਥਾ
• ਬਲਕ ਟਿਕਟ ਪ੍ਰੋਸੈਸਿੰਗ ਲਈ ਆਟੋਮੇਸ਼ਨ ਲਈ ਅਨੁਕੂਲ ਇਕਸਾਰ ਆਉਟਪੁੱਟ ਫਾਰਮੈਟ (JSON/ਸਾਰਣੀ) ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨ ਦੀ ਸਮਰੱਥਾ

ਇੱਕ ਸਹਾਇਤਾ ਟੀਮ ਦੀ ਸਵੇਰ ਦੀ ਕਲਪਨਾ ਕਰੋ: ਰਾਤੋ-ਰਾਤ 220 ਨਵੀਆਂ ਟਿਕਟਾਂ (ਟਿਕਟਾਂ) ਇਕੱਠੀਆਂ ਹੋ ਗਈਆਂ ਹਨ। ਕੁਝ ਇੱਕ-ਲਾਈਨ ਹਨ "ਮੈਂ ਆਪਣਾ ਪਾਸਵਰਡ ਭੁੱਲ ਗਿਆ ਹਾਂ", ਕੁਝ ਇੱਕ ਗੁੱਸੇ ਵਿੱਚ ਤਿੰਨ-ਪੈਰਾ ਦੀ ਸ਼ਿਕਾਇਤ ਹਨ, ਅਤੇ ਕੁਝ ਅਸਲ ਵਿੱਚ ਇੱਕ ਵਿਕਰੀ ਦਾ ਮੌਕਾ ਹਨ। ਇਸ ਪਾਇਲ ਨੂੰ ਪੜ੍ਹਨਾ, ਹਰ ਇੱਕ ਨੂੰ ਸਹੀ ਸ਼੍ਰੇਣੀ ਵਿੱਚ ਨਿਰਧਾਰਤ ਕਰਨਾ, ਇਸਦੀ ਜ਼ਰੂਰੀਤਾ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰਨਾ, ਅਤੇ ਇਸਨੂੰ ਸਹੀ ਵਿਅਕਤੀ ਤੱਕ ਪਹੁੰਚਾਉਣਾ (ਇਸ ਨੂੰ ਟ੍ਰਾਈਜ ਕਿਹਾ ਜਾਂਦਾ ਹੈ; ਐਮਰਜੈਂਸੀ ਰੂਮ ਵਿੱਚ ਮਰੀਜ਼ਾਂ ਨੂੰ ਤਰਜੀਹ ਦੇ ਕੇ ਛਾਂਟਣ ਦਾ ਉਹੀ ਤਰਕ) ਦਿਨ ਦੇ ਪਹਿਲੇ ਦੋ ਘੰਟੇ ਖਾ ਜਾਂਦਾ ਹੈ।

ਆਰਟੀਫੀਸ਼ੀਅਲ ਇੰਟੈਲੀਜੈਂਸ (AI) ਇਹ ਕੰਮ ਸਕਿੰਟਾਂ ਵਿੱਚ ਅਤੇ ਲਗਾਤਾਰ ਕਰ ਸਕਦੀ ਹੈ। ਪਰ ਜਾਦੂ "ਇਸ ਬੇਨਤੀ ਨੂੰ ਸੰਖੇਪ ਕਰੋ" ਕਹਿਣ ਵਿੱਚ ਨਹੀਂ ਹੈ; ਇਹ ਸ਼੍ਰੇਣੀਆਂ ਦੀ ਇੱਕ ਨਿਸ਼ਚਿਤ ਸੂਚੀ, ਸਪੱਸ਼ਟ ਜ਼ਰੂਰੀ ਪੱਧਰ, ਅਤੇ ਮਾਡਲ 'ਤੇ ਇੱਕ ਅਟੱਲ ਆਉਟਪੁੱਟ ਫਾਰਮੈਟ ਲਾਗੂ ਕਰਦਾ ਹੈ। ਇਸ ਯੂਨਿਟ ਵਿੱਚ, ਅਸੀਂ ਇੱਕ ਟ੍ਰਾਈਜ ਸਿਸਟਮ ਸਥਾਪਤ ਕਰਾਂਗੇ ਜੋ ਇੱਕ ਸਿੰਗਲ ਬੇਨਤੀ ਨੂੰ ਪ੍ਰੋਸੈਸ ਕਰਨ ਤੋਂ ਲੈ ਕੇ ਸਵੈਚਾਲਨ-ਤਿਆਰ ਤਰੀਕੇ ਨਾਲ ਸੈਂਕੜੇ ਬੇਨਤੀਆਂ ਨੂੰ ਲੇਬਲ ਕਰਨ ਤੱਕ ਜਾਂਦਾ ਹੈ।

ਨੋਟ: ਏਆਈ ਦੁਆਰਾ ਤਿਆਰ ਕੀਤੀ ਗਈ ਸ਼੍ਰੇਣੀ ਅਤੇ ਜ਼ਰੂਰੀ ਲੇਬਲ ਇੱਕ ਸ਼ੁਰੂਆਤੀ ਸਕ੍ਰੀਨਿੰਗ ਟੂਲ ਹਨ। ਖਾਸ ਤੌਰ 'ਤੇ, "ਜ਼ਰੂਰੀ" ਅਤੇ "ਸ਼ਿਕਾਇਤ" ਲੇਬਲ ਵਾਲੀਆਂ ਬੇਨਤੀਆਂ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕੀਤੇ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਮਨੁੱਖ ਦੁਆਰਾ ਪੁਸ਼ਟੀ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ।

ਸਟ੍ਰਕਚਰਡ ਸੰਖੇਪ ਕਿਉਂ?

ਇੱਕ ਮੁਫਤ ਸਾਰਾਂਸ਼ ("ਗਾਹਕ ਨੂੰ ਉਹਨਾਂ ਦੇ ਮਾਲ ਵਿੱਚ ਸਮੱਸਿਆਵਾਂ ਆ ਰਹੀਆਂ ਹਨ") ਨੂੰ ਖੋਜਿਆ, ਛਾਂਟਿਆ ਜਾਂ ਸਵੈਚਲਿਤ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਹਾਲਾਂਕਿ, ਸਹਾਇਤਾ ਪ੍ਰਬੰਧਕ ਦੀ ਲੋੜ ਹੇਠਾਂ ਦਿੱਤੇ ਸਵਾਲਾਂ ਲਈ ਸਪੱਸ਼ਟ ਹੈ:

• ਇਹ ਬੇਨਤੀ ਕਿਸ ਸ਼੍ਰੇਣੀ ਵਿੱਚ ਆਉਂਦੀ ਹੈ? (ਸ਼ਿਪਿੰਗ, ਵਾਪਸੀ, ਭੁਗਤਾਨ, ਤਕਨੀਕੀ, ਉਤਪਾਦ ਜਾਣਕਾਰੀ, ਸ਼ਿਕਾਇਤ, ਵਿਕਰੀ ਦੇ ਮੌਕੇ)
• ਇਹ ਕਿੰਨੀ ਜ਼ਰੂਰੀ ਹੈ? (ਨਾਜ਼ੁਕ / ਉੱਚ / ਮੱਧਮ / ਘੱਟ)
• ਗਾਹਕ ਦੀ ਭਾਵਨਾਤਮਕ ਸਥਿਤੀ ਕੀ ਹੈ? (ਗੁੱਸੇ / ਨਿਰਾਸ਼ / ਨਿਰਪੱਖ / ਸੰਤੁਸ਼ਟ)
• ਇਸ ਦਾ ਇਕ-ਵਾਕ ਦਾ ਸਾਰ ਕੀ ਹੈ?
• ਅਗਲਾ ਕਦਮ ਕੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ?

ਇੱਕ ਵਾਰ ਜਦੋਂ ਤੁਸੀਂ ਇਹਨਾਂ ਪ੍ਰਸ਼ਨਾਂ ਨੂੰ ਪਹਿਲਾਂ ਤੋਂ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦੇ ਹੋ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਮਾਡਲ ਨੂੰ ਇੱਕ ਸਕੀਮਾ (ਸਥਿਰ ਖੇਤਰ ਅਤੇ ਸੰਭਾਵੀ ਮੁੱਲਾਂ) ਦੇ ਰੂਪ ਵਿੱਚ ਦਿੰਦੇ ਹੋ, ਤਾਂ ਸਾਰੀਆਂ 220 ਬੇਨਤੀਆਂ ਇੱਕੋ ਫਾਰਮੈਟ ਵਿੱਚ ਤੁਲਨਾਤਮਕ ਅਤੇ ਫਿਲਟਰ ਕਰਨ ਯੋਗ ਬਣ ਜਾਂਦੀਆਂ ਹਨ।

ਕਦਮ-ਦਰ-ਕਦਮ: ਟ੍ਰਾਈਜ ਸਕੀਮ ਦੀ ਸਥਾਪਨਾ

1. ਸ਼੍ਰੇਣੀ ਸੂਚੀ ਨੂੰ ਪਿੰਨ ਕਰੋ। ਮਾਡਲ ਨੂੰ ਫਿੱਟ ਨਾ ਹੋਣ ਦਿਓ; ਇੱਕ ਬੰਦ ਸੂਚੀ ਦਿਓ.
2. ਜ਼ਰੂਰੀਤਾ ਦੇ ਮਾਪਦੰਡ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ। ਠੋਸ "ਨਾਜ਼ੁਕ" ਦਾ ਕੀ ਅਰਥ ਹੈ: ਸੇਵਾ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬੰਦ ਹੋ ਗਈ, ਭੁਗਤਾਨ ਦਾ ਨੁਕਸਾਨ, ਸੁਰੱਖਿਆ ਜੋਖਮ।
3. ਭਾਵਨਾ ਲੇਬਲ ਦੀ ਪਛਾਣ ਕਰੋ. ਇੱਕ ਸੀਮਤ ਅਤੇ ਸਪਸ਼ਟ ਸੈੱਟ ਦੀ ਵਰਤੋਂ ਕਰੋ।
4. ਆਉਟਪੁੱਟ ਫਾਰਮੈਟ ਨੂੰ ਆਯਾਤ ਕਰੋ. ਬੈਚ ਪ੍ਰੋਸੈਸਿੰਗ ਲਈ, JSON (ਮਸ਼ੀਨ-ਰੀਡ ਡੇਟਾ ਫਾਰਮੈਟ ਜਿਸ ਵਿੱਚ ਫੀਲਡ-ਵੈਲਯੂ ਜੋੜੇ ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ) ਢੁਕਵਾਂ ਹੈ, ਸਿੰਗਲ ਬੇਨਤੀ ਲਈ, ਸਾਰਣੀ ਢੁਕਵੀਂ ਹੈ।
5. ਇੱਕ "ਟਿਕ ਜੇ ਪੱਕਾ ਨਹੀਂ" ਨਿਯਮ ਬਣਾਓ। ਜੇ ਮਾਡਲ ਸ਼੍ਰੇਣੀ ਬਾਰੇ ਅਨਿਸ਼ਚਿਤ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਅਨਿਸ਼ਚਿਤ ਕਹੋ ਅਤੇ ਮਨੁੱਖ ਦਿਖਾਈ ਦੇਵੇਗਾ।
6. ਪੁਸ਼ਟੀ ਕਰੋ। ਪਹਿਲੇ ਬੈਚ ਵਿੱਚ, ਹੱਥੀਂ ਲੇਬਲਾਂ ਦੀ ਸ਼ੁੱਧਤਾ ਦੀ ਜਾਂਚ ਕਰੋ ਅਤੇ ਪ੍ਰੋਂਪਟ ਸੈਟ ਕਰੋ।

ਕਾਪੀ ਕਰਨ ਯੋਗ ਉਤਪ੍ਰੇਰਕ

ਬੁਨਿਆਦੀ ਪ੍ਰੋਂਪਟ ਜੋ ਇੱਕ ਸਿੰਗਲ ਬੇਨਤੀ ਨੂੰ ਇੱਕ ਸਟ੍ਰਕਚਰਡ ਸਾਰਾਂਸ਼ ਵਿੱਚ ਬਦਲਦਾ ਹੈ:

ਭੂਮਿਕਾ: ਤੁਸੀਂ ਇੱਕ ਤਜਰਬੇਕਾਰ ਸਹਾਇਤਾ ਟ੍ਰਾਈਜ ਸਪੈਸ਼ਲਿਸਟ ਹੋ। ਹੇਠਾਂ ਗਾਹਕ ਦੀ ਬੇਨਤੀ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰੋ। ਇੱਕ ਟਿੱਪਣੀ ਸ਼ਾਮਲ ਕਰੋ; ਸਿਰਫ਼ ਟੈਕਸਟ ਵਿੱਚ ਕੀ ਹੈ ਉਸ 'ਤੇ ਭਰੋਸਾ ਕਰੋ। ਹੇਠਾਂ ਦਿੱਤੇ ਖੇਤਰਾਂ ਨੂੰ ਭਰੋ:- ਸੰਖੇਪ: (ਵੱਧ ਤੋਂ ਵੱਧ 1 ਵਾਕ)- ਸ਼੍ਰੇਣੀ: [ਸ਼ਿਪਿੰਗ | ਵਾਪਸੀ | ਭੁਗਤਾਨ | ਤਕਨੀਕੀ | ਉਤਪਾਦ ਜਾਣਕਾਰੀ | ਸ਼ਿਕਾਇਤ | ਵਿਕਰੀ ਦੇ ਮੌਕੇ] - ਜ਼ਰੂਰੀ: [ਨਾਜ਼ੁਕ | ਉੱਚਾ | ਦਰਮਿਆਨਾ | ਘੱਟ] - ਭਾਵਨਾ: [ਗੁੱਸੇ | ਨਿਰਾਸ਼ਾ | ਨਿਰਪੱਖ | ਸੰਤੁਸ਼ਟ]- ਅਗਲਾ_ਕਦਮ: (ਇਕ ਵਾਕ, ਠੋਸ ਕਾਰਵਾਈ)- ਅਨਿਸ਼ਚਿਤ: ("ਹਾਂ" ਜੇਕਰ ਸ਼੍ਰੇਣੀ/ਜ਼ਰੂਰੀ ਅਸਪਸ਼ਟ ਹੈ, ਨਹੀਂ ਤਾਂ "ਨਹੀਂ") ਬੇਨਤੀ:"""{{ request_text }}"""

ਬੈਚ ਪ੍ਰੋਸੈਸਿੰਗ ਲਈ, ਪ੍ਰੋਂਪਟ ਕਈ ਬੇਨਤੀਆਂ ਨੂੰ ਇੱਕ ਵਾਰ ਵਿੱਚ JSON ਐਰੇ ਵਿੱਚ ਬਦਲਦਾ ਹੈ:

ਹੇਠਾਂ ਦਿੱਤੇ ਨੰਬਰ ਵਾਲੀਆਂ ਬੇਨਤੀਆਂ 'ਤੇ ਕਾਰਵਾਈ ਕਰੋ। ਹੇਠਾਂ ਦਿੱਤੀ ਸਕੀਮਾ ਨਾਲ ਹਰੇਕ ਲਈ ਇੱਕ JSON ਵਸਤੂ ਤਿਆਰ ਕਰੋ ਅਤੇ ਉਹਨਾਂ ਸਾਰਿਆਂ ਨੂੰ JSON ਐਰੇ ਵਜੋਂ ਵਾਪਸ ਕਰੋ। ਸਕੀਮ ਤੋਂ ਬਾਹਰ ਜਾਣਾ: { "id": "", "ਸਾਰਾਂਸ਼": "", "ਸ਼੍ਰੇਣੀ": "", "ਜ਼ਰੂਰੀ": "", "ਭਾਵਨਾ": "", "next_step": "", "ਮੈਨੂੰ ਯਕੀਨ ਨਹੀਂ ਹੈ": "" }ਸਿਰਫ਼ ਸ਼੍ਰੇਣੀਆਂ: ਸ਼ਿਪਿੰਗ, ਵਾਪਸੀ, ਭੁਗਤਾਨ, ਤਕਨੀਕੀ, ਉਤਪਾਦ ਜਾਣਕਾਰੀ, ਸ਼ਿਕਾਇਤ, ਵਿਕਰੀ ਮੌਕੇ। ਬੇਨਤੀਆਂ: {{ numbered_request_list }}

ਪ੍ਰੋਂਪਟ ਜੋ ਜ਼ਰੂਰੀ ਮਾਪਦੰਡ ਨੂੰ ਸਪੱਸ਼ਟ ਕਰਦਾ ਹੈ ਅਤੇ ਮਾਡਲ ਨੂੰ "ਨਾਜ਼ੁਕ" ਦੀ ਪਰਿਭਾਸ਼ਾ ਸਿਖਾਉਂਦਾ ਹੈ:

ਨਿਮਨਲਿਖਤ ਨਿਯਮ ਦੇ ਅਨੁਸਾਰ ਜ਼ਰੂਰੀਤਾ ਦਾ ਪਤਾ ਲਗਾਓ: - ਨਾਜ਼ੁਕ: ਸੇਵਾ ਪੂਰੀ ਤਰ੍ਹਾਂ ਅਣਉਪਲਬਧ, ਭੁਗਤਾਨ ਦਾ ਨੁਕਸਾਨ, ਸੁਰੱਖਿਆ/ਡਾਟਾ ਜੋਖਮ, ਕਾਨੂੰਨੀ ਖਤਰਾ।- ਉੱਚ: ਮਹੱਤਵਪੂਰਨ ਫੰਕਸ਼ਨ ਟੁੱਟ ਗਿਆ ਹੈ ਪਰ ਹੱਲ ਮੌਜੂਦ ਹੈ; ਨਾਰਾਜ਼ ਗਾਹਕ।- ਮਾਧਿਅਮ: ਇਕਵਚਨ ਮੁੱਦਾ, ਕੰਮ ਦੇ ਪ੍ਰਵਾਹ ਨੂੰ ਨਹੀਂ ਰੋਕ ਰਿਹਾ।- ਘੱਟ: ਜਾਣਕਾਰੀ ਲਈ ਬੇਨਤੀ, ਸੁਝਾਅ, ਆਮ ਸਵਾਲ। ਆਪਣੇ ਫੈਸਲੇ ਦਾ ਕਾਰਨ "ਜ਼ਰੂਰੀ_ਕਾਰਨ" ਖੇਤਰ ਵਿੱਚ ਇੱਕ ਵਾਕ ਵਿੱਚ ਲਿਖੋ।

ਪ੍ਰੋਂਪਟ ਜੋ ਵਿਕਰੀ ਦੇ ਮੌਕੇ ਨੂੰ ਹਾਸਲ ਕਰਦਾ ਹੈ ਅਤੇ ਇੱਕ ਸਹਾਇਤਾ/ਵਿਕਰੀ ਬ੍ਰਿਜ ਸਥਾਪਤ ਕਰਦਾ ਹੈ:

ਬੇਨਤੀ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰਦੇ ਸਮੇਂ, ਜੇਕਰ ਗਾਹਕ ਇੱਕ ਨਵਾਂ ਉਤਪਾਦ/ਪੈਕੇਜ/ਪੂਰਕ ਖਰੀਦਣ ਵਿੱਚ ਦਿਲਚਸਪੀ ਦਿਖਾਉਂਦਾ ਹੈ (ਉਦਾਹਰਨ ਲਈ, "ਕੀ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਵੱਡਾ ਪੈਕੇਜ ਹੈ", "ਕਿੰਨੇ ਉਪਭੋਗਤਾ ਇਸ ਨੂੰ ਲੈਂਦੇ ਹਨ"), ਸ਼੍ਰੇਣੀ "ਵਿਕਰੀ ਦੇ ਮੌਕੇ" ਬਣਾਓ ਅਤੇ "ਸੇਲ_ਨੋਟ" ਖੇਤਰ ਵਿੱਚ ਵਿਕਰੀ ਟੀਮ ਲਈ ਇੱਕ-ਵਾਕ ਦੀ ਟਿਪ ਸ਼ਾਮਲ ਕਰੋ।

ਕਮਜ਼ੋਰ ਪ੍ਰੋਂਪਟ / ਮਜ਼ਬੂਤ ਪ੍ਰੋਂਪਟ

ਕਮਜ਼ੋਰ ਪ੍ਰੋਂਪਟ

ਸ਼ਕਤੀਸ਼ਾਲੀ ਪ੍ਰਾਉਟ

"ਇਸ ਬੇਨਤੀ ਨੂੰ ਸੰਖੇਪ ਅਤੇ ਸ਼੍ਰੇਣੀਬੱਧ ਕਰੋ"

ਬੰਦ ਸ਼੍ਰੇਣੀ ਸੂਚੀ + ਜ਼ਰੂਰੀ ਪਰਿਭਾਸ਼ਾ + ਸਥਿਰ JSON ਸਕੀਮਾ

ਹਰ ਵਾਰ ਵੱਖ-ਵੱਖ ਲੇਬਲ ਤਿਆਰ ਕਰਦਾ ਹੈ

ਇੱਕੋ ਬੇਨਤੀ ਨੂੰ ਹਮੇਸ਼ਾ ਉਹੀ ਲੇਬਲ ਦਿੰਦਾ ਹੈ

ਉਹ ਆਪਣੀ ਇੱਛਾ ਅਨੁਸਾਰ "ਜ਼ਰੂਰੀ" ਸ਼ਬਦ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ।

"ਨਾਜ਼ੁਕ" ਲਈ ਠੋਸ ਮਾਪਦੰਡ ਲਾਗੂ ਕਰਦਾ ਹੈ

ਉਹ ਅਸਪਸ਼ਟ ਬਣਾਉਂਦਾ ਹੈ

emin_degilim: ਹਾਂ ਕਹੋ ਅਤੇ ਵਿਅਕਤੀ ਨੂੰ ਛੱਡ ਦਿਓ

ਇਕਸਾਰਤਾ ਇੱਥੇ ਸੁਨਹਿਰੀ ਨਿਯਮ ਹੈ: ਜੇਕਰ ਉਹੀ ਸ਼ਿਕਾਇਤ ਦੋ ਵੱਖ-ਵੱਖ ਦਿਨਾਂ 'ਤੇ ਇੱਕੋ ਸ਼੍ਰੇਣੀ ਵਿੱਚ ਨਹੀਂ ਆਉਂਦੀ, ਤਾਂ ਕੋਈ ਰਿਪੋਰਟਿੰਗ ਅਤੇ ਆਟੋਮੇਸ਼ਨ ਭਰੋਸੇਯੋਗ ਨਹੀਂ ਹੋਵੇਗੀ।

ਤਿੰਨ ਮਿੰਨੀ ਕੇਸ

ਕੇਸ 1 - ਗੁਪਤ ਆਲੋਚਕ। ਇੱਕ SaaS (ਇੰਟਰਨੈਟ ਕਿਰਾਏ 'ਤੇ ਸੌਫਟਵੇਅਰ) ਕੰਪਨੀ ਵਿੱਚ, ਸੁਨੇਹਾ "ਮੈਂ ਲੌਗਇਨ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਪੂਰੀ ਟੀਮ 40 ਲੋਕਾਂ ਦੀ ਉਡੀਕ ਕਰ ਰਹੀ ਹੈ" ਆਮ ਜਾਪਦਾ ਸੀ ਕਿਉਂਕਿ ਇਹ ਲੰਬਾਈ ਵਿੱਚ ਛੋਟਾ ਸੀ। ਟ੍ਰਾਈਜ ਪ੍ਰੋਂਪਟ ਨੇ ਇਸ ਨੂੰ "ਨਾਜ਼ੁਕ" ਵਜੋਂ ਚਿੰਨ੍ਹਿਤ ਕੀਤਾ ਹੈ, ਜ਼ਰੂਰੀ ਨਿਯਮ ("ਸੇਵਾ ਪੂਰੀ ਤਰ੍ਹਾਂ ਅਣਉਪਲਬਧ" ਮਾਪਦੰਡ) ਲਈ ਧੰਨਵਾਦ। ਬੇਨਤੀ ਨੂੰ ਕਤਾਰ ਵਿੱਚ 2 ਘੰਟੇ ਉਡੀਕ ਕਰਨ ਦੀ ਬਜਾਏ 6 ਮਿੰਟਾਂ ਵਿੱਚ ਨਿਪਟਾਇਆ ਗਿਆ ਸੀ; ਇੱਕ SLA (ਸੇਵਾ ਪੱਧਰ ਦਾ ਸਮਝੌਤਾ, ਭਾਵ ਵਾਅਦਾ ਕੀਤਾ ਜਵਾਬ ਸਮਾਂ) ਦੀ ਉਲੰਘਣਾ ਨੂੰ ਰੋਕਿਆ ਗਿਆ ਹੈ।

ਕੇਸ 2 - ਗੁੱਸੇ ਦੀ ਤਰਜੀਹ। ਇੱਕ ਦਿਨ, ਜਦੋਂ 180 ਬੇਨਤੀਆਂ ਦੇ ਏਆਈ ਟੈਗਸ ਦੀ ਜਾਂਚ ਕੀਤੀ ਗਈ, ਤਾਂ ਇਹ ਦੇਖਿਆ ਗਿਆ ਕਿ "ਨਰਾਜ਼" ਭਾਵਨਾ ਨਾਲ 14 ਬੇਨਤੀਆਂ ਨੂੰ ਇੱਕ ਵੱਖਰੀ ਕਤਾਰ ਵਿੱਚ ਰੱਖਿਆ ਗਿਆ ਸੀ। ਇਹ ਬੇਨਤੀਆਂ ਤਜਰਬੇਕਾਰ ਨੁਮਾਇੰਦਿਆਂ ਨੂੰ ਨਿਰਦੇਸ਼ਿਤ ਕੀਤੀਆਂ ਗਈਆਂ ਸਨ, ਅਤੇ ਉਸ ਹਫ਼ਤੇ ਨਕਾਰਾਤਮਕ ਸਰਵੇਖਣ ਸਕੋਰ (CSAT, ਭਾਵ ਗਾਹਕ ਸੰਤੁਸ਼ਟੀ ਸਕੋਰ) ਵਿੱਚ ਪਿਛਲੇ ਹਫ਼ਤੇ ਦੇ ਮੁਕਾਬਲੇ ਕਾਫ਼ੀ ਸੁਧਾਰ ਹੋਇਆ ਹੈ।

ਕੇਸ 3 - ਸਮਰਥਨ ਤੋਂ ਵਿਕਰੀ ਤੱਕ ਦਾ ਪੁਲ। "ਮੇਰਾ ਮੌਜੂਦਾ ਪੈਕੇਜ 5 ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਹੈ, ਮੈਨੂੰ ਇਸਨੂੰ 20 ਲੋਕਾਂ ਤੱਕ ਵਧਾਉਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ, ਕੀ ਇਹ ਸੰਭਵ ਹੈ?" AI ਨੇ ਸੰਦੇਸ਼ ਨੂੰ "ਵਿਕਰੀ ਦੇ ਮੌਕੇ" ਵਜੋਂ ਟੈਗ ਕੀਤਾ ਅਤੇ ਇੱਕ ਵਿਕਰੀ ਨੋਟ ਜੋੜਿਆ। ਬੇਨਤੀ ਆਟੋਮੈਟਿਕ ਹੀ ਵਿਕਰੀ ਟੀਮ ਨੂੰ ਡਿੱਗ ਗਈ; ਇੱਕ ਅਪਸੈਲ ਮੌਕਾ ਜੋ ਕਿਸੇ ਦਾ ਧਿਆਨ ਨਹੀਂ ਗਿਆ ਹੁੰਦਾ ਜੇਕਰ ਇਹ ਮਿਆਰੀ ਸਹਾਇਤਾ ਕਤਾਰ ਵਿੱਚ ਗੁਆਚ ਗਿਆ ਹੁੰਦਾ ਤਾਂ ਇੱਕ ਲਾਭ ਬਣ ਗਿਆ ਹੈ।

ਸੁਝਾਅ: ਆਪਣੀ ਸ਼੍ਰੇਣੀ ਸੂਚੀ ਨੂੰ ਜਿੰਨਾ ਸੰਭਵ ਹੋ ਸਕੇ ਛੋਟਾ ਅਤੇ ਵੱਖਰਾ ਰੱਖੋ। 20 ਸ਼੍ਰੇਣੀਆਂ ਮਾਡਲ (ਅਤੇ ਤੁਹਾਡੀ ਟੀਮ) ਨੂੰ ਉਲਝਾਉਣਗੀਆਂ; 6-8 ਸਪਸ਼ਟ ਸ਼੍ਰੇਣੀਆਂ ਨੂੰ ਵਧੇਰੇ ਲਗਾਤਾਰ ਲੇਬਲ ਕੀਤਾ ਗਿਆ ਹੈ ਅਤੇ ਰਿਪੋਰਟਾਂ ਵਿੱਚ ਅਰਥਪੂਰਨ ਹਨ। ਦੋ ਅਕਸਰ ਉਲਝਣ ਵਾਲੀਆਂ ਸ਼੍ਰੇਣੀਆਂ ਨੂੰ ਜੋੜੋ।

ਆਟੋਮੇਸ਼ਨ ਨਾਲ ਜੁੜ ਰਿਹਾ ਹੈ

ਸਟ੍ਰਕਚਰਡ JSON ਆਉਟਪੁੱਟ ਦੀ ਅਸਲ ਸ਼ਕਤੀ ਇਹ ਹੈ ਕਿ ਇਹ ਅਗਲੇ ਪੜਾਅ 'ਤੇ ਆਟੋਮੈਟਿਕਲੀ ਵਹਿ ਜਾਂਦੀ ਹੈ: "ਨਾਜ਼ੁਕ" ਲੇਬਲ ਵਾਲੀ ਬੇਨਤੀ ਤੁਰੰਤ ਮੈਨੇਜਰ ਨੂੰ ਸੂਚਿਤ ਕਰਦੀ ਹੈ, "ਵਿਕਰੀ ਦੇ ਮੌਕੇ" CRM (ਗਾਹਕ ਸਬੰਧ ਪ੍ਰਬੰਧਨ ਸੌਫਟਵੇਅਰ) ਵਿੱਚ ਆਉਂਦੇ ਹਨ, "ਵਾਪਸੀ" ਸਵੈ-ਸੇਵਾ ਪ੍ਰਵਾਹ ਵਿੱਚ ਜਾਂਦੀ ਹੈ। ਪਰ ਆਟੋਮੇਸ਼ਨ ਦਾ ਪਹਿਲਾ ਨਿਯਮ: ਉੱਚ-ਪ੍ਰਭਾਵ ਵਾਲੀਆਂ ਕਾਰਵਾਈਆਂ (ਰਿਫੰਡ, ਖਾਤਾ ਬੰਦ ਕਰਨਾ) ਕਦੇ ਵੀ ਇਕੱਲੇ ਏਆਈ ਟੈਗ ਦੇ ਅਧਾਰ 'ਤੇ ਸ਼ੁਰੂ ਨਹੀਂ ਹੁੰਦੇ ਹਨ; ਕਈ ਵਾਰ ਮਨੁੱਖੀ ਪ੍ਰਵਾਨਗੀ ਹੁੰਦੀ ਹੈ।

ਸਾਵਧਾਨ: ਭਾਵਨਾ ਵਿਸ਼ਲੇਸ਼ਣ ਇੱਕ ਪੂਰਵ-ਅਨੁਮਾਨ ਹੈ, ਇੱਕ ਸਹੀ ਮਾਪ ਨਹੀਂ। ਇੱਕ ਗਾਹਕ ਜਿਸਨੂੰ ਮਾਡਲ "ਨਿਰਪੱਖ" ਕਹਿੰਦਾ ਹੈ ਅਸਲ ਵਿੱਚ ਚੁੱਪਚਾਪ ਬਹੁਤ ਗੁੱਸੇ ਹੋ ਸਕਦਾ ਹੈ. ਤਰਜੀਹ ਦੇਣ ਲਈ ਭਾਵਨਾ ਟੈਗ ਦੀ ਵਰਤੋਂ ਕਰੋ; ਪਰ "ਇਹ ਗਾਹਕ ਪਹਿਲਾਂ ਹੀ ਸੰਤੁਸ਼ਟ ਹੈ" ਵਰਗੇ ਨਿਸ਼ਚਿਤ ਸਿੱਟੇ ਕੱਢਣ ਲਈ ਇਕੱਲੇ ਇਸ 'ਤੇ ਭਰੋਸਾ ਨਾ ਕਰੋ।

ਆਮ ਗਲਤੀਆਂ

• ਸ਼੍ਰੇਣੀ ਸੂਚੀ ਨੂੰ ਮਾਡਲ ਨੂੰ ਛੱਡਣਾ; ਹਰ ਵਾਰ ਵੱਖਰੇ, ਅਸੰਗਤ ਲੇਬਲ ਪ੍ਰਾਪਤ ਕਰਨਾ।
• "ਜ਼ਰੂਰੀ" ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਨਾ ਕਰਨ ਵਰਗੇ ਇੱਕ ਰਿਸ਼ਤੇਦਾਰ ਸ਼ਬਦ ਨੂੰ ਛੱਡਣਾ; ਸਾਰਿਆਂ ਨੂੰ ਬੇਨਤੀ ਹੈ।
• ਆਉਟਪੁੱਟ ਫਾਰਮੈਟ ਨੂੰ ਠੀਕ ਨਹੀਂ ਕਰਨਾ; ਕਈ ਵਾਰ ਪੈਰਾਗ੍ਰਾਫ, ਕਈ ਵਾਰ JSON ਦੀ ਬਜਾਏ ਸੂਚੀ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ।
• ਅਨਿਸ਼ਚਿਤਤਾ ਲਈ ਬਾਹਰ ਜਾਣ ਦਾ ਦਰਵਾਜ਼ਾ ਮੁਹੱਈਆ ਨਹੀਂ ਕਰ ਰਿਹਾ (ਮੈਨੂੰ ਯਕੀਨ ਨਹੀਂ ਹੈ)।
• ਮਨੁੱਖੀ ਪ੍ਰਵਾਨਗੀ ਤੋਂ ਬਿਨਾਂ ਉੱਚ-ਪ੍ਰਭਾਵ ਵਾਲੇ ਲੈਣ-ਦੇਣ (ਰਿਫੰਡ, ਖਾਤਾ ਬੰਦ) ਨੂੰ AI ਟੈਗ ਨਾਲ ਲਿੰਕ ਕਰਨਾ।
• ਪਹਿਲੇ ਬੈਚ ਦੀ ਦਸਤੀ ਤਸਦੀਕ ਕੀਤੇ ਬਿਨਾਂ ਪੂਰੇ ਪ੍ਰਵਾਹ ਨੂੰ ਸਵੈਚਲਿਤ ਕਰਨਾ।

ਸੰਖੇਪ ਵਿੱਚ

• ਟ੍ਰਾਈਜ ਆਉਣ ਵਾਲੀਆਂ ਬੇਨਤੀਆਂ ਦੇ ਢੇਰ ਨੂੰ ਸ਼੍ਰੇਣੀ, ਜ਼ਰੂਰੀਤਾ ਅਤੇ ਭਾਵਨਾ ਦੁਆਰਾ ਤੇਜ਼ੀ ਨਾਲ ਛਾਂਟ ਰਿਹਾ ਹੈ।
• ਇਕਸਾਰਤਾ ਦੀ ਕੁੰਜੀ: ਬੰਦ ਸ਼੍ਰੇਣੀ ਸੂਚੀ, ਠੋਸ ਜ਼ਰੂਰੀ ਪਰਿਭਾਸ਼ਾ, ਅਤੇ ਸਥਿਰ ਆਉਟਪੁੱਟ ਫਾਰਮੈਟ (JSON)।
• ਜ਼ਰੂਰੀ ਅਤੇ ਭਾਵਨਾਤਮਕ ਲੇਬਲ ਤਰਜੀਹਾਂ ਨੂੰ ਤੇਜ਼ ਕਰਦੇ ਹਨ; ਇਹ ਨਾਜ਼ੁਕ ਅਤੇ ਗੁੱਸੇ ਵਾਲੀਆਂ ਮੰਗਾਂ ਨੂੰ ਅੱਗੇ ਲਿਆਉਂਦਾ ਹੈ।
• ਸਟ੍ਰਕਚਰਡ ਆਉਟਪੁੱਟ ਨੂੰ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਆਟੋਮੇਸ਼ਨ (ਨੋਟੀਫਿਕੇਸ਼ਨ, ਰੂਟਿੰਗ, CRM) ਨਾਲ ਜੋੜਿਆ ਜਾ ਸਕਦਾ ਹੈ।
• ਉੱਚ-ਪ੍ਰਭਾਵ ਵਾਲੀਆਂ ਕਾਰਵਾਈਆਂ ਅਤੇ ਅਸਪਸ਼ਟ ਲੇਬਲਾਂ ਨੂੰ ਹਮੇਸ਼ਾ ਮਨੁੱਖੀ ਤਸਦੀਕ ਤੋਂ ਗੁਜ਼ਰਨਾ ਚਾਹੀਦਾ ਹੈ।

ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਕੰਮ

ਉੱਪਰ ਦਿੱਤੇ JSON ਐਰੇ ਪ੍ਰੋਂਪਟ ਨਾਲ ਤੁਹਾਡੇ ਕੋਲ 5 ਵੱਖ-ਵੱਖ ਗਾਹਕ ਬੇਨਤੀਆਂ (ਜਾਂ ਨਮੂਨੇ) 'ਤੇ ਬੈਚ ਪ੍ਰਕਿਰਿਆ ਕਰਦਾ ਹੈ। ਫਿਰ ਹੱਥੀਂ ਆਉਟਪੁੱਟ ਦੀ ਜਾਂਚ ਕਰੋ: (1) ਕੀ ਹਰੇਕ ਸ਼੍ਰੇਣੀ ਸਹੀ ਹੈ? (2) ਕੀ "ਨਾਜ਼ੁਕ" ਵਜੋਂ ਚਿੰਨ੍ਹਿਤ ਕੀਤੇ ਗਏ ਅਸਲ ਵਿੱਚ ਸੇਵਾ ਬੰਦ ਕਰਦੇ ਹਨ? (3) ਕੀ ਮੈਂ ਯਕੀਨੀ ਤੌਰ 'ਤੇ ਸਹੀ ਥਾਵਾਂ 'ਤੇ "ਹਾਂ" ਕਿਹਾ ਸੀ? ਕਿਸੇ ਵੀ ਟੈਗ ਨੂੰ ਠੀਕ ਕਰੋ ਜੋ ਫਿੱਟ ਨਹੀਂ ਹਨ ਅਤੇ ਉਸੇ ਅਨੁਸਾਰ ਪ੍ਰੋਂਪਟ (ਖਾਸ ਤੌਰ 'ਤੇ ਸ਼੍ਰੇਣੀ ਪਰਿਭਾਸ਼ਾਵਾਂ ਅਤੇ ਜ਼ਰੂਰੀ ਨਿਯਮ) ਨੂੰ ਅਪਡੇਟ ਕਰੋ। ਇਹ ਅਭਿਆਸ ਤੁਹਾਡੀ ਆਪਣੀ ਅਸਲੀਅਤ ਲਈ ਸਕੀਮਾ ਨੂੰ ਕੈਲੀਬਰੇਟ ਕਰਨ ਦੀ ਆਦਤ ਬਣਾਉਂਦਾ ਹੈ।

ਚੈੱਕਲਿਸਟ

• [ ] ਮੈਂ ਸ਼੍ਰੇਣੀਆਂ ਦੀ ਇੱਕ ਬੰਦ ਅਤੇ ਵੱਖਰੀ ਸੂਚੀ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤਾ ਹੈ।
• [ ] ਮੈਂ ਠੋਸ ਉਪਾਵਾਂ ਨਾਲ ਜ਼ਰੂਰੀਤਾ ਦੇ ਪੱਧਰਾਂ ਦਾ ਵਰਣਨ ਕੀਤਾ ਹੈ।
• [ ] ਮੈਂ ਆਉਟਪੁੱਟ ਫਾਰਮੈਟ (JSON/ਸਾਰਣੀ) ਨੂੰ ਫਿਕਸ ਕੀਤਾ ਹੈ।
• [ ] ਮੈਂ ਅਨਿਸ਼ਚਿਤਤਾ ਲਈ ਇੱਕ ਨਿਕਾਸ ਦਾ ਦਰਵਾਜ਼ਾ ਜੋੜਿਆ (ਮੈਨੂੰ ਯਕੀਨ ਨਹੀਂ ਹੈ)।
• [ ] ਮੈਂ ਹੱਥੀਂ ਪਹਿਲੇ ਬੈਚ ਦੀ ਪੁਸ਼ਟੀ ਕੀਤੀ ਅਤੇ ਪ੍ਰੋਂਪਟ ਨੂੰ ਕੈਲੀਬਰੇਟ ਕੀਤਾ।
• [ ] ਮੈਂ ਉੱਚ-ਪ੍ਰਭਾਵ ਵਾਲੀਆਂ ਕਾਰਵਾਈਆਂ 'ਤੇ ਮਨੁੱਖੀ ਪ੍ਰਵਾਨਗੀ ਦੀ ਇੱਕ ਪਰਤ ਪਾਉਂਦਾ ਹਾਂ।