20 ਮਾਰਚ 2025·2 ਮਿੰਟ
ਟਿਕਟਾਂ ਅਤੇ SLA ਲਈ ਕਸਟਮਰ ਸਪੋਰਟ ਵੈੱਬ ਐਪ ਕਿਵੇਂ ਬਣਾਈਏ
ਟਿਕਟ ਵਰਕਫਲੋ, SLA ਟ੍ਰੈਕਿੰਗ ਅਤੇ ਇੱਕ ਖੋਜਯੋਗ ਜਾਣਕਾਰੀ ਭੰਡਾਰ ਵਾਲੀ ਕਸਟਮਰ ਸਪੋਰਟ ਵੈੱਬ ਐਪ ਦੀ ਯੋਜਨਾ, ਡਿਜ਼ਾਈਨ ਅਤੇ ਤਿਆਰੀ — ਰੋਲ, ਐਨਾਲਿਟਿਕਸ ਅਤੇ ਇੰਟੀਗਰੇਸ਼ਨ ਸਮੇਤ।
ਗੋਲ, ਯੂਜ਼ਰ ਅਤੇ ਸਕੋਪ ਨਿਰਧਾਰਿਤ ਕਰੋ
ਜਦੋਂ ਟਿਕਟਿੰਗ ਉਤਪਾਦ ਫੀਚਰਾਂ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਬਣਦਾ ਹੈ ਨਾ ਕਿ ਨਤੀਜਿਆਂ ਦੇ, ਤਾਂ ਉਹ ਗੜਬੜ ਹੋ ਜਾਂਦਾ ਹੈ। ਖੇਤਰ, ਕਿਊ ਜਾਂ ਆਟੋਮੇਸ਼ਨ ਡਿਜ਼ਾਈਨ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਸਪਸ਼ਟ ਕਰੋ ਕਿ ਐਪ ਕਿਸ ਲਈ ਹੈ, ਕਿਹੜੀ ਪੀੜ ਹਟ ਰਹੀ ਹੈ, ਅਤੇ “ਚੰਗਾ” ਕੀ ਦਿਸਦਾ ਹੈ।
ਆਪਣੇ ਯੂਜ਼ਰਾਂ ਦੀ ਪਛਾਣ ਕਰੋ (ਅਤੇ ਉਹਨਾਂ ਦੇ ਰੋਜ਼ਾਨਾ ਕੰਮ)
ਰੋਲਾਂ ਦੀ ਸੂਚੀ ਬਣਾਉ ਅਤੇ ਹਰ ਇੱਕ ਨੂੰ ਇੱਕ ਸਧਾਰਨ ਹਫ਼ਤੇ ਵਿੱਚ ਕੀ ਕਰਨਾ ਹੁੰਦਾ ਹੈ ਲਿਖੋ:
- ਏਜੰਟ: ਤ्वरਿਤ ਤਰੀਕੇ ਨਾਲ ਟ੍ਰਿਆਜ, ਜਵਾਬ ਦੇਣਾ, ਹੱਲ ਕਰਨਾ ਅਤੇ ਹੱਲ ਦਸਤਾਵੇਜ਼ ਕਰਨਾ।
- ਟੀਮ ਲੀਡ: ਕਾਰਜਭਾਰ ਨੂੰ ਮੁੜ ਤਬਕਾ ਕਰਨਾ, ਅਟਕੇ ਹੋਏ ਟਿਕਟ ਵੇਖਣਾ, SLA ਲਾਗੂ ਕਰਨਾ, ਏਜੰਟਾਂ ਦੀ ਕੋਚਿੰਗ।
- ਐਡਮਿਨ: ਚੈਨਲ, ਵਰਗੀਕਰਨ, ਆਟੋਮੇਸ਼ਨ, ਅਨੁਮਤੀਆਂ ਅਤੇ ਟੈਮਪਲੇਟ ਸੰਰਚਿਤ ਕਰਨਾ।
- ਗਾਹਕ (ਵਿਕਲਪਿਕ): ਬੇਨਤੀਆਂ ਦਾਖਲ ਕਰਨਾ, ਸਥਿਤੀ ਟਰੈਕ ਕਰਨਾ, ਵੇਰਵਾ ਜੋੜਨਾ, ਪੋਰਟਲ ਵਿੱਚ ਜਵਾਬ ਲੱਭਣਾ।
ਜੇ ਤੁਸੀਂ ਇਹ ਕਦਮ ਛੱਡ ਦਿੰਦੇ ਹੋ, ਤਾਂ ਗਲਤੀ ਨਾਲ ਤੁਸੀਂ ਐਡਮਿਨ ਲਈ ਹੀ ਅਪਟੀਮਾਈਜ਼ ਕਰ ਦੋਗੇ ਜਦੋਂ ਕਿ ਏਜੰਟ ਕਿਊ ਵਿੱਚ ਸੰਘਰਸ਼ ਕਰਨਗੇ।
ਤੁਸੀਂ ਹੱਲ ਕਰ ਰਹੇ ਸਮੱਸਿਆਵਾਂ ਲਿਖੋ
ਇਹ ਨੂੰ ਠوس ਅਤੇ ਐਸੋਹੈਵ ਹੈ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਵੇਖ ਸਕਦੇ ਹੋ:
- ਛੁੱਟੀਆਂ SLA: ਟਿਕਟ ਬਿਨਾਂ ਆਵਾਜ਼ ਉਮਰ ਬਦ獃 ਜਾਦਾ ਹੈ; ਏਸਕਲੇਸ਼ਨ ਦੇਰ ਨਾਲ ਹੁੰਦੇ ਹਨ।
- ਗੜਬੜ ਕਿਊਜ਼: ਮਲੂਮ ਨਹੀਂ ਹੁੰਦਾ ਕੌਣ ਮਲਕੀਅਤ ਹੈ, ਨਕਲ ਕੰਮ ਤੇ “ਇਹ ਕਿੱਥੇ ਜਾਣਾ ਚਾਹੀਦਾ?” ਦੀ ਉਲਝਣ।
- ਦੋਹਰਾਏ ਸਵਾਲ: ਉਹੇ ਜਵਾਬ ਵਾਰ-ਵਾਰ ਟਾਈਪ ਹੋ ਰਹੇ ਹਨ, ਜਿਸ ਨਾਲ ਹੱਲ ਦੇਣ ਦੀ ਰਫ਼ਤਾਰ ਘੱਟ ਹੁੰਦੀ ਹੈ।
ਐਪ ਕਿੱਥੇ ਵਰਤੀ ਜਾਵੇਗੀ ਇਹ ਫੈਸਲਾ ਕਰੋ
ਸਪਸ਼ਟ ਹੋਵੋ: ਕੀ ਇਹ ਇੱਕ ਅੰਦਰੂਨੀ ਟੂਲ בלבד ਹੈ, ਜਾਂ ਤੁਸੀਂ ਇੱਕ ਗਾਹਕ-ਮੁੱਖ ਪੋਰਟਲ ਵੀ ਜਾਰੀ ਕਰੋਗੇ? ਪੋਰਟਲ ਦੀਆਂ ਮੰਗਾਂ ਵੱਖ-ਵੱਖ ਹੁੰਦੀਆਂ ਹਨ (ਪਛਾਣ, ਅਨੁਮਤੀਆਂ, ਸਮੱਗਰੀ, ਬ੍ਰੈਂਡਿੰਗ, ਅਲਰਟ)।
ਸਫਲਤਾ ਮੈਟ੍ਰਿਕ ਛੇਤੀ ਚੁਣੋ
ਦਿਨ ਇੱਕ ਤੋਂ ਹੀ ਕੁਝ ਮੁੱਖ ਮੈਟ੍ਰਿਕ ਟਰੈਕ ਕਰਨ ਲਈ ਚੁਣੋ:
- ਪਹਿਲੇ ਜਵਾਬ ਦਾ ਸਮਾਂ
- ਹੱਲ ਕਰਨ ਦਾ ਸਮਾਂ
- ਡਿਫਲੇਕਸ਼ਨ ਦਰ (ਜਾਣਕਾਰੀ ਭੰਡਾਰ ਰਾਹੀਂ ਟਿਕਟਾਂ ਦੀ ਬੱਚਤ)
ਇੱਕ ਸਧਾਰਨ v1 ਸਕੋਪ ਬਿਆਨ ਬਣਾਓ
5–10 ਵਾਕ ਲਿਖੋ ਜੋ ਵੱਖ-ਵੱਖ ਵਸਤਾਂ ਦੱਸਣ: v1 ਵਿੱਚ ਕੀ ਹੋਵੇਗਾ (ਜ਼ਰੂਰੀ ਵਰਕਫਲੋ) ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਕੀ ਜੋੜਿਆ ਜਾਵੇਗਾ (ਅਡਵਾਂਸ ਰੋਟਿੰਗ, AI ਸੁਝਾਅ ਜਾਂ ਡੀਪ ਰਿਪੋਰਟਿੰਗ). ਇਹ ਤੁਹਾਡੇ ਲਈ ਇੱਕ ਗਾਰਡਰੇਲ ਬਣੇਗਾ ਜਦੋਂ ਬੇਨਤੀਆਂ ਵਧਣ।
ਟਿਕਟ ਮਾਡਲ ਅਤੇ ਲਾਈਫਸਾਇਕਲ ਡਿਜ਼ਾਈਨ ਕਰੋ
ਤੁਹਾਡਾ ਟਿਕਟ ਮਾਡਲ ਹਰ ਚੀਜ਼ ਲਈ “ਸੋర్స్ ਆਫ਼ ਤ੍ਰੂਥ” ਹੈ: ਕਿਊਜ਼, SLA, ਰਿਪੋਰਟਿੰਗ ਅਤੇ ਏਜੰਟ ਯੂਆਈ। ਇਹ ਸਹੀ ਜਲਦੀ ਕਰ ਲਓ ਤਾਂ ਮਾਈਗਰੇਸ਼ਨ ਤੋਂ ਬਚਾਅ ਰਹਿੰਦਾ ਹੈ।
ਇੱਕ ਐਸੀ ਲਾਈਫਸਾਇਕਲ ਨਕਸ਼ਾ ਬਣਾਓ ਜੋ ਇਕ ਵਾਕ ਵਿੱਚ ਸਮਝ ਆ ਜਾਵੇ
ਸਪਸ਼ਟ ਰਾਜਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਪ੍ਰਤੱਖ ਰੂਪ ਵਿੱਚ ਹਰ ਇੱਕ ਦਾ ਆਪਰੇਸ਼ਨਲ ਅਰਥ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ:
- ਨਵਾਂ (New): ਬਣਿਆ ਪਰ ਹਜੇ ਤੱਕ ਟ੍ਰਿਆਜ ਨਹੀਂ
- ਅਸਾਈਨਡ (Assigned): ਕਿਸੇ ਏਜੰਟ ਜਾਂ ਟੀਮ ਦੀ ਮਲਕੀਅਤ
- ਚੱਲ ਰਿਹਾ (In progress): ਤੁਰੰਤ ਕੰਮ ਹੋ ਰਿਹਾ
- ਉਡੀਕ ਰਹਿਆ (Waiting): ਰੁਕਿਆ (ਗਾਹਕ ਜਵਾਬ, ਤੀਜਾ ਪੱਖ, ਇੰਜੀਨੀਅਰਿੰਗ)
- ਹੱਲ ਹੋਇਆ (Solved): ਏਜੰਟ ਸੋਚਦਾ ਹੈ ਕਿ ਹੱਲ ਹੋ ਗਿਆ (ਜ਼ਿਆਦਾਤਰ ਨੋਟੀਫਿਕੇਸ਼ਨ ਕੰਟਰੋਲ)
- ਬੰਦ (Closed): ਆਖ਼ਰੀ ਸਥਿਤੀ (ਲਾਕ ਜਾਂ ਸੀਮਤ ਸੰਪਾਦਨ)
ਸਟੇਟ ਟ੍ਰਾਂਜ਼ਿਸ਼ਨ ਲਈ ਨਿਯਮ ਜੋੜੋ। ਉਦਾਹਰਨ ਲਈ, ਸਿਰਫ Assigned/In progress ਟਿਕਟਾਂ ਨੂੰ Solved ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਅਤੇ Closed ਟਿਕਟ ਬਿਨਾਂ ਫਾਲੋਅੱਪ ਬਣਾਏ ਦੁਬਾਰਾ ਨਹੀਂ ਖੁੱਲ ਸਕਦੀ।
ਫੈ਼ਸਲਾ ਕਰੋ ਕਿ ਟਿਕਟ ਸਿਸਟਮ ਵਿੱਚ ਕਿਵੇਂ ਆਵੇਗੀ
ਹਰ ਇੰਟੇਕ ਪਾਥ ਲਿਖੋ ਜੋ ਤੁਸੀਂ ਹੁਣ ਸਪੋਰਟ ਕਰੋਗੇ (ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਜੋੜੋਗੇ): ਵੈੱਬ ਫਾਰਮ, ਇਨਬਾਊਂਡ ਈਮੇਲ, ਚੈਟ, ਅਤੇ API। ਹਰ ਚੈਨਲ ਇੱਕੋ ਜਿਹਾ ਟਿਕਟ ਬਜੈਕਟ ਬਣਾਉਣਾ ਚਾਹੀਦਾ ਹੈ, ਕੁਝ ਚੈਨਲ-ਖਾਸ ਫੀਲਡਸ ਦੇ ਨਾਲ (ਜਿਵੇਂ ਈਮੇਲ ਹੈਡਰ ਜਾਂ ਚੈਟ ਟ੍ਰਾਂਸਕ੍ਰਿਪਟ ID)। ਇਕਸਾਰਤਾ ਆਟੋਮੇਸ਼ਨ ਅਤੇ ਰਿਪੋਰਟਿੰਗ ਨੂੰ ਸਧਾਰਨ ਰੱਖਦੀ ਹੈ।
ਲਾਜਮੀ ਫੀਲਡ ਚੁਣੋ (ਤੇ ਥੋੜੇ ਰੱਖੋ)
ਘੱਟੋ-ਘੱਟ ਲੋੜੀਂਦੇ:
- ਸਬਜੈਕਟ ਅਤੇ ਵੇਰਵਾ
- ਰਿਕਵੈਸਟ ਕਰਨ ਵਾਲਾ (ਗਾਹਕ ਪਛਾਣ)
- ਪ੍ਰਾਇਰਟੀ (ਕਿੰਨੀ ਤੁਰੰਤ)
- ਸ਼੍ਰੇਣੀ (ਕਿਸ ਕਿਸਮ ਦੀ ਸਮੱਸਿਆ)
ਹੋਰ ਸਾਰਾ ਵਿਅਕਲਪਿਕ ਜਾਂ ਅਨੁਪਾਦਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਵੱਧ ਭਰਵਾਅ ਵਾਲਾ ਫਾਰਮ ਪੂਰਨਤਾ ਘਟਾ ਦਿੰਦਾ ਹੈ ਅਤੇ ਏਜੰਟਾਂ ਨੂੰ ਧੀਮਾ ਕਰਦਾ ਹੈ।
ਅਸਲ ਟੀਮਾਂ ਲਈ ਟੈਗ ਅਤੇ ਕਸਟਮ ਫੀਲਡਸ ਦੀ ਯੋਜਨਾ ਬਣਾਓ
ਹਲਕੇ ਛਾਜ਼ ਲਈ ਟੈਗ ਵਰਤੋ (ਜਿਵੇਂ “billing”, “bug”, “vip”), ਅਤੇ ਜਦੋਂ ਤੁਹਾਨੂੰ ਸੰਰਚਿਤ ਰਿਪੋਰਟਿੰਗ ਜਾਂ ਰੋਟਿੰਗ ਦੀ ਲੋੜ ਹੋਵੇ ਤਾਂ ਕਸਟਮ ਫੀਲਡਸ ਬਣਾਓ (ਜਿਵੇਂ “Product area”, “Order ID”, “Region”). ਯਕੀਨੀ ਬਨਾਓ ਕਿ ਫੀਲਡਸ ਟੀਮ-ਸਕੋਪਡ ਹੋ ਸਕਦੇ ਹਨ ਤਾਂ ਇਕ ਵਿਭਾਗ ਦੂਜੇ ਨੂੰ ਭਰ ਨਾ ਦੇਵੇ।
ਟਿਕਟ ਵਿੱਚ ਸਹਯੋਗ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ
ਏਜੰਟਾਂ ਨੂੰ ਕੋਆਰਡੀਨੇਟ ਕਰਨ ਲਈ ਇੱਕ ਸੁਰੱਖਿਅਤ ਥਾਂ ਚਾਹੀਦੀ ਹੈ:
- ਅੰਦਰੂਨੀ ਨੋਟਸ (ਗਾਹਕਾਂ ਨੂੰ ਦਿਖਾਈ ਨਹੀਂ ਦਿੰਦੇ)
- @mentions ਅਤੇ follower/CC ਸੂਚੀਆਂ
- ਲਿੰਕ ਕੀਤੇ ਟਿਕਟਸ (ਨਕਲ, ਮਾਪਾ/ਬੱਚੇ ਇਨਸੀਡੈਂਟ)
ਤੁਹਾਡੀ ਏਜੰਟ UI ਨੂੰ ਇਨ੍ਹਾਂ ਤत्त्वਾਂ ਨੂੰ ਮੂਲ ਟਾਈਮਲਾਈਨ ਤੋਂ ਇੱਕ ਕਲਿਕ ਦੂਰ ਬਣਾਉਣਾ ਚਾਹੀਦਾ ਹੈ।
ਟਿਕਟ ਕਿਊਜ਼ ਅਤੇ ਨਿਯੁਕਤੀ ਵਰਕਫਲੋ ਬਣਾਓ
Mock the agent UI quickly
Draft the agent workspace, queue views, and one-click actions in minutes.
ਕਿਊਜ਼ ਅਤੇ ਨਿਯੁਕਤੀ ਉਹ جگہ ਹਨ ਜਿੱਥੇ ਟਿਕਟਿੰਗ ਸਿਸਟਮ ਸਾਂਝੇ ਇਨਬਾਕਸ ਤੋਂ ਬਾਹਰ ਆਉਂਦਾ ਹੈ ਅਤੇ ਆਪਰੇਸ਼ਨ ਟੂਲ ਬਣ ਜਾਂਦਾ ਹੈ। ਤੁਹਾਡਾ ਟੀਚਾ ਸਧਾਰਨ ਹੈ: ਹਰ ਟਿਕਟ ਦੇ ਲਈ ਇੱਕ ਵਾਜਬ “ਅਗਲਾ ਕਾਰਵਾਈ” ਹੋਵੇ, ਅਤੇ ਹਰ ਏਜੰਟ ਨੂੰ ਪਤਾ ਹੋਵੇ ਕਿ ਹੁਣ ਕੀ ਕਰਨਾ ਹੈ।
ਏਜੰਟ ਕਿਊ ਐਸਾ ਡਿਜ਼ਾਈਨ ਕਰੋ ਜੋ “ਅਗਲਾ ਕੀ ਹੈ?” ਦਾ ਜਵਾਬ ਦੇਵੇ
ਇੱਕ ਕਿਊ ਦ੍ਰਿਸ਼ ਬਣਾਓ ਜੋ ਡਿਫ਼ੌਲਟ ਤੌਰ ਤੇ ਸਭ ਤੋਂ ਸਮੇਂ-ਸੰਵੇਦਨਸ਼ੀਲ ਕੰਮ ਦਿਖਾਏ। ਆਮ ਸੋਰਟ آپਸ਼ਨ ਜੋ ਏਜੰਟ ਅਸਲ ਵਿੱਚ ਵਰਤਣਗੇ:
- ਪ੍ਰਾਇਰਟੀ (ਜਿਵੇਂ P1–P4)
- SLA ਦੇਣ ਵਾਲਾ ਸਮਾਂ (ਸਭ ਤੋਂ ਪਹਿਲਾਂ)
- ਆਖਰੀ ਅੱਪਡੇਟ (ਫ਼ਾਂਸੀ ਹੋਈਆਂ ਗੱਲਾਂ ਨੂੰ ਫੜਨ ਲਈ)
ਤੇਜ਼ ਫਿਲਟਰ (ਟੀਮ, ਚੈਨਲ, ਪ੍ਰੋਡਕਟ, ਗਾਹਕ ਟੀਅਰ) ਅਤੇ ਤੇਜ਼ ਸਰਚ ਜੋੜੋ। ਲਿਸਟ ਕਾਂਡੇਨਸ ਰੱਖੋ: ਸਬਜੈਕਟ, ਰਿਕਵੈਸਟਰ, ਪ੍ਰਾਇਰਟੀ, ਸਥਿਤੀ, SLA ਕਾਊਂਟਡਾਊਨ, ਅਤੇ ਅਸਾਈਨੀਡ ਏਜੰਟ ਆਮ ਤੌਰ 'ਤੇ ਕਾਫੀ ਹੁੰਦੇ ਹਨ।
ਨਿਯੁਕਤੀ ਨਿਯਮ: ਸੰਭਵ ਹੋਵੇ ਤਾਂ ਆਟੋਮੈਟਿਕ, ਲੋੜ ਪੈਣ 'ਤੇ ਮੈਨੁਅਲ
ਕੁਝ ਨਿਯੁਕਤੀ ਰਸਤੇ ਸਪੋਰਟ ਕਰੋ ਤਾਂ ਟੀਮਾਂ ਬਿਨਾਂ ਟੂਲ ਬਦਲੇ ਤਰੱਕੀ ਕਰ ਸਕਣ:
- ਮੈਨੁਅਲ ਨਿਯੁਕਤੀ ਕਿਨਾਰੇ ਦੇ ਮਾਮਲੇ ਅਤੇ ਟ੍ਰੈਨਿੰਗ ਲਈ
- ਰਾਊਂਡ-ਰੋਬਿਨ ਬੋਝ ਬਰਾਬਰ ਵੰਡਣ ਲਈ
- ਕੌਸ਼ਲ-ਆਧਾਰਿਤ ਰੋਟਿੰਗ (ਭਾਸ਼ਾ, ਪ੍ਰੋਡਕਟ ਐਰੀਆ, ਬਿਲਿੰਗ ਵਸੇ technical)
- ਟੀਮ-ਆਧਾਰਿਤ ਰੋਟਿੰਗ (ਜਿਵੇਂ “Payments,” “Enterprise,” “Returns”)
ਨਿਯਮ ਫੈਸਲਿਆਂ ਨੂੰ ਵਿਜ਼ੀਬਲ ਬਣਾਓ (“Assigned by: Skills → French + Billing”) ਤਾਂ ਏਜੰਟ ਸਿਸਟਮ 'ਤੇ ਭਰੋਸਾ ਕਰਨ।
ਕੰਮ ਨੂੰ ਚਲਾਉਣ ਵਾਲੀਆਂ ਸਥਿਤੀਆਂ ਅਤੇ ਮੈਟੇਰਟਾਰੇ ਜੋ ਕੰਮ ਜਾਰੀ ਰੱਖਣ
Waiting on customer ਅਤੇ Waiting on third party ਵਰਗੀਆਂ ਸਥਿਤੀਆਂ ਟਿਕਟਾਂ ਨੂੰ “ਆਇਲ” ਨਹੀਂ ਦਿਖਾਉਂਦੀਆਂ ਜਦੋਂ ਕਾਰਵਾਈ ਬਲਾਕ ਹੈ, ਅਤੇ ਰਿਪੋਰਟਿੰਗ ਨੂੰ ਸੱਚਾ ਬਣਾਉਂਦੀਆਂ ਹਨ।
ਜਵਾਬ ਤੇਜ਼ ਕਰਨ ਲਈ canned replies ਅਤੇ reply templates ਸ਼ਾਮਲ ਕਰੋ ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਸੁਰੱਖਿਅਤ ਵੈਰੀਏਬਲ ਹੋਣ (ਨਾਮ, ਆਰਡਰ ਨੰਬਰ, SLA ਤਾਰੀਖ)। ਟੈਮਪਲੇਟਾਂ ਨੂੰ ਖੋਜਯੋਗ ਅਤੇ ਅਧਿਕ੍ਰਤ ਲੀਡਾਂ ਵੱਲੋਂ ਸੰਪਾਦਨ ਯੋਗ ਰੱਖੋ।
ਟਕਰਾਅ ਰੋਕੋ (ਦੋ ਏਜੰਟ, ਇੱਕ ਟਿਕਟ)
ਕਾਲੀਜ਼ਨ ਹੈਂਡਲਿੰਗ ਜੋੜੋ: ਜਦੋਂ ਏਜੰਟ ਇੱਕ ਟਿਕਟ ਖੋਲ੍ਹਦਾ ਹੈ, ਤਾਂ ਇੱਕ ਛੋਟਾ “ਵੇਖੋ/ਸੰਪਾਦਨ ਲੌਕ” ਜਾਂ “ਹੁਣ ਸੰਭਾਲ ਰਿਹਾ: [ਏਜੰਟ]