01 ਜੁਲਾ 2025·8 ਮਿੰਟ
ਆਰਡਰ ਦੀ ਸਥਿਤੀ ਟਾਈਮਲਾਈਨ: UI ਅਤੇ ਘਟਨਾਵਾਂ ਜੋ ਸਪੋਰਟ ਲੋਡ ਘਟਾਉਂਦੀਆਂ ਹਨ
ਆਰਡਰ ਸਥਿਤੀ ਟਾਈਮਲਾਈਨ ਜੋ ਸਪੱਸ਼ਟ ਕਰਦੀ ਹੈ ਕਿ ਕੀ ਹੋ ਰਿਹਾ ਹੈ, ਅਗਲਾ ਕੀ ਹੈ ਅਤੇ ਕਦੋਂ ਚਿੰਤਿਤ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ—ਇੱਕ ਸਧਾਰਨ ਇਵੈਂਟ ਮਾਡਲ ਨਾਲ ਜਿਹੜਾ ਅਪਡੇਟ ਲਗਾਤਾਰ ਰੱਖਦਾ ਹੈ।
ਆਰਡਰ ਸਥਿਤੀ ਟਾਈਮਲਾਈਨ ਜੋ ਸਪੱਸ਼ਟ ਕਰਦੀ ਹੈ ਕਿ ਕੀ ਹੋ ਰਿਹਾ ਹੈ, ਅਗਲਾ ਕੀ ਹੈ ਅਤੇ ਕਦੋਂ ਚਿੰਤਿਤ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ—ਇੱਕ ਸਧਾਰਨ ਇਵੈਂਟ ਮਾਡਲ ਨਾਲ ਜਿਹੜਾ ਅਪਡੇਟ ਲਗਾਤਾਰ ਰੱਖਦਾ ਹੈ।
ਜ਼ਿਆਦਾਤਰ “ਮੇਰਾ ਆਰਡਰ ਕਿੱਥੇ ਹੈ?” ਟਿਕਟਾਂ ਅਸਲ ਵਿੱਚ ਸ਼ਿਪਿੰਗ ਬਾਰੇ ਨਹੀਂ ਹੁੰਦੀਆਂ—ਉਹ ਅਣਿਸ਼ਚਿਤਤਾ ਬਾਰੇ ਹੁੰਦੀਆਂ ਹਨ। ਜੇ ਗਾਹਕ ਨੂੰ ਪਤਾ ਨਹੀਂ ਚਲਦਾ ਕਿ ਕੀ ਹੋ ਰਿਹਾ ਹੈ, ਤਾਂ ਉਹ ਅਨੁਮਾਨ ਲਗਾ ਕੇ ਬੰਦੇ ਨੂੰ ਪੁੱਛਦੇ ਹਨ ਭੁਲੇਕਿ ਕੁਝ ਗਲਤ ਨਾ ਵੀ ਹੋਵੇ।
ਉਹੀ ਪ੍ਰਸ਼ਨ ਮੁੜ-ਮੁੜ ਆਉਂਦੇ ਹਨ: ਹੁਣ ਆਰਡਰ ਕਿੱਥੇ ਹੈ, ਕੀ ਇਹ ਸ਼ਿਪ ਹੋ ਚੁੱਕਿਆ ਹੈ ਜਾਂ ਅਜੇ ਤਿਆਰ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ, ਇਹ ਕਦੋਂ ਪਹੁੰਚੇਗਾ (ਅਤੇ ਕੀ ਮਿਤੀ ਬਦਲੀ), ਕੀ ਦੁਲਾਂ ਕਰਨ ਜਾਂ ਪਤਾ ਬਦਲਣ ਦੀ ਸੰਭਵਤਾ ਹੈ, ਅਤੇ ਜੇ ਟ੍ਰੈਕਿੰਗ ਨਹੀਂ ਚਲ ਰਹੀ ਤਾਂ ਕੀ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।
ਜਦੋਂ ਤੁਹਾਡੀ ਟੀਮ ਇਹਨਾਂ ਦਾ ਹੱਥੋਂ-ਹੱਥ ਜਵਾਬ ਦਿੰਦੀ ਹੈ, ਤੱਤਕਾਲੀ ਦੋ ਸਮੱਸਿਆਵਾਂ ਸਾਹਮਣੇ ਆਉਂਦੀਆਂ ਹਨ। ਪਹਿਲੀ ਗੱਲ, ਇਹ ਸਕੇਲ ਨਹੀਂ ਹੁੰਦਾ। ਆਰਡਰਾਂ ਵਿੱਚ ਛੋਟੀ ਤੇਜ਼ੀ ਟਿਕਟਾਂ ਦੀ ਲਹਿਰ ਨੂੰ ਭੰਨ ਸਕਦੀ ਹੈ, ਅਤੇ ਰਿਸਪਾਂਸ ਸਮਾਂ ਖਰਾਬ ਹੋ ਜਾਦਾ ਹੈ। ਦੂਜੀ ਗੱਲ, ਜਵਾਬ ਵਿੱਚ ਫਰਕ ਪੈ ਜਾਂਦਾ ਹੈ। ਇੱਕ ਏਜੰਟ ਕਹਿੰਦਾ ਹੈ “it’s processing,” ਦੂਜਾ ਕਹਿੰਦਾ ਹੈ “it’s being packed,” ਅਤੇ ਗਾਹਕ ਨੂੰ ਸਪਸ਼ਟਤਾ ਦੀ ਬਜਾਏ ਟਕਰਾਅ ਸੁਝਦਾ ਹੈ। ਇਸ ਨਾਲ ਫਾਲੋ-ਅਪ ਬਣਦੇ ਹਨ, ਜੋ ਹੋਰ ਕੰਮ ਲੈ ਆਉਂਦੇ ਹਨ।
ਮਕਸਦ ਸਧਾਰਨ ਹੈ: ਗਾਹਕਾਂ ਨੂੰ ਆਰਡਰ ਸਥਿਤੀ ਬਿਨਾਂ ਅਨੁਮਾਨ ਦੇ ਸਕੇਣੀ ਚਾਹੀਦੀ ਹੈ। ਇੱਕ ਚੰਗੀ ਆਰਡਰ ਸਥਿਤੀ ਟਾਈਮਲਾਈਨ ਅੰਦਰੂਨੀ ਗਤਿਵਿਧੀ ਨੂੰ ਇੱਕ ਸਪਸ਼ਟ ਕਹਾਣੀ ਵਿੱਚ ਬਦਲ ਦਿੰਦੀ ਹੈ ਜਿਸਨੂੰ ਗਾਹਕ ਅਣਗਾਹੀ ਨਾਲ ਫਾਲੋ ਕਰ ਸਕਦਾ ਹੈ।
ਪਾਰਦਰਸ਼ਤਾ ਹਰ ਅੰਦਰੂਨੀ ਤਫਸੀਲ ਦਿਖਾਉਣ ਦਾ ਮਤਲਬ ਨਹੀਂ ਹੈ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਗਾਹਕ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਵੇਖ ਸਕੇ ਕਿ ਹਾਲਤ ਕੀ ਹੈ, ਇਸ 'ਚ ਕਦੋਂ ਬਦਲਾਅ ਆਇਆ (ਉੱਚ ਮਾਤਰਾ ਦਾ ਸਮਾਂ-ਟੈਸ੍ਟੈਂਪ), ਅਗਲਾ ਕੀ ਹੋਵੇਗਾ (ਅਤੇ ਕੀ ਦੇਰ ਕਰ ਸਕਦਾ ਹੈ), ਅਤੇ ਕਦੋਂ ਤੁਹਾਨੂੰ ਸੰਪਰਕ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।
ਜਦੋਂ ਗਾਹਕ ਆਪਣੇ ਆਪ "ਕੀ ਹੋ ਰਿਹਾ ਹੈ ਅਤੇ ਮੈਨੂੰ ਕੀ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ?" ਦਾ ਜਵਾਬ ਦੇ ਸਕਦੇ ਹਨ, ਬਹੁਤ ਸਾਰੀਆਂ ਟਿਕਟਾਂ ਹੀ ਬਣਦੀਆਂ ਹੀ ਨਹੀਂ।
ਗਾਹਕ ਟ੍ਰੈਕਿੰਗ ਇਸ ਲਈ ਨਹੀਂ ਵੇਖਦੇ ਕਿ ਉਹ ਜਿਗਿਆਸੂ ਹਨ। ਉਹ ਇੱ ਲਈ ਵੇਖਦੇ ਹਨ ਕਿ ਉਹਨਾਂ ਨੂੰ ਜਲਦੀ ਜਵਾਬ ਮਿਲੇ: ਹੁਣ ਆਰਡਰ ਕਿੱਥੇ ਹੈ, ਆਖ਼ਰੀ ਵਾਰੀ ਕਦੋਂ ਕੁਝ ਹੋਇਆ, ਅਤੇ ਅਗਲੇ ਕਦਮ ਦੀ ਕੀ ਉਮੀਦ ਹੈ।
ਚੰਗਾ ਆਰਡਰ ਟ੍ਰੈਕਿੰਗ UI ਸਿਰਫ਼ ਇਕ ਲੇਬਲ ਨਹੀਂ ਦਿਖਾਉਂਦਾ—ਇਹ ਇੱਕ ਕਹਾਣੀ ਦੱਸਦਾ ਹੈ। “Shipped” ਸਿਰਫ਼ ਲੇਬਲ ਹੈ। ਇੱਕ ਕਹਾਣੀ ਹੋਵੇਗੀ: “ਕੱਲ੍ਹ ਸ਼ਾਮ 3:12 ਵਜੇ ਸਾਡੇ ਵੈਅਰਹਾਉਸ ਵਿੱਚ ਪੈਕ ਕੀਤਾ ਗਿਆ, ਕੈਰੀਅਰ ਨੇ ਲੈ ਲਿਆ, ਅਗਲਾ ਅਪਡੇਟ ਇੱਕ in-transit ਸਕੈਨ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।” ਇਹ ਕਹਾਣੀ ਅਨੁਮਾਨ ਘਟਾ ਦਿੰਦੀ ਹੈ, ਤਾਂ ਜੋ ਲੋਕ ਸਪੋਰਟ ਨੂੰ ਨਹੀਂ ਪੁਛਦੇ।
ਆਰਡਰ ਸਥਿਤੀ ਟਾਈਮਲਾਈਨ 'ਤੇ ਤਿੰਨਾਂ ਚੀਜ਼ਾਂ ਸਬ ਤੋਂ ਜ਼ਿਆਦਾ ਮਹੱਤਵਪੂਰਨ ਹਨ:
ਜਦੋਂ ਟ੍ਰੈਕਿੰਗ ਸੁੰਨੀ ਜਾਂ ਅਸਪਸ਼ਟ ਮਹਿਸੂਸ ਹੁੰਦੀ ਹੈ ਤਾਂ ਚਿੰਤਾ ਵੱਧਦੀ ਹੈ। ਵੱਡੇ ਕਾਰਨ ਹਨ ਲੰਮੇ ਫ਼ਾਸਲੇ ਬਿਨਾਂ ਵਿਆਖਿਆ, ਅਜਿਹੀ ਸਥਿਤੀ ਲੇਖ ਜੋ ਕੁਝ ਵੀ ਦੱਸ ਸਕਦੀ ਹੈ (“Processing”), ਅਤੇ ਗੁਮ ਡਿਲਿਵਰੀ ਵਿੰਡੋ। ਜੇ ਤੁਸੀਂ ਹੁਣੇ ETA ਅੰਦਾਜ਼ਾ ਨਹੀਂ ਲਗਾ ਸਕਦੇ, ਤਾਂ ਸਾਫ਼ ਬੋਲੋ ਅਤੇ ਦੱਸੋ ਕਿ ਤੁਸੀਂ ਕਿਸ ਦੀ ਉਡੀਕ ਕਰ ਰਹੇ ਹੋ, ਉਦਾਹਰਨ ਲਈ: “ਅਸੀਂ ETA ਕੈਰੀਅਰ ਦੇ ਪਹਿਲੇ ਸਕੈਨ ਤੋਂ ਬਾਅਦ ਦਿਖਾਵਾਂਗੇ।”
ਸੱਚਾਈ ਉਮੀਦ ਤੋਂ ਵੱਧ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਲੋਕ ਦੇਰੀ ਨੂੰ ਜ਼ਿਆਦਾ ਮਾਫ਼ੀ ਨਾਲ ਵੇਖ ਲੈਂਦੇ ਹਨ ਪਰ ਝੂਠੇ ਵਾਅਦੇ ਨੂੰ ਨਹੀਂ। ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਖੁੱਧ ਡੇਟਾ ਅਧੂਰਾ ਹੈ, ਤਾਂ ਜੋ ਜਾਣੂ ਹੈ ਉਹ ਦਿਖਾਓ ਅਤੇ ਬਾਕੀ ਬਾਰੇ ਦੋਸ਼ ਨਾ ਲਾਵੋ।
ਇੱਕ ਸਧਾਰਨ ਉਦਾਹਰਨ: ਜੇ ਪੈਕੇਟ 36 ਘੰਟੇ ਲਈ “Label created” 'ਤੇ ਰਹਿੰਦਾ ਹੈ, ਤਾਂ ਗਾਹਕ ਮੰਨਦਾ ਹੈ ਕਿ ਇਹ ਅਟਕ ਗਿਆ ਹੈ। ਇੱਕ ਮਦਦਗਾਰ ਟਾਈਮਲਾਈਨ ਸੰਦਰਭ ਜੋੜੇਗੀ: “ਕੈਰੀਅਰ ਨੇ ਅਜੇ ਤੱਕ ਪਾਰਸਲ ਨੂੰ ਸਕੈਨ ਨਹੀਂ ਕੀਤਾ। ਅਗਲਾ ਅਪਡੇਟ pickup ਤੋਂ ਬਾਅਦ ਉਮੀਦ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਜੇ ਕੱਲ੍ਹ 5 ਵਜੇ ਤੱਕ ਕੋਈ ਸਕੈਨ ਨਹੀਂ ਹੋਇਆ, ਅਸੀਂ ਜਾਂਚ ਕਰਾਂਗੇ।” ਇਹ ਇਕ ਵਾਕ ਇੱਕ ਲਹਿਰ "ਮੇਰਾ ਆਰਡਰ ਕਿੱਥੇ ਹੈ?" ਵਾਲੀਆਂ ਟਿਕਟਾਂ ਰੋਕ ਸਕਦਾ ਹੈ।
ਇੱਕ ਚੰਗੀ ਆਰਡਰ ਸਥਿਤੀ ਟਾਈਮਲਾਈਨ ਇਕ ਨਜ਼ਰ ਵਿੱਚ ਤਿੰਨ ਗੱਲਾਂ ਦਾ ਜਵਾਬ ਦੇਣੀ ਚਾਹੀਦੀ ਹੈ: ਹੁਣ ਕਿੱਥੇ ਹੈ, ਪਹਿਲਾਂ ਕੀ ਹੋਇਆ, ਅਤੇ ਗਾਹਕ ਅਗਲੇ ਕੀ ਉਮੀਦ ਕਰੇ। ਇਸਨੂੰ ਸਾਦਾ ਰੱਖੋ। ਜੇ ਲੋਕਾਂ ਨੂੰ ਟਾਈਮਲਾਈਨ ਸਮਝਣ ਲਈ ਇੱਕ ਹੈਲਪ ਆਰਟਿਕਲ ਪੜ੍ਹਨਾ ਪੈਂਦਾ ਹੈ, ਤਾਂ ਇਹ ਸਪੋਰਟ ਟਿਕਟ ਘਟਾਉਣ ਵਿਚ ਕਾਮਯਾਬ ਨਹੀਂ ਹੋਵੇਗੀ।
ਛੋਟੇ, ਗਾਹਕ-ਮਿੱਤਰ ਮਾਈਲਸਟੋਨ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਜ਼ਿਆਦਾਤਰ ਦੁਕਾਨਾਂ ਇੱਕ ਸਥਿਰ ਸੈੱਟ ਨਾਲ ਬਹੁਤ ਸਾਰੇ ਸਵਾਲ ਕਵਰ ਕਰ ਸਕਦੀਆਂ ਹਨ: Placed, Paid, Packed, Shipped, Delivered, ਅਤੇ ਸਪਸ਼ਟ ਅੰਤ ਜਿਵੇਂ Canceled ਅਤੇ Returned।
ਹਰ ਕਦਮ ਲਈ ਇੱਕ ਛੋਟਾ ਮਾਇਕ੍ਰੋ-ਕਾਪੀ ਲਾਈਨ ਸ਼ਾਮِل ਕਰੋ ਜੋ ਦੱਸੇ ਕਿ ਇਹਦਾ ਮਤਲਬ ਕੀ ਹੈ ਅਤੇ ਅਗਲਾ ਕੀ ਹੁੰਦਾ ਹੈ। ਉਦਾਹਰਨ: “Packed: ਤੁਹਾਡੀਆਂ ਵਸਤਾਂ ਸਾਡੇ ਵੈਅਰਹਾਉਸ ਵਿੱਚ ਤਿਆਰ ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ। ਅਗਲਾ: ਕੈਰੀਅਰ ਨੂੰ ਸौंਪੀ ਜਾਣਾ।” ਇਹ ਕਲਾਸਿਕ “ਕੀ ਇਹ ਵਾਕਈ ਸ਼ਿਪ ਹੋ ਗਿਆ?” ਸਵਾਲ ਨੂੰ ਰੋਕਦਾ ਹੈ।
ਹਮੇਸ਼ਾ ਟਾਈਮਸਟੈਂਪ ਦਿਖਾਓ, ਅਤੇ ਅਪਡੇਟ ਦੇ ਸ੍ਰੋਤ ਨੂੰ ਲੇਬਲ ਕਰੋ ਤਾਂ ਕਿ ਗਾਹਕ ਭਰੋਸਾ ਕਰ ਸਕਣ। “Updated 14:32 by Warehouse” “Updated today” ਨਾਲੋਂ ਵੱਖਰਾ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ। ਜਦੋਂ ਸ੍ਰੋਤ ਬਾਹਰੀ ਹੋਵੇ ਤਾਂ ਕਹੋ: “Updated by Carrier.” ਜੇ ਤੁਸੀਂ ਸ੍ਰੋਤ ਨਹੀਂ ਜਾਣਦੇ, ਤਾ ਅਨੁਮਾਨ ਨਾ ਲਗਾਓ।
ਐਕਸੈਪਸ਼ਨ ਨੂੰ ਨਾਰਮਲ ਪ੍ਰਗਤੀ ਨਾਲੋਂ ਜਿਆਦਾ ਉਜਾਗਰ ਕਰੋ। ਉਨ੍ਹਾਂ ਨੂੰ ਆਪਣਾ ਵੱਖਰਾ ਦਿੱਖ ਵਾਲਾ ਕਦਮ ਬਣਾਓ ਜਾਂ ਸੰਬੰਧਤ ਕਦਮ 'ਤੇ ਇੱਕ ਸਪਸ਼ਟ ਬੈਜ ਦਿਖਾਓ ਅਤੇ ਸਧਾ ਬੋਲ ਚਲਾ ਕੇ ਅਗਲਾ ਕਦਮ ਦੱਸੋ। ਆਮ ਐਕਸੈਪਸ਼ਨ ਵਿੱਚ Delay, Address issue, ਅਤੇ Delivery attempt failed ਸ਼ਾਮਿਲ ਹਨ।
ਇੱਕ ਸਧਾਰਨ, ਭਰੋਸੇਯੋਗ ਪੈਟਰਨ ਇਹ ਹੈ:
ਉਦਾਹਰਨ: ਗਾਹਕ “Shipped (Carrier) 09:10” ਵੇਖਦਾ ਹੈ ਅਤੇ ਫਿਰ “Delivery attempt failed 18:40”। ਜੇ UI ਇਹ ਵੀ ਦਿਖਾਏ “Carrier ਨੂੰ ਬਿਲਡਿੰਗ ਤੱਕ ਪਹੁੰਚ ਨਹੀਂ ਮਿਲੀ। ਅਗਲਾ ਯਤਨ: ਕੱਲ੍ਹ,” ਤਾਂ ਤੁਸੀਂ ਵਾਪਸੀ-ਵੱਲੀ ਨੋਟਬੰਦ ਚਰਚਾ ਤੋਂ ਬਚ ਜਾਂਦੇ ਹੋ।
ਤੁਹਾਡੀ ਅੰਦਰੂਨੀ ਵਰਕਫਲੋ ਵਿੱਚ ਸੈਂਕੜੇ ਕਦਮ ਹੋ ਸਕਦੇ ਹਨ: picking, packing, batching labels, handing off to a carrier, retries, exceptions, ਆਦਿ। ਗਾਹਕਾਂ ਨੂੰ ਇਸ ਵਰਗੀ ਵਿਆਪਕ ਜਾਣਕਾਰੀ ਦੀ ਲੋੜ ਨਹੀਂ—ਉਹ ਸਾਫ਼ ਜਵਾਬ ਚਾਹੁੰਦੇ ਹਨ: “ਕੀ ਤੁਸੀਂ ਮੇਰਾ ਆਰਡਰ ਪਾਇਆ?”, “ਕੀ ਇਹ ਸ਼ਿਪ ਹੋਇਆ?”, “ਇਹ ਕਦੋਂ ਪਹੁੰਚੇਗਾ?”, ਅਤੇ “ਕੁਝ ਗਲਤ ਹੈ?”
ਇਸ ਲਈ ਅੰਦਰੂਨੀ ਓਪਰੇਸ਼ਨ ਤੋਂ ਗਾਹਕ-ਸਮਣੇ ਵਾਲੀਆਂ ਸਥਿਤੀਆਂ ਨੂੰ ਵੱਖ ਕਰਨਾ ਫਾਇਦਾ ਕੁਦਰਤੀ ਹੈ। ਅੰਦਰੂਨੀ ਵਰਕਫਲੋ ਜਿੰਨਾ ਜ਼ਰੂਰੀ ਹੈ ਉਤਨਾ ਹੀ ਜਟਿਲ ਰੱਖੋ, ਪਰ ਪੇਸ਼ ਕਰਨ ਲਈ ਇੱਕ ਛੋਟਾ, ਸਥਿਰ ਸੈੱਟ ਟਾਈਮਲਾਈਨ ਕਦਮ ਦਿਖਾਓ ਜੋ ਵੈਅਰਹਾਉਸ ਤੋਂ ਬਾਹਰ ਵੀ ਸਮਝ ਆ ਸਕਣ।
ਇੱਕ ਉਪਯੋਗੀ ਤਰੀਕਾ ਹੈ ਮੈਪਿੰਗ ਲੇਅਰ ਸ਼ਾਮِل ਕਰਨਾ: ਬਹੁਤੇ ਅੰਦਰੂਨੀ ਇਵੈਂਟ ਨੂੰ ਕੁਝ ਟਾਈਮਲਾਈਨ ਸਟੇਟ ਵਿੱਚ ਰੋਲ-ਅੱਪ ਕਰ ਦਿਓ। ਉਦਾਹਰਨ ਵਜੋਂ, payment authorized, fraud check passed, ਅਤੇ inventory reserved ਨੂੰ “Order confirmed” ਵਿੱਚ ਰੋਲ-ਅੱਪ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। Pick started, packed, ਅਤੇ label created ਨੂੰ “Preparing” ਦਿਖਾਇਆ ਜਾ ਸਕਦਾ ਹੈ। Carrier handoff ਅਤੇ in-transit scans “Shipped” ਬਣਦੇ ਹਨ। Out-for-delivery scan “Out for delivery” ਬਣਦਾ ਹੈ, ਅਤੇ delivered scan ਨਾਲ ਫ਼ੋਟੋ ਪੁਸ਼ਟੀ “Delivered” ਹੋ ਜਾਂਦਾ ਹੈ।
ਇਹ ਮੈਪਿੰਗ ਲੇਅਰ ਤੁਹਾਡੀ ਸੁਰੱਖਿਆ ਦਾ ਜਾਲ ਵੀ ਹੈ। ਜੇ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਆਪਣਾ ਬੈਕਐਂਡ ਬਦਲਦੇ ਹੋ (ਨਵਾਂ ਕੈਰੀਅਰ, ਨਵਾਂ ਫੁਲਫਿਲਮੈਂਟ ਸੈਂਟਰ, ਨਵੀਂ retry logic), ਤਾਂ ਤੁਹਾਡੀ ਟਾਈਮਲਾਈਨ ਕਦਮਾਂ ਵਿੱਚ ਅਚਾਨਕ ਤਬਦੀਲੀ ਨਹੀਂ ਕਰਨੀ ਚਾਹੀਦੀ। ਗਾਹਕ ਉਹੋ ਜਿਹਾ ਟਾਈਮਲਾਈਨ ਦੇਖਦੇ ਰਹਿਣ ਤਾਂ ਭਰੋਸਾ ਬਣਦਾ ਹੈ।
ਹਰ ਗਾਹਕ-ਸਮਣੇ ਵਾਲੀ ਸਥਿਤੀ ਨੂੰ ਪੜ੍ਹਨ ਯੋਗ ਅਤੇ ਪਹੁੰਚਯੋਗ ਬਣਾਓ। ਪਹਿਲਾਂ ਸਧਾਰਨ ਟੈਕਸਟ ਲੇਬਲ ਵਰਤੋ, ਫਿਰ ਆਈਕਾਨ ਅਤੇ ਰੰਗ ਨਾਲ ਸਹਾਇਤਾ ਕਰੋ। ਰੰਗ ਇੱਕੱਲਾ ਹੁਣੋਂ ਸੰਕੇਤ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ। ਦੇਰੀ ਸਥਿਤੀ ਸ਼ਬਦਾਂ ਵਿੱਚ “Delayed” ਕਹੇ। ਉੱਚ ਕਾਂਟ੍ਰਾਸਟ ਰੱਖੋ, ਇੱਕ ਸਪਸ਼ਟ “ਮੌਜੂਦਾ ਕਦਮ” ਚਿੰਨ੍ਹ ਰੱਖੋ, ਅਤੇ ਛੋਟੇ ਮਦਦਗਾਰ ਲਿਖੋ ਜਿਵੇਂ “ਅਸੀਂ ਤੁਹਾਡਾ ਆਰਡਰ ਤਿਆਰ ਕਰ ਰਹੇ ਹਾਂ (ਆਮ ਤੌਰ 'ਤੇ 1-2 ਦਿਨ)।” ਇਹ “ਇਸਦਾ ਕੀ ਮਤਲਬ?” ਵਾਲੀਆਂ ਟਿਕਟਾਂ ਨੂੰ ਪਹਿਲੇ ਹੀ ਘਟਾ ਦਿੰਦਾ ਹੈ।
ਇੱਕ ਚੰਗੀ ਆਰਡਰ ਸਥਿਤੀ ਟਾਈਮਲਾਈਨ ਇੱਕ ਸਧਾਰਨ ਵਿਚਾਰ ਤੇ ਆਧਾਰਤ ਹੁੰਦੀ ਹੈ: ਤੱਥਾਂ (events) ਸਟੋਰ ਕਰੋ, ਸਿਰਫ਼ ਤਾਜ਼ਾ ਸਥਿਤੀ ਨਹੀਂ। ਇੱਕ ਇਵੈਂਟ ਇੱਕ ਤੱਥ ਹੁੰਦਾ ਹੈ ਜੋ ਇੱਕ ਨਿਰਧਾਰਿਤ ਸਮੇਂ 'ਤੇ ਹੋਇਆ, ਜਿਵੇਂ “label created” ਜਾਂ “package delivered.” ਤੱਥ ਬਦਲਦੇ ਨਹੀਂ, ਇਸ ਲਈ ਤੁਹਾਡੀ ਟਾਈਮਲਾਈਨ ਸਥਿਰ ਰਹਿੰਦੀ ਹੈ।
ਜੇ ਤੁਸੀਂ ਸਿਰਫ਼ ਇੱਕ ਸਥਿਤੀ ਫੀਲਡ ਨੂੰ ਓਵਰਰਾਈਟ ਕਰਦੇ ਹੋ (ਉਦਾਹਰਨ status = shipped), ਤਾਂ ਤੁਸੀਂ ਕਹਾਣੀ ਗੁਆ ਦੇਂਦੇ ਹੋ। ਜਦੋਂ ਗਾਹਕ ਪੁੱਛਦਾ ਹੈ, “ਇਸਨੇ ਕਦੋਂ ਸ਼ਿਪ ਕੀਤਾ?” ਜਾਂ “ਇਹ ਪਿੱਛੇ ਕਿਉਂ ਗਿਆ?”, ਤੁਹਾਡੇ ਕੋਲ ਸਾਫ਼ ਜਵਾਬ ਨਹੀਂ ਹੋਵੇਗਾ। ਇਵੈਂਟ ਨਾਲ ਤੁਹਾਨੂੰ ਇੱਕ ਸਪਸ਼ਟ ਇਤਿਹਾਸ ਅਤੇ ਆਡਿਟ ਟਰੇਲ ਮਿਲਦਾ ਹੈ ਜਿਸ 'ਤੇ ਭਰੋਸਾ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।
ਰਿਕਾਰਡ ਨੂੰ ਸਧਾਰਾ ਅਤੇ ਨਿਰਾਸ਼ਥانہ ਰੱਖੋ। ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਹੋਰ ਜੋੜ ਸਕਦੇ ਹੋ।
order_id: ਇਹ ਇਵੈਂਟ ਕਿਸ ਆਰਡਰ ਨਾਲ ਸੰਬੰਧਿਤ ਹੈevent_type: ਕੀ ਹੋਇਆ (picked_up, out_for_delivery, delivered)happened_at: ਇਹ ਕਦੋਂ ਹੋਇਆ (ਇਹ ਰੀਅਲ-ਵਰਲਡ ਕ੍ਰਿਆ ਦਾ ਸਮਾਂ)actor: ਜਿਸ ਨੇ ਇਹ ਕੀਤਾ (system, warehouse, carrier, support)details: ਛੋਟੀ ਵਾਧੂ ਜਾਣਕਾਰੀ (tracking number, location, note)ਜਦੋਂ ਤੁਹਾਡਾ UI ਟਾਈਮਲਾਈਨ ਰੈਂਡਰ ਕਰਦਾ ਹੈ, ਇਹ happened_at ਦੁਆਰਾ ਐਵੈਂਟ ਨੂੰ ਸਿੱਧਾ ਕਰਕੇ ਦਿਖਾਉਂਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਗਾਹਕ-ਸਮਣੇ ਲੇਬਲ ਬਦਲਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਇਵੈਂਟ ਕਿਸਮਾਂ ਨੂੰ ਰੀਮੇਪ ਕਰ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਇਤਿਹਾਸ ਮੁੜ ਲਿਖੇ।
ਡਿਲਿਵਰੀ ਸਿਸਟਮ ਅਕਸਰ ਇੱਕੋ ਹੀ ਅਪਡੇਟ ਨੂੰ ਮੁੜ-ਭੇਜਦੇ ਹਨ। Idempotency ਦਾ ਮਤਲਬ: ਜੇ ਉਹੀ ਇਵੈਂਟ ਦੁਬਾਰਾ ਆਵੇ, ਤਾਂ ਇਸ ਨੂੰ ਦੋ ਟਾਈਮਲਾਈਨ ਦਰਜਿਆਂ ਵੱਜੋਂ ਨਹੀਂ ਰਖਣਾ ਚਾਹੀਦਾ।
ਸਭ ਤੋਂ ਸਧਾਰਨ ਤਰੀਕਾ ਇਹ ਹੈ ਕਿ ਹਰ ਆਉਣ ਵਾਲੇ ਇਵੈਂਟ ਨੂੰ ਇੱਕ ਸਥਿਰ ਵਿਲੱਖਣ ਕੁੰਜੀ ਦੇਵੋ (ਉਦਾਹਰਨ, ਕੈਰੀਅਰ ਇਵੈਂਟ ID, ਜਾਂ order_id + event_type + happened_at + tracking_number ਦਾ ਹੈਸ਼) ਅਤੇ ਇਸਨੂੰ ਸਟੋਰ ਕਰੋ। ਜੇ ਇਹ ਦੁਬਾਰਾ ਆਵੇ, ਤਾਂ ਤੁਸੀਂ ਇਸਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰ ਦਿਓ।
ਆਰਡਰ ਸਥਿਤੀ ਟਾਈਮਲਾਈਨ ਸਭ ਤੋਂ ਵਧੀਆ ਤਦ ਹੀ ਕੰਮ ਕਰਦੀ ਹੈ ਜਦੋਂ ਇਹ ਉਹ ਅਸਲ ਪਲ ਦਰਸਾਉਂਦੀ ਹੈ ਜੋ ਗਾਹਕ ਸਮਝ ਸਕਦਾ ਹੈ, ਨਾ ਕਿ ਤੁਹਾਡੇ ਅੰਦਰੂਨੀ ਕੰਮ। ਸ਼ੁਰੂ ਕਰੋ ਉਹ ਬਿੰਦੂਆਂ ਲਿਸਟ ਕਰਕੇ ਜਦੋਂ ਕਿਸੇ ਬਣਦੇ ਲਈ ਵਸਤੂ ਵਿਚ ਵਾਸਤਵਿਕ ਤਬਦੀਲੀ ਆਉਂਦੀ ਹੈ: ਪੈਸਾ ਕੈਪਚਰ ਹੋਇਆ, ਡੱਬਾ ਬਣਿਆ, ਕੈਰੀਅਰ ਕੋਲ ਗਿਆ, ਪਹੁੰਚ ਗਿਆ।
ਛੋਟਾ ਸੈੱਟ ਆਮ ਤੌਰ 'ਤੇ ਕਾਫ਼ੀ ਹੁੰਦਾ ਹੈ:
ਨਾਂ ਸਥਿਰ ਅਤੇ ਵਿਸ਼ੇਸ਼ ਰੱਖੋ। “Packed” ਅਤੇ “Ready” ਮਿਲਦੇ-ਜੁਲਦੇ ਸੁਣਦੇ ਹਨ, ਪਰ ਗਾਹਕ ਲਈ ਵੱਖ-ਵੱਖ ਮਤਲਬ ਰੱਖਦੇ ਹਨ। ਹਰ ਇਵੈਂਟ ਲਈ ਇੱਕ ਮਤਲਬ ਚੁਣੋ ਅਤੇ ਇੱਕੋ ਹੀ ਲੇਬਲ ਨੂੰ ਦੁਬਾਰਾ ਨਹੀਂ ਵਰਤੋ।
ਹਰ ਬੈਕਐਂਡ ਇਵੈਂਟ UI ਵਿੱਚ ਨਹੀਂ ਆਉਣਾ ਚਾਹੀਦਾ। ਕੁਝ ਸਿਰਫ਼ ਤੁਹਾਡੀ ਟੀਮ ਲਈ ਹੁੰਦੇ ਹਨ (fraud review, warehouse pick started, address validation). ਇੱਕ ਵਧੀਆ ਨਿਯਮ: ਜੇ ਉਸਨੂੰ ਦਿਖਾਉਣ ਨਾਲ ਹੋਰ ਸਵਾਲ ਬਣ ਜਾਣਗੇ, ਤਾਂ ਇਸਨੂੰ ਅੰਦਰੂਨੀ ਰੱਖੋ।
ਅੰਦਰੂਨੀ ਕਦਮਾਂ ਨੂੰ ਘੱਟ ਗਿਣਤੀ ਵਾਲੀਆਂ ਗਾਹਕ-ਸਮਝਦਾਰ ਸਥਿਤੀਆਂ ਵਿੱਚ ਮੈਪ ਕਰੋ। ਤੁਹਾਡੇ ਕੋਲ ਪੰਜ ਵੈਅਰਹਾਉਸ ਕਦਮ ਹੋ ਸਕਦੇ ਹਨ, ਪਰ ਟਾਈਮਲਾਈਨ “Preparing your order” ਤੱਕ ਹੀ ਦਿਖਾਏ ਜਾ ਸਕਦੀ ਹੈ ਜਦ ਤੱਕ ਇਹ “Handed to carrier” ਨਾ ਹੋ ਜਾਵੇ। ਇਹ UI ਨੂੰ ਸ਼ਾਂਤ ਅਤੇ ਪੇਸ਼ਗੋਈਯੋਗ ਬਨਾਈ ਰੱਖਦਾ ਹੈ।
ਵਕਤ ਲੇਬਲ ਤੋਂ ਵੱਧ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਜੇ ਸੰਭਵ ਹੋਵੇ ਤਾਂ ਦੋ ਟਾਈਮਸਟੈਂਪ ਸਟੋਰ ਕਰੋ: ਜਦੋ ਇਵੈਂਟ ਹੋਇਆ ਅਤੇ ਜਦੋ ਤੁਸੀਂ ਇਸਨੂੰ ਰਿਕਾਰਡ ਕੀਤਾ। UI ਵਿੱਚ ਘਟਨਾ ਦਾ ਸਮਾਂ ਦਿਖਾਓ (ਕੈਰੀਅਰ ਸਕੈਨ ਸਮਾਂ, ਡਿਲਿਵਰੀ ਪੁਸ਼ਟੀ ਸਮਾਂ)। ਜੇ ਤੁਸੀਂ ਸਿਰਫ਼ ਪ੍ਰੋਸੈਸਿੰਗ ਸਮਾਂ ਦਿਖਾਓਗੇ, ਤਾਂ ਇੱਕ ਦੇਰ ਨਾਲ ਆਯਾਤ ਹੋਣ 'ਤੇ ਇਹ ਲੱਗ ਸਕਦਾ ਹੈ ਕਿ ਪੈਕੇਜ ਪਿੱਛੇ ਹੋ ਗਿਆ।
ਕੈਰੀਅਰ ਡੇਟਾ ਕਦੇ ਕਦੇ ਗੁੰਮ ਰਹਿੰਦੀ ਹੈ। ਇਸ ਲਈ ਯੋਜਨਾ ਬਣਾਓ। ਜੇ ਤੁਹਾਨੂੰ ਕਦੇ “Handed to carrier” ਸਕੈਨ ਨਹੀਂ ਮਿਲਦਾ, ਤਾਂ fallback ਵਜੋਂ “Label created” ਦਿਖਾਓ ਅਤੇ ਸਪਸ਼ਟ ਸੁਨੇਹਾ ਰੱਖੋ ਜਿਵੇਂ “Carrier ਦੇ ਸਕੈਨ ਦੀ ਉਡੀਕ ਹੈ।” ਤਰੱਕੀ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਅਗੇ ਵਧਣ ਦੀ ਨਕਲ ਨਾ ਬਣਾਓ।
ਇੱਕ ٹھੋਸ ਉਦਾਹਰਨ: ਵੈਅਰਹਾਉਸ 10:05 'ਤੇ ਲੇਬਲ ਪ੍ਰਿੰਟ ਕਰਦਾ ਹੈ, ਪਰ ਕੈਰੀਅਰ 18:40 'ਤੇ ਹੀ ਸਕੈਨ ਕਰਦਾ ਹੈ। ਤੁਹਾਡਾ ਬੈਕਐਂਡ ਦੋਨੋਂ ਇਵੈਂਟ ਸਟੋਰ ਕਰੇਗਾ, ਪਰ ਤੁਹਾਡੀ ਟਾਈਮਲਾਈਨ ਗੈਪ ਦੌਰਾਨ ਮੂੰਹ ਚਲਣ ਵਾਲੀ ਹਰਕਤ ਦਾ ਇੰਦੇਸ਼ ਨਹੀਂ ਦਿੱਤੇਗੀ। ਇਹ ਚੋਣ ਕਈ “It says shipped but hasn’t moved” ਵਾਲੀਆਂ ਟਿਕਟਾਂ ਨੂੰ ਰੋਕਦੀ ਹੈ।
ਕਦਮ 1: ਪਹਿਲਾਂ ਗਾਹਕ ਟਾਈਮਲਾਈਨ ਲਿਖੋ। 5 ਤੋਂ 8 ਕਦਮ ਲਿਸਟ ਕਰੋ ਜੋ ਖਰੀਦਦਾਰ ਸਮਝ ਸਕਦਾ ਹੈ (ਉਦਾਹਰਨ: Order placed, Paid, Packed, Shipped, Out for delivery, Delivered). ਹਰ ਕਦਮ ਲਈ ਉਹੀ ਵਾਕ ਬਣਾਓ ਜੋ ਤੁਸੀਂ ਦਿਖਾਉਣ ਵਾਲੇ ਹੋ। ਸ਼ਾਂਤ ਅਤੇ ਵਿਸ਼ੇਸ਼ ਰਹੋ।
ਕਦਮ 2: ਇਵੈਂਟ ਕਿਸਮਾਂ ਅਤੇ ਮੈਪਿੰਗ 정의 ਕਰੋ। ਤੁਹਾਡੇ ਸਿਸਟਮ ਦੇ ਕੋਲ ਦਰਜਨਾਂ ਅੰਦਰੂਨੀ ਸਥਿਤੀਆਂ ਹੋ ਸਕਦੀਆਂ ਹਨ, ਪਰ ਗਾਹਕਾਂ ਨੂੰ ਇੱਕ ਘੱਟ ਸੈੱਟ ਹੀ ਵੇਖਣਾ ਚਾਹੀਦਾ ਹੈ। ਇੱਕ ਸਧਾਰਣ ਮੈਪਿੰਗ ਟੇਬਲ ਬਣਾਓ ਜਿਵੇਂ warehouse.picked -> Packed ਅਤੇ carrier.in_transit -> Shipped।
ਕਦਮ 3: ਇਵੈਂਟ ਸਟੋਰ ਕਰੋ, ਫਿਰ view ਗਣਨਾ ਕਰੋ। ਹਰ ਇਵੈਂਟ ਨੂੰ append-only ਰਿਕਾਰਡ ਵਜੋਂ ਸੰਭਾਲੋ ਜਿਸ ਵਿੱਚ order_id, type, occurred_at, ਅਤੇ ਆਪਸ਼ਨਲ data (ਜਿਵੇਂ carrier code ਜਾਂ reason) ਹੋਵੇ। UI ਇਵੈਂਟ ਹਿਸਟਰੀ ਤੋਂ ਬਣੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ, ਨਾ ਕਿ ਇੱਕ single mutable status field ਤੋਂ।
ਕਦਮ 4: ਇੱਕ timeline-ready API ਵਾਪਸ ਕਰੋ। ਰਿਸਪਾਂਸ ਫਰੰਟਏਂਡ ਲਈ ਆਸਾਨ ਹੋਵੇ: steps (ਲੇਬਲਾਂ ਨਾਲ), ਮੌਜੂਦਾ ਕਦਮ ਇੰਡੀਕਸ, ਤੁਹਾਡੇ ਕੋਲ ਜਿਹੜੇ ਟਾਈਮਸਟੈਂਪ ਹਨ, ਅਤੇ ਇੱਕ ਛੋਟਾ ਸੁਨੇਹਾ।
{
"order_id": "123",
"current_step": 3,
"steps": [
{"key":"placed","label":"Order placed","at":"2026-01-09T10:11:00Z"},
{"key":"paid","label":"Payment confirmed","at":"2026-01-09T10:12:00Z"},
{"key":"packed","label":"Packed","at":"2026-01-09T14:40:00Z"},
{"key":"shipped","label":"Shipped","at":null,"message":"Waiting for carrier scan"}
],
"last_update_at": "2026-01-09T14:40:00Z"
}
ਕਦਮ 5: UI ਨੂੰ ਤਾਜ਼ਾ ਰੱਖੋ ਬਿਨਾਂ ਸ਼ੋਰ-ਸ਼राबੇ ਦੇ। ਇੱਕ ਆਰਡਰ ਸਥਿਤੀ ਟਾਈਮਲਾਈਨ ਲਈ, polling ਹਰ 30 ਤੋਂ 120 ਸਕਿੰਟ ਵਿੱਚ ਅਕਸਰ ਕਾਫ਼ੀ ਹੁੰਦਾ ਹੈ ਜਦ ਟਰਾਂਜ਼ੈਕਸ਼ਨ ਸਰਗਰਮ ਹੋਵੇ, ਅਤੇ ਜਦ ਕੁਝ ਵੀ ਨਹੀਂ ਬਦਲ ਰਿਹਾ ਹੋਵੇ ਤਾਂ ਕਾਫ਼ੀ ਕਮ।
ਕਦਮ 6: ਡੇਰ ਡੇਟਾ ਲਈ fallback ਜੋੜੋ। ਜੇ ਕੈਰੀਅਰ ਸਕੈਨ ਦੇਰ ਨਾਲ ਆਉਂਦਾ ਹੈ, ਤਾਂ ਆਖ਼ਰੀ ਜਾਣਿਆ ਗਿਆ ਅਪਡੇਟ ਅਤੇ ਇੱਕ ਸਪਸ਼ਟ ਅਗਲਾ ਕਦਮ ਦਿਖਾਓ: “ਜੇ ਕੱਲ੍ਹ ਤੱਕ ਕੋਈ ਅਪਡੇਟ ਨਹੀਂ ਹੋਇਆ ਤਾਂ ਅਰਡਰ 123 ਨਾਲ ਸਪੋਰਟ ਨਾਲ ਸੰਪਰਕ ਕਰੋ।”
ਇੱਕ ਪ੍ਰੈਕਟਿਕਲ ਉਦਾਹਰਨ: ਗਾਹਕ “Packed” ਦੇਖਦਾ ਹੈ ਟਾਈਮਸਟੈਂਪ ਨਾਲ, ਫਿਰ “Shipped: Waiting for carrier scan” ਦਿਖਦਾ ਰਹਿੰਦਾ ਹੈ ਜਦ ਤੱਕ carrier.accepted ਨਹੀਂ ਆ ਜਾਂਦਾ। ਕੋਈ ਖਾਸ ਜਵਾਬ ਲਈ ਲੋੜ ਨਹੀਂ, ਸਿਰਫ਼ ਸੱਚੀ ਸਥਿਤੀ।
ਗਾਹਕ ਨੇ ਇੱਕ hoodie ਆਰਡਰ ਕੀਤਾ। ਭੁਗਤਾਨ ਤੁਰੰਤ ਹੋ ਗਿਆ, ਪਰ ਪੈਕਿੰਗ ਨੂੰ ਦੋ ਕਾਰੋਬਾਰੀ ਦਿਨ ਲੱਗ ਗਏ। ਫਿਰ ਸ਼ਿਪਿੰਗ ਵਿੱਚ ਕੈਰੀਅਰ ਦੀ ਦੇਰੀ ਹੋ ਗਈ। ਫਿਰ ਵੀ ਗਾਹਕ ਨੂੰ ਪੁੱਛਣਾ ਨਾ ਪਵੇ—ਉਸਨੂੰ ਜਾਣਕਾਰੀ ਮਿਲਣੀ ਚਾਹੀਦੀ ਹੈ।
ਇੱਥੇ ਦਿਨ-ਦਰ-ਦਿਨ ਟਾਈਮਲਾਈਨ ਹੈ ਜੋ ਗਾਹਕ ਵੇਖੇਗਾ (ਉਹੀ UI, ਸਿਰਫ਼ ਨਵੇਂ ਐਨਟ੍ਰੀ ਆਉਂਦੀਆਂ ਹਨ):
| Day and time | Status shown | Message in plain language |
|---|---|---|
| Mon 09:12 | Order placed | “We got your order. You will get updates as it moves.” |
| Mon 09:13 | Payment confirmed | “Payment approved. Next: we will prepare your package.” |
| Tue 16:40 | Preparing your order | “We are packing your items. Expected ship date: Wed.” |
| Wed 14:05 | Shipped | “Handed to carrier. Tracking will update as the carrier scans it.” |
| Thu 08:30 | In transit | “On the way. Current estimate: delivery Fri.” |
| Fri 10:10 | Delivery delayed | “The carrier reported a delay due to high volume. New estimate: Sat. No action needed right now.” |
| Sat 12:22 | Out for delivery | “With your local driver. It usually arrives today.” |
| Sat 18:05 | Delivered | “Delivered. If you cannot find it, check around your entrance and with neighbors.” |
ਧਿਆਨ ਦਿਓ ਕਿ ਸ਼ੁੱਕਰਵਾਰ ਨੂੰ ਕੀ ਬਦਲਿਆ: ਤੁਸੀਂ ਕੋਈ ਨਵੀਂ ਪ੍ਰਵਾਹ ਰਚੀ ਨਹੀਂ। ਤੁਸੀਂ ਇੱਕ ਨਵਾਂ ਇਵੈਂਟ ਜੋੜਿਆ (ਉਦਾਹਰਨ ਤੌਰ 'ਤੇ shipment_delayed) ਅਤੇ ਇਸਨੂੰ ਇੱਕ ਸਪਸ਼ਟ ਗਾਹਕ ਸੁਨੇਹੇ ਨਾਲ ਮੈਪ ਕੀਤਾ। ਪਹਿਲਾਂ ਵਾਲੇ ਕਦਮ ਇੱਕੋ ਜਿਹੇ ਰਹਿੰਦੇ ਹਨ, ਅਤੇ UI ਸਥਿਰ ਰਹਿੰਦੀ ਹੈ।
ਸੰਪਰਕ ਦਾ ਵਿਕਲਪ ਸਿਰਫ਼ ਇੱਕ ਸਪਸ਼ਟ ਥਰੇਸ਼ਹੋਲਡ ਤੋਂ ਬਾਅਦ ਹੀ ਦਿਖਾਓ, ਤਾਂ ਜੋ ਲੋਕ ਚਿੰਤਾਕਾਰ ਕੇਵਲ ਕਲਿੱਕ ਨਾ ਕਰਨ। ਇੱਕ ਸਧਾਰਨ ਨਿਯਮ ਵਰਤੋ: ਆਖ਼ਰੀ ਵਾਅਦੇ ਦੀ ਮਿਤੀ ਤੋਂ 24 ਘੰਟੇ ਬਾਅਦ ਜਾ 72 ਘੰਟੇ ਕਿਸੇ ਬਦਲਾਅ ਦੇ ਬਿਨਾਂ "Contact us" ਦਿਖਾਓ। ਇਸ ਤੋਂ ਪਹਿਲਾਂ, ਆਸਰਾ ਅਤੇ ਮੌਜੂਦਾ ਅੰਦਾਜ਼ਾ ਦਿਖਾਓ।
ਇੱਕ ਚੰਗੀ ਆਰਡਰ ਸਥਿਤੀ ਟਾਈਮਲਾਈਨ "ਮੇਰਾ ਆਰਡਰ ਕਿੱਥੇ ਹੈ?" ਵਾਲੀਆਂ ਟਿਕਟਾਂ ਘਟਾਉਂਦੀ ਹੈ। ਇੱਕ ਖਰਾਬ ਟਾਈਮਲਾਈਨ ਨਵੇਂ ਸਵਾਲ ਪੈਦਾ ਕਰਦੀ ਹੈ ਕਿਉਂਕਿ UI ਅਤੇ ਉਸਦੇ ਪਿੱਛੇ ਦਾ ਡੇਟਾ ਲੋਕਾਂ ਦੀ ਅਸਲ ਅਨੁਭਵ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦਾ।
ਜੇ ਤੁਸੀਂ ਹਰ ਅੰਦਰੂਨੀ ਕਦਮ ਨੂੰ ਦਰਸਾਓਗੇ, ਤਾਂ ਗਾਹਕ ਭਟਕ ਜਾਣਗੇ। ਪੰਦਰਾਂ ਮਾਈਕ੍ਰੋ-ਸਥਿਤੀਆਂ ਜਿਵੇਂ “picked”, “sorted”, “labeled”, “staged”, ਅਤੇ “queued” ਬਹੁਤ ਵਿਅਸਤ ਲੱਗਦੀਆਂ ਹਨ ਪਰ ਉਹ ਦੋ ਅਸਲ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਨਹੀਂ ਦਿੰਦੀਆਂ: “ਇਹ ਕਦੋਂ ਪਹੁੰਚੇਗਾ?” ਅਤੇ “ਕੁਝ ਗਲਤ ਹੈ?” ਜਨਤਕ ਟਾਈਮਲਾਈਨ ਨੂੰ ਛੋਟਾ ਰੱਖੋ, ਬਾਕੀ ਅੰਦਰੂਨੀ ਰੱਖੋ।
ਤਾਜ਼ਾ ਸਥਿਤੀ ਨੂੰ ਓਵਰਰਾਈਟ ਕਰਨਾ ਬਿਨਾਂ ਇਵੈਂਟ ਸਟੋਰ ਕੀਤੇ ਇੱਕ ਤੇਜ਼ ਰਸਤਾ ਹੈ ਟਕਰਾਅ ਬਣਾਉਣ ਲਈ। ਗਾਹਕ “Shipped” ਵੇਖਦਾ ਹੈ, ਬਾਅਦ ਵਿੱਚ ਰੀਫ੍ਰੈਸ਼ ਕਰਦਾ ਹੈ ਅਤੇ ਅਚਾਨਕ “Preparing” ਦਿਖਦਾ ਹੈ ਕਿਉਂਕਿ ਕੋਈ retry ਜਾਂ ਮੈਨੁਅਲ ਐਡੀਟ ਹੋ ਗਿਆ। ਸਮੇਂ-ਚਿੰਨ੍ਹਾਂ ਵਾਲੀ ਇਵੈਂਟ ਇਤਿਹਾਸ ਸਟੋਰ ਕਰੋ ਅਤੇ ਉਸ ਇਤਿਹਾਸ ਤੋਂ ਮੌਜੂਦਾ ਸਥਿਤੀ ਬਣਾਓ।
ਸਭ ਤੋਂ ਆਮ ਗੜਬੜਾਂ ਆਸਾਨੀ ਨਾਲ ਨਜ਼ਰ ਆਉਂਦੀਆਂ ਹਨ:
ਇੱਥੇ ਕਾਰਨ ਹੈ ਕਿ ਇਹ ਮੈਟਰ ਕਰਦਾ ਹੈ। ਇਕ ਆਈਟਮ ਅੱਜ ਸ਼ਿਪ ਹੁੰਦਾ ਹੈ ਅਤੇ ਦੂਜਾ backordered ਹੈ। ਜੇ ਤੁਸੀਂ ਸਿਰਫ਼ “Shipped” ਦਿਖਾਉਂਦੇ ਹੋ, ਤਾਂ ਗਾਹਕ ਸਭ ਕੁਝ ਉਮੀਦ ਕਰੇਗਾ। ਜੇ ਤੁਸੀਂ “Partially shipped (1 of 2)” ਦਿਖਾਉਂਦੇ ਹੋ ਅਤੇ ਹਰ ਪੈਕੇਜ ਨਾਲ “Delivered” ਜੋੜੀ ਰੱਖਦੇ ਹੋ, ਤਾਂ ਟਾਈਮਲਾਈਨ ਬਰਾਬਰ ਦਿਖੇਗੀ।
ਟਾਈਮਲਾਈਨ ਲੇਬਲਾਂ ਨੂੰ ਡੇਟਾਬੇਸ ਫੀਲਡਾਂ ਦੇ ਤੌਰ 'ਤੇ ਨਹੀਂ, ਪਰ ਉਤਪਾਦ ਦੀ ਕਾਪੀ ਸਮਝ ਕੇ ਲਿਖੋ। ਪਹਿਲਾਂ ਮਨੁੱਖਾਂ ਲਈ ਲਿਖੋ, ਫਿਰ ਆਪਣੇ ਅੰਦਰੂਨੀ ਇਵੈਂਟਾਂ ਨੂੰ ਉਹਨਾਂ ਕੁਝ ਗਾਹਕ-ਮਿੱਤਰ ਕਦਮਾਂ ਨਾਲ ਮੈਪ ਕਰੋ।
ਟਾਈਮਲਾਈਨ ਨੂੰ ਹਰ ਗਾਹਕ ਨੂੰ ਰਿਲੀਜ਼ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਗਾਹਕ ਦੇ ਨਜ਼ਰੀਏ ਤੋਂ ਇੱਕ ਤੇਜ਼ ਚੈੱਕ ਕਰੋ: “ਜੇ ਮੈਂ ਇਹ ਰਾਤ 11 ਵਜੇ ਵੇਖਾਂ, ਤਾਂ ਕੀ ਮੈਂ ਫਿਰ ਵੀ ਸਪੋਰਟ ਟਿਕਟ ਖੋਲ਼ਾਂਗਾ?” ਮਕਸਦ ਸਪਸ਼ਟਤਾ ਹੈ ਬਿਨਾਂ ਇਹ ਦਿਖਾਉਣ ਦੇ ਕਿ ਕੁਝ ਗਲਤ ਹੈ।
ਟਾਈਮਸਟੈਂਪ ਅਤੇ ਉਮੀਦ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਹਰ ਆਰਡਰ ਨੂੰ ਆਖ਼ਰੀ ਅਪਡੇਟ ਸਮਾਂ ਅਤੇ ਅਗਲਾ ਆਮ ਤੌਰ 'ਤੇ ਕੀ ਹੁੰਦਾ ਇਹ ਦਿਖਾਉਣਾ ਚਾਹੀਦਾ ਹੈ। “Last updated 2 hours ago” ਅਤੇ “Next: carrier pickup” ਫੀਲਿੰਗ "ਫਸਿਆ ਹੋਇਆ" ਨੂੰ ਘਟਾਉਂਦੇ ਹਨ।
ਪ੍ਰੀ-ਲਾਂਚ ਚੈੱਕਲਿਸਟ ਸੰਖੇਪ ਰੱਖੋ:
ਫਿਰ ਕੁਝ ਗੰਦੇ ਆਰਡਰ ਜ਼ਰੀਏ ਟੈਸਟ ਕਰੋ। ਇੱਕ ਐਸਾ ਲਓ ਜੋ split shipment ਹੋਵੇ, ਇੱਕ ਜਿਹੜਾ ਕੈਰੀਅਰ ਦੇਰ ਨਾਲ ਸਕੈਨ ਕਰਦਾ ਹੋਵੇ, ਅਤੇ ਇੱਕ ਜਿਹੜਾ failed delivery attempt ਹੋਵੇ। ਜੇ ਟਾਈਮਲਾਈਨ ਇੱਕ ਰਾਜ਼ ਵਾਂਗ ਪੜ੍ਹਦੀ ਹੈ, ਤਾਂ ਗਾਹਕ ਮਨੁੱਖ ਨੂੰ ਵਿਵਰਣਾ ਲਈ ਪੂਛਣਗੇ।
ਅੰਤ ਵਿੱਚ, ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਤੁਹਾਡੀ ਸਪੋਰਟ ਟੀਮ ਉਹੀ ਵਿਊ ਵੇਖ ਸਕਦੀ ਹੈ ਜੋ ਗਾਹਕ ਵੇਖਦਾ ਹੈ, ਟਾਈਮਸਟੈਂਪ ਅਤੇ ਐਕਸੈਪਸ਼ਨ ਸੁਨੇਹਿਆਂ ਸਮੇਤ। ਜਦ ਦੋਹਾਂ ਪਾਸੇ ਇਕੋ ਕਹਾਣੀ ਪੜ੍ਹੀ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਜਵਾਬ ਛੋਟੇ ਹੋ ਜਾਂਦੇ ਹਨ ਅਤੇ ਬਹੁਤ ਸਾਰੀਆਂ ਟਿਕਟਾਂ ਹੀ ਨਹੀਂ ਬਣਦੀਆਂ।
ਛੋਟੇ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਉਹ ਮਿਨੀਮਲ ਆਰਡਰ ਸਥਿਤੀ ਟਾਈਮਲਾਈਨ ਜੋ ਮੁੱਖ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਦਿੰਦੀ ਹੈ (ਕੀ ਤੁਸੀਂ ਮੇਰਾ ਆਰਡਰ ਲਿਆ?, ਇਹ ਕਦੋਂ ਸ਼ਿਪ ਹੋਵੇਗਾ?, ਹੁਣ ਇਹ ਕਿੱਥੇ ਹੈ?) ਇੱਕ ਬਹੁਤ ਹੀ ਜਟਿਲ ਟ੍ਰੈੱਕਰ ਨਾਲੋਂ ਬਿਹਤਰ ਹੈ। ਪਹਿਲਾਂ ਕੋਰ ਸਟੇਟ ਸ਼ਿਪ ਕਰੋ, ਫਿਰ ਜਦੋਂ ਅਸਲ ਗਾਹਕ ਫੀਡਬੈਕ ਦਿੱਤਾ ਤਾਂ ਹੋਰ ਵੇਰਵਾ ਜੋੜੋ।
ਧੀਰੇ-ਧੀਰੇ ਰੋਲਆਊਟ ਯੋਜਨਾ ਬਣਾਓ ਤਾਂ ਜੋ ਤੁਸੀਂ ਸਿੱਖ ਸਕੋ ਬਿਨਾਂ ਭਰੋਸਾ ਤੋੜੇ। ਆਰਡਰਾਂ ਦੇ ਇੱਕ ਛੋਟੇ ਹਿੱਸੇ (ਉਦਾਹਰਨ, ਇੱਕ ਵੈਅਰਹਾਉਸ, ਇੱਕ ਸ਼ਿਪਿੰਗ ਮੈਥਡ, ਜਾਂ ਇੱਕ ਦੇਸ਼) ਚੁਣੋ ਅਤੇ ਸਪੋਰਟ ਵਾਲੀ ਬਦੌਲਤ ਅਤੇ ਗਾਹਕ ਵਿਹਾਰ ਦੇ ਬਦਲਾਅ ਨੋਟ ਕਰੋ।
ਅੰਦਾਜ਼ਾ ਨਾ ਲਗਾਓ—ਮਾਪੋ। ਟਾਈਮਲਾਈਨ ਨੂੰ ਇੰਸਟਰੂਮੈਂਟ ਕਰੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਦੇਖ ਸਕੋ ਕਿ ਇਹ ਆਪਣਾ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ ਜਾਂ ਨਹੀਂ। ਰਿਲੀਜ਼ ਤੋਂ ਪਹਿਲਾਂ ਅਤੇ ਬਾਅਦ ਸਭ ਤੋਂ ਆਮ “Where is my order?” ਸਵਾਲਾਂ ਦੀ ਤੁਲਨਾ ਕਰੋ, ਅਤੇ ਟ੍ਰੈਕ ਕਰੋ ਕਿ ਕਿਹੜੀ ਸਥਿਤੀ ਸਕ੍ਰੀਨਾਂ ਉਨ੍ਹਾਂ ਤੋਂ ਪਹਿਲਾਂ ਗਾਹਕਾਂ ਨੇ ਵੇਖੀਆਂ ਜਦੋਂ ਉਹ ਸਪੋਰਟ ਨਾਲ ਸੰਪਰਕ ਕਰਦੇ ਹਨ।
ਸ਼ੁਰੂਆਤੀ ਮੈਟਰਿਕਸ:
ਜ਼ਿਆਦਾਤਰ ਸਪੋਰਟ ਲੋਡ ਐਕਸੈਪਸ਼ਨਜ਼ ਤੋਂ ਆਉਂਦੀ ਹੈ: label created ਪਰ ਕੋਈ ਸਕੈਨ ਨਹੀਂ, weather delay, address issue, split shipment। ਇਹਨਾਂ ਮਾਮਲਿਆਂ ਲਈ ਸੁਨੇਹੇ ਲਈ ਟੈਮਪਲੇਟ ਤਿਆਰ ਕਰੋ ਤਾਂ ਕਿ ਤੁਹਾਡੀ ਟੀਮ ਹਰ ਵਾਰੀ ਇਕੋ ਜਿਹਾ ਜਵਾਬ ਦੇਵੇ। ਛੋਟੇ, ਸਪਸ਼ਟ, ਕਾਰਵਾਈ-ਆਧਾਰਿਤ ਰੱਖੋ: ਕੀ ਹੋਇਆ, ਤੁਸੀਂ ਕੀ ਕਰ ਰਹੇ ਹੋ, ਅਤੇ ਗਾਹਕ ਅਗਲੇ ਕੀ ਉਮੀਦ ਰੱਖੇ।
ਜੇ ਤੁਸੀਂ UI ਅਤੇ ਇਵੈਂਟ-ਬੈਕਡ API ਦਾ ਪ੍ਰੋਟੋਟਾਈਪ ਬਣਾ ਰਹੇ ਹੋ, ਤਾਂ ਇੱਕ vibe-coding ਪਲੇਟਫਾਰਮ ਜਿਵੇਂ Koder.ai (koder.ai) ਪਹਿਲੀ ਪਾਸ ਬਣਾਉਣ ਲਈ ਸਹਾਇਕ ਹੋ ਸਕਦਾ ਹੈ—ਛੋਟੀ ਗੱਲ-ਬਾਤ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ, ਫਿਰ ਟਿਕਟਾਂ ਤੋਂ ਸਿੱਖ ਕੇ ਕਾਪੀ ਅਤੇ ਮੈਪਿੰਗ ਸੁਧਾਰੋ।
ਕਵਰੇਜ ਨੂੰ ਕਦਮ-ਕਦਮ ਵਧਾਓ। ਜਦੋਂ ਸਬਸੈਟ ਰੋਲਆਊਟ ਘੱਟ ਟਿਕਟ ਦਿਖਾਏ (ਅਤੇ ਕੋਈ ਨਵੀਂ ਗੁੰਝਲ ਨਹੀਂ), ਤਾਂ ਹੋਰ ਆਰਡਰ ਕਿਸਮਾਂ ਅਤੇ ਕੈਰੀਅਰਾਂ 'ਤੇ ਵਧਾਓ। ਹਫਤੇ-ਹਫਤੇ ਜਾਂ ਕੁਝ ਹਫ਼ਤਿਆਂ 'ਚ ਇੱਕ ਸਮੀਖਿਆ ਰਖੋ: ਨਵੇਂ ਟਿਕਟ ਥੀਮਾਂ ਨੂੰ ਸਕੈਨ ਕਰੋ ਅਤੇ ਫ਼ੈਸਲਾ ਕਰੋ ਕਿ ਫਿਕਸ ਵਧੀਆ ਲਫ਼ਜ਼ ਹੈ, ਇਕ ਨਵਾਂ ਐਕਸੈਪਸ਼ਨ ਟੈਮਪਲੇਟ ਹੈ, ਜਾਂ ਇੱਕ ਨਵਾਂ ਇਵੈਂਟ ਟਾਈਮਲਾਈਨ ਨੂੰ ਭਰਨਾ ਚਾਹੀਦਾ ਹੈ।
ਓਖਾ ਪਤਾ ਲਗਾਉਣ ਦੀ ਬਜਾਏ ਇੱਕ ਛੋਟਾ, ਪੜ੍ਹਨਯੋਗ ਟਾਈਮਲਾਈਨ ਡਿਫੌਲਟ ਕਰੋ ਜੋ ਤਿੰਨ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਦੇਵੇ: ਹੁਣ ਕੀ ਹੋ ਰਿਹਾ ਹੈ, ਇਹ ਆਖ਼ਰੀ ਵਾਰੀ ਕਦੋਂ ਬਦਲਿਆ, ਅਤੇ ਅਗਲਾ ਕੀ ਹੋਵੇਗਾ। ਜ਼ਿਆਦਾਤਰ ਟਿਕਟਾਂ ਅਣਿਸ਼ਚਿਤਤਾ ਤੋਂ ਬਣਦੀਆਂ ਹਨ, ਇਸ ਲਈ ਟਾਈਮਲਾਈਨ ਅੰਦਾਜ਼ਾ ਘਟਾਏ (ਉਦਾਹਰਨ ਲਈ, ਅਸਪਸ਼ਟ “Processing” ਦੀ بجائے “Waiting for carrier scan”).
ਉਸ ਸਥਿਰ ਸੈੱਟ ਨੂੰ ਵਰਤੋ ਜੋ ਜ਼ਿਆਦਾਤਰ ਖਰੀਦਦਾਰ ਸਮਝ ਸਕਦੇ ਹਨ:
ਅਤੇ ਸਪਸ਼ਟ ਅੰਤ, ਜਿਵੇਂ Canceled ਅਤੇ Returned ਸ਼ਾਮِل ਕਰੋ। ਅੰਦਰੂਨੀ ਕਦਮ (pick/pack/batch/retry) ਨੂੰ ਗਾਹਕ-ਵਿਊ ਤੋਂ ਬਾਹਰ ਰੱਖੋ।
ਹਰ ਕਦਮ ਲਈ ਟਾਈਮਸਟੈਂਪ ਅਤੇ ਇੱਕ ਸਪਸ਼ਟ “Last updated” ਦਿਖਾਓ। ਜੇ ਤੁਸੀਂ ਅੰਤਰਰਾਸ਼ਟਰੀ ਵੇਚ ਰਹੇ ਹੋ, ਤਾਂ ਟਾਈਮਜ਼ੋਨ ਸ਼ਾਮِل ਕਰੋ ਜਾਂ ਅਬਾਂਧੈਕ ਬਣਾਓ। ਇੱਕ ਟਾਈਮਸਟੈਂਪ “ਕੁਝ ਨਹੀਂ ਹੋ ਰਿਹਾ” ਨੂੰ “ਇਹ ਹਾਲ ਹੀ ਵਿੱਚ ਹੋਇਆ ਸੀ” ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ, ਜੋ ਫਾਲੋ-ਅਪ ਰੋਕਦਾ ਹੈ।
ਇਸਨੂੰ ਆਪਣੀ ਇੱਕ ਵੱਖਰੀ ਦਿੱਖ-ਦਰਜਾ ਵਜੋਂ ਹੱਲ ਕਰੋ, ਨਾਰਮਲ ਤਰੱਕੀ ਸਮਝ ਕੇ ਨਹੀਂ। ਇੱਕ ਵਧੀਆ ਡਿਫੌਲਟ ਸੁਨੇਹਾ ਹੋ ਸਕਦਾ ਹੈ:
ਜਿਸ ਤਰ੍ਹਾਂ ਦੀ ਪ੍ਰਗਤੀ ਨੂੰ ਤੁਸੀਂ ਸਾਬਤ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਉਸਨੂੰ ਦਿਖਾਉਣ ਤੋਂ ਗੁਰੇਜ਼ ਕਰੋ।
ਤੱਥਾਂ (events) ਅਤੇ ਗਾਹਕ ਟਾਈਮਲਾਈਨ (states) ਨੂੰ ਵੱਖ ਕਰੋ। ਵਿਸਥਾਰਿਤ ਅੰਦਰੂਨੀ ਇਵੈਂਟਾਂ ਨੂੰ ਸਟੋਰ ਕਰੋ, ਫਿਰ ਉਹਨਾਂ ਨੂੰ ਕੁਝ ਗਾਹਕ-ਮਿੱਤਰ ਸਟੇਟਾਂ ਵਿੱਚ ਮੈਪ ਕਰੋ। ਇਸ ਨਾਲ UI ਸਥਿਰ ਰਹੇਗਾ ਭਾਵੇਂ ਤੁਹਾਡੀ ਵਰਕਫਲੋ ਬਦਲੇ।
ਇਵੈਂਟਾਂ ਨੂੰ append-only ਤਰੀਕੇ ਨਾਲ ਸਟੋਰ ਕਰੋ (ਉਦਾਹਰਨ: label_created, picked_up, out_for_delivery, delivered) ਨਾਲ:
ਇਡੈਮਪੋਟੈਂਸੀ ਵਰਤੋ। ਹਰ ਆ ਰਹੀ ਅਪਡੇਟ ਨੂੰ ਇੱਕ ਸਥਿਰ UNIQUE ਕੁੰਜੀ ਦਿਓ (ਕੈਰੀਅਰ ਇਵੈਂਟ ID ਜਾਂ ਕੁਝ ਫੀਲਡਾਂ ਦਾ ਹੈਸ਼) ਅਤੇ ਨਕਲਾਂ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰੋ। ਇਹ ਦੁਹਰਾਏ Entries ਨੂੰ ਰੋਕਦਾ ਹੈ, ਜਿਵੇਂ ਜਦੋਂ ਕੈਰੀਅਰ ਅਪਡੇਟ ਦੁਬਾਰਾ ਭੇਜੇ ਤਾਂ “Out for delivery” ਦੁਬਾਰਾ ਨਾ ਆਵੇ।
ਸਭ ਤੋਂ ਵਧੀਆ ਪ੍ਰਕਟੀਸ ਇਹ ਹੈ ਕਿ ਸਭ ਤੋਂ ਵਧੀਆ ਮਾਲੂਮ ਅੰਦਾਜ਼ਾ ਦਿਖਾਓ ਅਤੇ ਸਾਫ਼ ਦੱਸੋ ਕਿ ਤੁਸੀਂ ਕਿਸ ਦੀ ਉਡੀਕ ਕਰ ਰਹੇ ਹੋ। ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਐਨ ETA ਨਹੀਂ ਹੈ, ਸਪਸ਼ਟ ਤਰੀਕੇ ਨਾਲ ਕਹੋ: “ਅਸੀਂ ਪਹਿਲੇ ਕੈਰੀਅਰ ਸਕੈਨ ਤੋਂ ਬਾਅਦ ETA ਦਿਖਾਵਾਂਗੇ।” ਅਸਲੀਅਤ, ਨਿਰਾਸ਼ਾਵਾਦੀ ਵਾਅਦਾਂ ਨਾਲੋਂ ਵਧੇਰੇ ਮੁਆਫੀ ਮਿਲਦੀ ਹੈ।
ਐਕਸੈਪਸ਼ਨਜ਼ ਨੂੰ ਸਪਸ਼ਟ ਅਤੇ ਕਾਰਵਾਈ-ਕੇਂਦ੍ਰਿਤ ਬਣਾਓ। ਆਮ ਐਕਸੈਪਸ਼ਨ:
ਐਕਸੈਪਸ਼ਨ ਸਧਾਰਨ ਤਰੱਕੀ ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਅਹਮ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ ਅਤੇ ਗਾਹਕ ਨੂੰ ਦੱਸੋ ਕਿ ਉਹਨੂੰ ਕੀ ਕਰਨਾ ਹੈ, ਜੇ ਕੁਝ ਕਰਨਾ ਲੋੜੀਂਦਾ ਹੋਵੇ।
ਇੱਕ ਅਗਲੇ-ਕਾਰੀ ਢੰਗ ਵਜੋਂ ਸੰਪਰਕ ਦੇ ਵਿਕਲਪ ਤੁਹਾਨੂੰ ਸਾਫ਼ ਥਰੇਸ਼ਹੋਲਡ ਪਾਸ ਹੋਣ 'ਤੇ ਹੀ ਦਿਖਾਉਣੇ ਚਾਹੀਦੇ ਹਨ, ਉਦਾਹਰਨ:
ਉਸ ਤੋਂ ਪਹਿਲਾਂ, ਆਖ਼ਰੀ ਅਪਡੇਟ ਅਤੇ ਅਗਲਾ ਉਮੀਦ ਕੀਤਾ ਕਦਮ ਦਿਖਾਓ ਤਾਂ ਕਿ ਚਿੰਤਾ ਕਰਕੇ ਕੋਈ ਗਾਹਕ ਸਿਰਫ਼ ਕਲਿੱਕ ਨਾ ਕਰ ਦੇ।
order_idevent_typehappened_atactor (system/warehouse/carrier/support)detailsਫਿਰ ਟਾਈਮਲਾਈਨ ਨੂੰ ਇੱਕ ਇਕੱਲੇ mutable status ਫੀਲਡ ਦੀ ਥਾਂ ਇਵੈਂਟ ਹਿਸਟਰੀ ਤੋਂ ਰੈਂਡਰ ਕਰੋ।