20 ਨਵੰ 2025·8 ਮਿੰਟ
ਪਿੰਕੋਡ-ਅਧਾਰਿਤ ਡਿਲਿਵਰੀ ਸੁਨੇਹਾ ਨਾਲ ਚੈਕਆਊਟ ਹੈਰਾਨੀਆਂ ਘਟਾਓ
ਪਤਾ ਲਾਉ ਕਿ pincode-ਅਧਾਰਿਤ ਡਿਲਿਵਰੀ ਸੁਨੇਹਾ ਕਿਵੇਂ ਉਪਲਬਧਤਾ, ETA ਅਤੇ COD ਪਹਿਲਾਂ ਦਿਖਾ ਕੇ ਚੈਕਆਊਟ ਤੇ ਛੱਡੇ ਜਾਣ ਵਾਲੇ ਕਾਰਟ ਅਤੇ ਸਪੋਰਟ ਟਿਕਟਾਂ ਘਟਾਉਂਦਾ ਹੈ।
ਕਿਉਂ ਚੈਕਆਊਟ 'ਤੇ ਹੈਰਾਨੀਆਂ ਹੁੰਦੀਆਂ ਨੇ (ਅਤੇ ਉਪਭੋਗਤਾ ਕੀ ਉਮੀਦ ਕਰਦੇ ਹਨ)
ਚੈਕਆਊਟ ਹੈਰਾਨੀ ਉਸ ਵੇਲੇ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਖਰੀਦਦਾਰ ਨੂੰ ਲੱਗਦਾ ਹੈ ਕਿ ਨਿਯਮ ਆਖ਼ਰੀ ਮੋੜ 'ਤੇ ਬਦਲ ਗਏ। ਉਹ ਸਾਮਾਨ ਚੁਣਦਾ ਹੈ, ਕੀਮਤ ਮਨ ਵਿੱਚ ਮਨਜ਼ੂਰ ਕਰਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਚੈਕਆਊਟ ਕਿਸੇ ਨਵੇਂ ਪਾਬੰਦੀ ਜਾਂ ਖ਼ਰਚ ਨੂੰ ਜੋੜਦਾ ਹੈ ਜੋ ਪਹਿਲਾਂ ਦਿਖਾਈ ਨਹੀਂ ਦਿੱਤਾ।
ਅਕਸਰ ਇਹ ਇਸ ਤਰ੍ਹਾਂ ਨਜ਼ਰ ਆਉਂਦਾ ਹੈ:
- ਡਿਲਿਵਰੀ ਅਚਾਨਕ ਉਨ੍ਹਾਂ ਦੇ ਪਿੰਕੋਡ ਲਈ “ਉਪਲਬਧ ਨਹੀਂ” ਬਣ ਜਾਂਦੀ
- ਐਡਰੈੱਸ ਦਰਜ ਕਰਨ 'ਤੇ ETA “2-3 ਦਿਨ” ਤੋਂ “10-14 ਦਿਨ” ਹੋ ਜਾਂਦਾ ਹੈ
- Cash on delivery (COD) ਬਿਨਾਂ ਵਾਜ੍ਹੇ ਬਲਾਕ ਹੋ ਜਾਂਦਾ ਹੈ
- ਵਾਧੂ ਫੀਸਾਂ ਆ ਜਾਂਦੀਆਂ ਹਨ (ਸ਼ਿਪਿੰਗ, ਹੈਂਡਲਿੰਗ, ਦੂਰੇ ilaqੇ ਦੀ ਫੀਸ, ਘੱਟੋ-ਘੱਟ ਆਰਡਰ ਨਿਯਮ)
ਇਹ ਹੈਰਾਨੀਆਂ ਮਹਿੰਗੀਆਂ ਹੁੰਦੀਆਂ ਹਨ। ਲੋਕ ਟਰਾਲੀ ਛੱਡ ਦੇਂਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ ਜੋ ਵੇਖ ਰਹੇ ਹਨ ਉਸ 'ਤੇ ਭਰੋਸਾ ਨਹੀਂ ਕਰਦੇ। ਕੁਝ ਲੋਕ ਆਰਡਰ ਦਿੰਦੇ ਹਨ ਅਤੇ ਫਿਰ ਰੱਦ ਕਰਦੇ ਹਨ ਜਾਂ ਰਿਫੰਡ ਮੰਗਦੇ ਹਨ ਜਦੋਂ ਵਾਅਦਾ ਹਕੀਕਤ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦਾ। ਸਪੋਰਟ ਟੀਮਾਂ ਨੂੰ ਗੁੱਸੇ ਭਰੇ ਸੁਨੇਹੇ ਮਿਲਦੇ ਹਨ: “ਤੁਸੀਂ ਪਹਿਲਾਂ ਨਹੀਂ ਦੱਸਿਆ?” ਅਤੇ “ਤੁਹਾਡੇ ਐਪ ਨੇ ਮੇਰਾ ਸਮਾਂ ਖਰਾਬ ਕੀਤਾ।”
ਮਕਸਦ ਸਪਸ਼ਟ ਹੈ: ਯੂਜ਼ਰ ਦੇ ਅਸੀਂਮਤ ਉੱਤੇ ਸੇਵਾ ਯੋਗਤਾ ਅਤੇ ਉਮੀਦਾਂ ਪੁਸ਼ਟੀ ਕਰਨਾ ਪਹਿਲਾਂ, ਤਾਂ ਜੋ ਉਹ ਮਨੁਸ਼ੀ ਕਮਿਟ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਜਾਣ ਸਕੇ। ਇਹ ਮਤਲਬ ਹੈ ਕਿ ਮੁੱਖ ਨਿਯਮ ਪਹਿਲਾਂ ਹੀ ਦਿਖਾਓ, ਵਧੀਆ ਤਾਂ ਪ੍ਰੋਡਕਟ ਪੇਜ਼ ਜਾਂ ਕਾਰਟ 'ਤੇ, ਤਾਂ ਜੋ ਖਰੀਦਦਾਰ ਜਲਦੀ ਫੈਸਲਾ ਕਰ ਸਕਣ।
ਇੱਥੇ pincode-ਅਧਾਰਿਤ ਡਿਲਿਵਰੀ ਸੁਨੇਹਾ ਮਦਦ ਕਰਦਾ ਹੈ। ਇਹ ਲੁਕਵੇਂ ਪਾਬੰਦੀਆਂ ਨੂੰ ਸਪਸ਼ਟ, ਸਥਾਨਕ-ਵਿਸ਼ੇਸ਼ ਜਵਾਬਾਂ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ: ਕੀ ਤੁਸੀਂ ਇੱਥੇ ਡਿਲਿਵਰ ਕਰ ਸਕਦੇ ਹੋ, ਕਦੋਂ ਪਹੁੰਚੇਗਾ, COD ਦੀ ਆਗਿਆ ਹੈ ਜਾਂ ਨਹੀਂ, ਅਤੇ ਇਸ ਖੇਤਰ ਲਈ ਅੰਤਿਮ ਕੀਮਤ ਕਿਵੇਂ ਹੋਵੇਗੀ।
ਦਾਇਰਾ ਤੰਗ ਅਤੇ ਪ੍ਰਯੋਗਿਕ ਰੱਖੋ। ਉਹਨਾਂ ਚਾਰ ਗੱਲਾਂ ’ਤੇ ਧਿਆਨ ਦਿਓ ਜੋ ਖਰੀਦਦਾਰ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਚਾਹੁੰਦੇ ਹਨ: ਪਿੰਕੋਡ ਅਨੁਸਾਰ ਡਿਲਿਵਰੀ ਉਪਲਬਧਤਾ, ਡਿਲਿਵਰੀ ETA ਸੁਨੇਹਾ, COD ਯੋਗਤਾ ਚੈੱਕ, ਅਤੇ ਖੇਤਰੀ-ਅਨੁਕੂਲ ਕੀਮਤਦਰਸ਼ਨ (ਇਸ ਵਿੱਚ ਸਥਾਨਕ ਫੀਸਾਂ ਜਾਂ ਲਘੂ ਨਿਯਮ ਸ਼ਾਮਲ)।
ਪਹਿਲਾਂ ਕੀ ਦਿਖਾਉਣਾ ਚਾਹੀਦਾ ਹੈ: ਉਪਲਬਧਤਾ, ETA, COD, ਅਤੇ ਫੀਸਾਂ
ਚੈਕਆਊਟ ਹੈਰਾਨੀਆਂ ਘਟਾਉਣ ਦਾ ਤੇਜ਼ ਤਰੀਕਾ ਇਹਨਾਂ ਚਾਰ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਪਹਿਲਾਂ ਦੇਣਾ ਹੈ:
ਕੀ ਤੁਸੀਂ ਮੇਰੇ ਇੱਥੇ ਡਿਲਿਵਰ ਕਰ ਸਕਦੇ ਹੋ? ਇਹ ਕਦੋਂ ਪਹੁੰਚੇਗਾ? ਕੀ ਮੈਂ ਨਗਦ ਭੁਗਤਾਨ ਕਰ ਸਕਦਾ/ਸਕਦੀ ਹਾਂ? ਮੇਰੇ ਖੇਤਰ ਨੂੰ ਸ਼ਿਪਿੰਗ ਦੀ ਕੀ ਕੀਮਤ ਆਏਗੀ?
ਉਪਲਬਧਤਾ
ਉਪਲਬਧਤਾ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। “Deliverable” ਜਾਂ “Not deliverable” 'ਤੇ ਹੀ ਰੁਕੋ ਨਾ। ਜੇ ਉਤਪਾਦ-ਖ਼ਾਸ ਪਾਬੰਦੀਆਂ ਹਨ, ਤਦ ਉਨ੍ਹਾਂ ਨੂੰ ਸਾਫ਼ ਸ਼ਬਦਾਂ ਵਿੱਚ ਦੱਸੋ।
ਚੰਗੇ ਉਦਾਹਰਨ:
- “ਤੁਹਾਡੇ ਖੇਤਰ ਵਿੱਚ ਉਪਲਬਧ ਹੈ, ਪਰ ਬੈਟਰੀਆਂ ਸਿਰਫ਼ ਗ੍ਰਾਉਂਡ ਰਾਹੀਂ ਭੇਜੀਆਂ ਜਾਂਦੀਆਂ ਹਨ।”
- “ਇਸ ਆਈਟਮ ਨੂੰ ਉਸ ਪਿੰਕੋਡ 'ਤੇ ਆਕਾਰ ਦੀਆਂ ਪਾਬੰਦੀਾਂ ਕਾਰਨ ਡਿਲਿਵਰ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ।”
ਲੋਕ ਬੁਰੇ ਖ਼ਬਰ ਨੂੰ ਵਧੇਰੇ ਆਸਾਨੀ ਨਾਲ ਸਵੀਕਾਰ ਕਰ ਲੈਂਦੇ ਹਨ ਜਦੋਂ ਉਹ ਖਾਸ ਹੁੰਦੀ ਹੈ।
ETA
ETA ਅਗਲੀ ਮਹੱਤਵਪੂਰਨ ਗੱਲ ਹੈ, ਪਰ ਸਿਰਫ਼ ਜੇ ਇਹ ਭਰੋਸੇਯੋਗ ਹੋਵੇ। ਇੱਕ ਤੰਗ ਵਾਅਦਾ ਜੋ ਤੁਸੀਂ ਪੂਰਾ ਨਾ ਕਰੋ, ਉਸ ਨਾਲ ਨੁਕਸਾਨ ਹੋਵੇਗਾ; ਇਸ ਲਈ “2 ਤੋਂ 4 ਦਿਨ” ਵਰਗੇ ਰੇਂਜ ਨੂੰ ਪਸੰਦ ਕਰੋ, ਅਤੇ ਕੇਵਲ ਓਦੋਂ ਕਟਆਫ਼ ਨੋਟ ਸ਼ਾਮਲ ਕਰੋ ਜਦੋਂ ਇਹ ਵਰਤਾਰ ਨੂੰ ਬਦਲ ਦੇਵੇ (ਉਦਾਹਰਨ: “ਸਵੇਰੇ 4 ਵਜੇ ਤੋਂ ਪਹਿਲਾਂ ਆਰਡਰ ਕਰੋ ਤਾਂ ਹੀ ਉਹੀ ਦਿਨ ਡਿਸਪੈਚ”)।
ਜੇ ETA ਉਤਪਾਦ ਮੁਤਾਬਕ ਵੱਖਰਾ ਹੈ, ਤਾਂ ਇਹ ਸ਼ੁਰੂ ਤੋਂ ਦਰਸਾਓ। ਐਡਰੈੱਸ ਕਦਮ ਤੱਕ ਇੰਤਜ਼ਾਰ ਨਾ ਕਰੋ।
COD ਯੋਗਤਾ
COD ਯੋਗਤਾ ਬਹੁਤ ਵਾਰੀ ਸਭ ਤੋਂ ਵੱਡੀ ਹੈਰਾਨੀ ਹੁੰਦੀ ਹੈ, ਇਸ ਲਈ ਇਸ ਨੂੰ ਸਪਸ਼ਟ ਦੱਸੋ। ਜੇ COD ਉਪਲਬਧ ਨਹੀਂ ਹੈ, ਤਾਂ ਪਹਿਲਾਂ ਹੀ ਦੱਸੋ। ਜੇ ਇਹ ਉਪਲਬਧ ਹੈ ਪਰ ਸੀਮਤ ਹੈ (ਕੁੱਝ ਵੱਧੋ-ਘੱਟ ਆਰਡਰ ਮੁੱਲ, ਬੰਦ ਸ਼੍ਰੇਣੀਆਂ, ਪਹਿਲੀ ਵਾਰ ਖਰੀਦਦਾਰ, ਸਿਰਫ਼ ਪ੍ਰੀਪੇਈਡ ਆਈਟਮ), ਤਾਂ ਇੱਕ ਹੀ ਛੋਟੀ ਲਾਈਨ ਵਿੱਚ ਨਿਯਮ ਦੱਸੋ।
ਫੀਸਾਂ
ਫੀਸਾਂ ਉੱਥੇ ਹਨ ਜਿੱਥੇ ਭਰੋਸਾ ਜਿੱਤਿਆ ਜਾਂ ਜਾਂਦਾ ਹੈ ਜਾਂ ਹਾਰ ਜਾਂਦਾ ਹੈ। ਖੇਤਰੀ-ਅਨੁਕੂਲ ਕੀਮਤਦਰਸ਼ਨ ਉਹ ਦਿਖਾਵੇ ਜੋ ਹਕੀਕਤ ਵਿੱਚ ਪਿੰਕੋਡ ਦੁਆਰਾ ਬਦਲਦਾ ਹੈ: ਸ਼ਿਪਿੰਗ ਫੀਸ, COD ਫੀਸ, ਜਿੱਥੇ ਲਾਗੂ ਹੋਵੇ ਸਥਾਨਕ ਟੈਕਸ, ਜਾਂ ਘੱਟੋ-ਘੱਟ ਆਰਡਰ ਸੀਮਾ।
ਜੇ ਤੁਸੀਂ ਅਜੇ ਤੱਕ ਸਹੀ ਟੈਕਸ ਨਹੀਂ ਗਿਣ ਸਕਦੇ, ਤਾਂ ਅਨੁਮਾਨ ਨਾ ਲਾਓ। ਕਹੋ “Estimated at checkout” ਅਤੇ ਇੱਕ ਛੋਟਾ ਕਾਰਨ ਦਿਓ।
ਇੱਕ ਸਧਾਰਣ ਪ੍ਰਸਤੁਤੀ ਜੋ ਕੰਮ ਕਰਦੀ ਹੈ:
- ਡਿਲਿਵਰੇਬਲ ਸਥਿਤੀ (ਜੋ ਕੋਈ ਰੋਕਾਵਟ ਹੋਵੇ ਉਹ ਵੀ)
- ETA ਰੇਂਜ (ਕਿਸੇ ਵੀ ਕਟਆਫ਼ ਨੋਟ ਦੇ ਨਾਲ)
- COD: ਹਾਂ/ਨਹੀਂ (ਜੇ ਸੀਮਤ ਹੋਵੇ ਤਾਂ ਮੁੱਖ ਨਿਯਮ)
- ਫੀਸਾਂ: ਸ਼ਿਪਿੰਗ, COD ਫੀਸ ਅਤੇ ਕੋਈ ਘੱਟੋ-ਘੱਟ ਆਰਡਰ ਨਿਯਮ
ਕੇਵਲ ਉਹਨਾਂ ਭਰੋਸੇਯੋਗ ਸੂਚਨਾਂ ਨੂੰ ਦਿਖਾਓ ਜੋ ਉਸ ਖੇਤਰ ਲਈ ਸਹੀ ਹਨ। ਜੇ ਰਿਟਰਨ, ਐਕਸਚੇਂਜ ਜਾਂ ਇੰਸਟਾਲੇਸ਼ਨ ਸਹਾਇਤਾ ਖੇਤਰ ਵਾਰ ਵੱਧਦੀ-ਘਟਦੀ ਹੈ, ਤਾਂ ਸੁਨੇਹਾ ਸਹੀ ਰੱਖੋ। “ਤੁਹਾਡੇ ਖੇਤਰ ਵਿੱਚ ਮੁਫ਼ਤ ਰਿਟਰਨ” ਤਦ ਹੀ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੈ ਜਦੋਂ ਇਹ ਪਿੰਕੋਡ ਲਈ ਭਰੋਸੇਯੋਗ ਹੋਵੇ।
ਉਦਾਹਰਨ: ਇੱਕ ਖਰੀਦਦਾਰ ਆਪਣੇ ਪਿੰਕੋਡ ਨੂੰ ਪ੍ਰੋਡਕਟ ਪੇਜ 'ਤੇ ਦਰਜ ਕਰਦਾ ਹੈ ਅਤੇ ਵੇਖਦਾ ਹੈ: “Deliverable. Arrives in 2 to 4 days. COD available up to ₹5,000. Shipping ₹49, free over ₹999.” ਇਹ ਚਾਰ ਕਾਰਨਾਂ ਨੂੰ ਆਖਰੀ ਵੇਲੇ ਛੱਡਣ ਤੋਂ ਬਚਾਂਦਾ ਹੈ।
ਉਸ ਡੇਟਾ ਦੀ ਲੋੜ ਜੋ ਤੁਸੀਂ ਚਾਹੀਦੀ ਹੈ (ਅਤੇ ਕੌਣ ਆਮ ਤੌਰ 'ਤੇ ਇਸਦਾ ਮਾਲਕ ਹੁੰਦਾ ਹੈ)
ਚੰਗੀ pincode-ਅਧਾਰਿਤ ਡਿਲਿਵਰੀ ਸੁਨੇਹਾ UIs ਦਾ ਮੁੱਦਾ ਘੱਟ ਅਤੇ ਪਿੱਛੇ ਸਾਫ਼ ਨਿਯਮਾਂ ਦਾ ਹੋਣਾ ਹੈ। ਜੇ ਡੇਟਾ ਫੈਲਿਆ ਹੋਇਆ ਹੋਵੇ, ਤਾਂ ਤੁਸੀਂ ਪ੍ਰੋਡਕਟ ਪੇਜ, ਕਾਰਟ ਅਤੇ ਚੈਕਆਊਟ 'ਤੇ ਵੱਖ-ਵੱਖ ਜਵਾਬ ਵਿਖਾਉਂਦੇ ਹੋ ਅਤੇ ਖਰੀਦਦਾਰ ਤੁਸੀਂ 'ਤੇ ਭਰੋਸਾ ਘਟਾਉਂਦੇ ਹਨ।
ਕੋਰ ਇਨਪੁਟਸ ਅਤੇ ਆਮ ਮਾਲਕ
ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ ਕੋਲ ਜ਼ਰੂਰੀ ਚੀਜ਼ਾਂ ਹੁੰਦੀਆਂ ਹਨ, ਪਰ ਇਹ ਵੱਖਰੇ ਥਾਂਵਾਂ ਵਿੱਚ ਪੈਂਦੀਆਂ ਹਨ। ਹਰ ਆਈਟਮ ਲਈ ਇੱਕ “ਸੋర్స్ ਆਫ਼ ਟਰੂਥ” 'ਤੇ ਸਹਿਮਤ ਹੋਵੋ:
- Pincode → zone mapping (Logistics ਜਾਂ Ops): ਕਿਹੜੇ ਪਿੰਕੋਡ ਸਰਵਿਸੇਬਲ ਹਨ, ਕਿਹੜਾ ਕੈਰੀਅਰ ਡਿਲਿਵਰ ਕਰੇਗਾ, ਵਾਅਦਾ ਕੀ ਡਿਲਿਵਰੀ ਸਪੀਡ ਹੈ, ਖਾਸ ਲੇਨ (ਮੇਟਰੋ ਵਿਰੁੱਧ ਦੂਰਾ). ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਕਿਸੇ ਕੋਰੀਅਰ ਟੂਲ, ਸ਼ਿਪਿੰਗ ਐਗਰੀਗੇਟਰ ਜਾਂ ops-maintained sheet ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ।
- ਉਤਪਾਦ ਸੀਮਾਵਾਂ (Catalog ਜਾਂ Fulfillment): ਵਜ਼ਨ ਅਤੇ ਮਾਪ, ਨਾਜੁਕ ਜਾਂ ਖ਼ਤਰਨਾਕ ਫਲੈਗ, ਕੋਲਡ-ਚੇਨ ਦੀ ਲੋੜ, ਅਤੇ ਕਿਹੜਾ ਵੇਅਰਹਾਊਸ ਜਾਂ ਸੈਲਰ ਇਸਨੂੰ ਭੇਜਦਾ ਹੈ। ਇਹ “ਸਰਵਿਸੇਬਲ ਪਿੰਕੋਡ” ਨੂੰ “ਇਸ ਆਈਟਮ ਲਈ ਸਰਵਿਸੇਬਲ” ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ।
- COD ਨਿਯਮ (Payments ਜਾਂ Risk): ਉੱਚ-ਮੁੱਲ ਵਾਲੇ ਕਾਰਟ ਲਈ COD ਬਲਾਕ, ਪਹਿਲੀ ਵਾਰੀ ਖਰੀਦਦਾਰ, ਕੁਝ ਐਡਰੈੱਸ ਕਿਸਮਾਂ (ਹੋਸਟਲ, PO ਬਾਕਸ), ਪਿਛਲੇ ਰਿਟਰਨ, ਜਾਂ ਉਹ ਪਿੰਕੋਡ ਜਿੱਥੇ RTO ਜ਼ਿਆਦਾ ਹੋ। ਇਹ ਨਿਯਮ ਸਪਸ਼ਟ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ, ਨਾਂ ਕਿ ਮਨਮਾਨੇ।
- ਕੀਮਤ ਇਨਪੁਟ (Finance ਅਤੇ Growth): ਜ਼ੋਨ ਅਤੇ ਵਜ਼ਨ ਮੁਤਾਬਕ ਸ਼ਿਪਿੰਗ ਸਲੈਬ, COD ਫੀਸ, ਖੇਤਰੀ ਟੈਕਸ ਨਿਯਮ ਜਿੱਥੇ ਲਾਗੂ, ਪ੍ਰੋਮੋਸ਼ਨ ਜੋ ਸਿਰਫ਼ ਕੁਝ ਰਾਜਾਂ ਜਾਂ ਸ਼ਹਿਰਾਂ ਵਿੱਚ ਲਾਗੂ ਹੁੰਦੇ ਹਨ।
- ਇਨਵੈਂਟਰੀ ਅਤੇ ਕਟਆਫ਼ (Warehouse Ops): ਸਮੇ-ਅਨੁਸਾਰ ਕਟਆਫ਼ ਸਮਾਂ, ਛੁੱਟੀਆਂ, ਅਤੇ ਸਮਰੱਥਾ ਦੀਆਂ ਪਾਬੰਦੀਾਂ ਜੋ ETA ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੀਆਂ ਹਨ ਭਾਵੇਂ ਪਿੰਕੋਡ ਸਰਵਿਸੇਬਲ ਹੋਵੇ।
ਇੱਕ ਆਮ ਹਕੀਕਤੀ ਕੇਸ: ਇੱਕ ਪਿੰਕੋਡ ਸਰਵਿਸੇਬਲ ਹੈ, ਪਰ ਇੱਕ ਵੱਡਾ ਆਈਟਮ ਬਲਾਕ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਕਿਉਂਕਿ ਉਸ ਲੇਨ ਲਈ ਨਿਯੁਕਤ ਕੈਰੀਅਰ ਦਾ ਆਕਾਰ ਸੀਮਾ ਹੋਵੇ। ਜਾਂ COD ਅਯੋਗ ਹੈ ਕਿਉਂਕਿ ਕਾਰਟ ਦਾ ਮੁੱਲ ਲੰਘ ਗਿਆ।
ਜੇ ETA ਅਣਜਾਣ ਹੋਵੇ ਤਾਂ ਬੈਕਅਪ ਯੋਜਨਾ
ਕਈ ਵਾਰੀ ਤੁਸੀਂ ETA ਗਿਣਣ ਨਹੀਂ ਸਕਦੇ (ਵਜ਼ਨ ਗੁੰਮ, ਕੋਈ ਕੈਰੀਅਰ ਜਵਾਬ ਨਹੀਂ, ਮਿਕਸਡ ਕਾਰਟ ਦੋ ਥਾਵਾਂ ਤੋਂ ਭੇਜਿਆ ਜਾ ਰਿਹਾ)। ਨਿਰਣਾ ਕਰੋ ਕਿ ਇਸਦੀ ਥਾਂ ਕੀ ਦਿਖਾਓ ਤਾਂ ਜੋ ਤਜ਼ਰਬਾ ਸਥਿਰ ਰਹੇ:
- “Delivery available to this pincode” ਬਿਨਾਂ ਮਿਤੀ ਦੇ
- ਇੱਕ ETA ਰੇਂਜ (ਉਦਾਹਰਨ: 3 to 5 days) ਇਕ ਦਿਨ ਦੀ ਬਜਾਏ
- “Enter full address at checkout for exact ETA”
- ਜਦੋਂ ਕਿਸੇ ਚੀਜ਼ 'ਤੇ ਰੋਕ ਹੋਵੇ ਤਾਂ ਇੱਕ ਸਪਸ਼ਟ ਕਾਰਨ ਦਿਖਾਓ (ਆਈਟਮ ਸੀਮਿਤ, ਪਿੰਕੋਡ ਨਾ ਸਰਵਿਸ, COD ਅਨੁਮਤੀ ਨਹੀਂ)
ਜੇ ਤੁਸੀਂ ਇਹ ਲਾਜਿਕ ਇੱਕ ਸਾਂਝੇ ਸਰਵਿਸ ਵਿੱਚ ਬਣਾਉਂਦੇ ਹੋ (ਇੱਕ ਸਧਾਰਣ ਅੰਦਰੂਨੀ API ਵੀ), ਤਾਂ ਪੰਨਿਆਂ 'ਤੇ ਸੁਨੇਹੇ ਸਥਿਰ ਰੱਖਣਾ ਬਹੁਤ ਆਸਾਨ ਹੋ ਜਾਂਦਾ ਹੈ।
ਕਿੱਥੇ ਪਿੰਕੋਡ ਚੈਕ ਰੱਖਣਾ ਹੈ ਤਾਂ ਕਿ ਲੋਕ ਦੇਖ ਲੈਣ
ਜੇ ਲੋਕ ਸਿਰਫ਼ ਆਖ਼ਰੀ ਕਦਮ 'ਤੇ ਡਿਲਿਵਰੀ ਹੱਦਾਂ ਬਾਰੇ ਜ਼ਾਨਦੇ ਹਨ, ਤਾਂ ਉਹ ਧੋਖੇ ਵਿੱਚ ਮਹਿਸੂਸ ਕਰਦੇ ਹਨ, ਭਲਕੇ ਨਿਯਮ ਇਮਾਨਦਾਰ ਹੋਣ। ਹੱਲ ਸਧਾਰਣ ਹੈ: ਪਿੰਕੋਡ ਪਹਿਲਾਂ ਪੁੱਛੋ, ਫਿਰ ਉਸੇ ਵਾਅਦੇ ਨੂੰ ਭੁਗਤਾਨ ਤੱਕ ਦੁਹਰਾਓ।
ਸਭ ਤੋਂ ਬਹੁਤ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਥਾਂ ਪ੍ਰੋਡਕਟ ਪੇਜ ਹੈ। ਪਿੰਕੋਡ ਫੀਲਡ ਨੂੰ ਕੀਮਤ ਅਤੇ ਮੁੱਖ Buy/Add to Cart ਬਟਨ ਦੇ ਨੇੜੇ ਰੱਖੋ, ਤਾਂ ਜੋ ਇਹ ਫੈਸਲੇ ਦਾ ਹਿੱਸਾ ਮਹਿਸੂਸ ਹੋਵੇ, ਨਾ ਕਿ ਛੁਪੇ ਹੋਏ ਨਿਯਮ ਵਾਂਗ। ਜੇ ਤੁਹਾਡੇ ਪੇਜ 'ਤੇ ਵੈਰੀਅੰਟ ਹਨ, ਤਾਂ ਪਿੰਕੋਡ ਚੈਕ ਸੇਲੈਕਟ ਕੀਤੇ ਗਏ ਵੈਰੀਅੰਟ ਕੀਮਤ ਦੇ ਨੇੜੇ ਰੱਖੋ।
ਜ਼ਿਆਦਾਤਰ ਸਟੋਰਾਂ ਲਈ ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਲੇਆਉਟ:
- Product page: ਇੱਕ ਛੋਟਾ “Enter pincode” ਫੀਲਡ ਤੁਰੰਤ ਨਤੀਜੇ ਦੇ ਨਾਲ, ਕੀਮਤ ਅਤੇ ਮੁੱਖ CTA ਨੇੜੇ।
- Sticky header ਜਾਂ sticky bar: ਇੱਕ ਵਾਰ ਪੁਸ਼ਟੀ ਹੋਣ 'ਤੇ “Delivering to 560001” ਦਿਖਾਓ ਤਾਂ ਯੂਜ਼ਰ ਨੂੰ ਪਤਾ ਰਹੇ ਕਿ ਤੁਸੀਂ ਕਿਹੜਾ ਪਤਾ ਵਰਤ ਰਹੇ ਹੋ।
- Cart: ਸੇਵ ਕੀਤੇ ਪਿੰਕੋਡ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ ਅਤੇ ਇੱਕ ਘੁਟਿਆ ਹੋਇਆ ਸਮਰੀ ਦਿਖਾਓ (ETA, COD, ਕੋਈ ਡਿਲਿਵਰੀ ਫੀਸ) ਇਕ ਬਲਾਕ ਵਿੱਚ।
- Checkout: ਪੁਸ਼ਟੀ ਕੀਤੇ ਵਾਅਦੇ ਨੂੰ ਦੁਹਰਾਓ ਬਸ। ਨਵੇਂ ਨਿਯਮ ਇਥੇ ਨਾ ਸ਼ਾਮਲ ਕਰੋ।
ਕਾਰਟ ਵਿੱਚ, ਜਾਣਕਾਰੀ ਤਿੰਨ ਥਾਂਵਾਂ 'ਤੇ ਵੰਡਣ ਤੋਂ ਬਚੋ। ਇਸਨੂੰ ਇੱਕ ਸਪਸ਼ਟ ਵਾਕ ਵਿੱਚ ਮਿਲਾਓ, ਉਦਾਹਰਨ: “Delivery by Tue, COD available, Shipping fee: Rs 49.”
ਚੈਕਆਊਟ ਨੂੰ ਇਕ कॉਨਟ੍ਰੈਕਟ ਵਾਂਗ ਦੱਸੋ। ਤੁਸੀਂ ਉਹੀ ਚੀਜ਼ ਦੁਹਰਾ ਰਹੇ ਹੋ ਜੋ ਪਹਿਲਾਂ ਮੰਨ ਲਈ ਗਈ ਸੀ। ਜੇ ਕੁਝ ਬਦਲਦਾ ਹੈ (ਜਿਵੇਂ ਸਟਾਕ ਖਤਮ ਹੋਣਾ), ਤਾਂ ਇਸਨੂੰ ਬਦਲਾਅ ਵਜੋਂ ਦਰਸਾਓ ਅਤੇ ਖਰੀਦਦਾਰ ਨੂੰ ਪੁੱਛੋ, ਬਿਨਾਂ ਚੁਪਚਾਪ ਵਿਕਲਪਾਂ ਨੂੰ ਬਦਲੇ।
ਮੁਢਲੀ ਜਾਂ ਵਰਤਮਾਨ ਜਾਂਚ ਲਈ ਸਾਈਨ-ਇਨ ਜ਼ਬਰਦਸਤੀ ਨਾ ਕਰੋ। ਗੇਸਟ ਯੂਜ਼ਰ ਪ੍ਰੋਡਕਟ ਪੇਜ ਅਤੇ ਕਾਰਟ 'ਤੇ ਪਿੰਕੋਡ ਦਰਜ ਕਰ ਸਕਦੇ ਹਨ, ਫਿਰ ਉਹ ਪੁਸ਼ਟੀ ਕੀਤੀ ਸਥਿਤੀ ਚੈਕਆਊਟ ਤੱਕ ਲੈ ਜਾ ਸਕਦੇ ਹਨ।
ਭਰੋਸਾ ਬਣਾਉਣ ਵਾਲਾ ਸੁਨੇਹਾ (ਬਿਨਾਂ ਜ਼ਿਆਦਾ ਵਾਅਦਾ ਕੀਤੇ)
Add pincode messaging to PDP
Ship a React pincode module near price and Add to Cart without starting from scratch.
ਸਧਾਰਨ ਪ੍ਰੰਪਟ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ: “Enter pincode to check delivery.” ਇਹ ਦੱਸਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਅੰਦਾਜ਼ਾ ਨਹੀਂ ਲਾ ਰਹੇ ਹੋ, ਅਤੇ ਇਹ ਸਪਸ਼ਟ ਕਰਦਾ ਹੈ ਕਿ ਉਪਲਬਧਤਾ ਖੇਤਰ ਮੁਤਾਬਕ ਬਦਲਦੀ ਹੈ।
ਨਤੀਜੇ ਦਿਖਾਉਣ ਤੋਂ ਬਾਅਦ ਇਸਨੂੰ ਸਕੈਨੇਬਲ ਰੱਖੋ। ਲੋਕ ਇਕ ਨਿਗਾਹ ਵਿੱਚ ਨਤੀਜੇ ਸਮਝ ਜਾਣਾ ਚਾਹੁੰਦੇ ਹਨ।
ਪਿੰਕੋਡ ਚੈਕ ਤੋਂ ਬਾਅਦ ਇੱਕ ਸਾਫ਼ ਬਣਤਰ:
- Availability: Available / Not available
- Delivery ETA: “Delivers in 2-4 days” (ਜਾਂ “Ships in 24 hours” ਜੇ ਇਹ ਹੀ ਸਹੀ ਹੈ)
- COD: “Cash on delivery: Available / Not available”
- Fees: “Delivery fee: Rs X” ਜਾਂ “Free delivery”
ਜੇ ਕੁਝ ਸੰਭਵ ਨਹੀਂ, ਤਾਂ ਸਧਾਰਨ ਸ਼ਬਦਾਂ ਵਿੱਚ ਕਾਰਨ ਦੱਸੋ। “Not serviceable in this pincode” “Delivery unavailable” ਤੋਂ ਵਧੀਆ ਹੈ। ਜੇ ਤੁਹਾਨੂੰ ਕਾਰਨ ਪਤਾ ਹੈ, ਤਾਂ ਬਿਨਾਂ ਉਪਭੋਗਤਾ ਨੂੰ ਦੋਸ਼ ਦਿੰਦੇ ਹੋਏ ਖਾਸ ਦੱਸੋ: “Courier pickup not available for this area” ਜਾਂ “This item can’t be shipped to your location.”
ਝੂਠੀ ਸੁਧਾਰ ਜਾਂ ਬਹੁਤ ਸਹੀ ਸਮਾਂ ਦਰਸਾਉਣ ਤੋਂ ਬਚੋ। “Arrives Tuesday, 3:15 PM” ਵਰਗੇ ਸਹੀ ਟਾਈਮਸਟੈਂਪ ਜ਼ਿਆਦਾ ਆਤਮਵਿਸ਼ਵਾਸ ਵਾਲੇ ਲਗਦੇ ਹਨ ਪਰ ਜੇ ਕੈਰੀਅਰ ਉਹਨਾਂ ਨੂੰ ਮਾਰ ਨਹੀਂ ਸਕਦਾ ਤਾਂ ਨੁਕਸਾਨ ਕਰਦੇ ਹਨ। ਦੂਰੀ ਯਾਤਰਾ, ਉੱਚ ਮੰਗ ਵਾਲੀਆਂ ਮੌਸਮਾਂ ਜਾਂ ਦੂਰੇ ਖੇਤਰਾਂ ਲਈ ਰੇਂਜਾਂ ਆਮ ਤੌਰ 'ਤੇ ਜ਼ਿਆਦਾ ਠੀਕ ਲੱਗਦੀਆਂ ਹਨ। ਜੇ ਤੁਸੀਂ ਮਿਤੀ ਦਿਖਾਉਂਦੇ ਹੋ, ਤਾਂ ਇਸਨੂੰ ਅਨੁਮਾਨਿਤ (estimated) ਵਜੋਂ ਲੇਬਲ ਕਰੋ।
ਖਰੀਦਦਾਰ ਦਾ ਪਿੰਕੋਡ ਪ੍ਰੋਡਕਟ, ਕਾਰਟ ਅਤੇ ਚੈਕਆਊਟ 'ਚ ਯਾਦ ਰੱਖੋ ਤਾਂ ਕਿ ਉਹ ਮੁੜ ਨਾ ਭਰੇ। ਪਰ ਇਸਨੂੰ ਇੱਕ ਕਲਿੱਕ ਨਾਲ ਬਦਲਣਾ ਅਸਾਨ ਬਣਾਓ, ਕਿਉਂਕਿ ਲੋਕ ਤੋਹਫ਼ੇ ਲਈ, ਦਫ਼ਤਰੀ ਪ੍ਰੇਰੇ ਲਈ ਜਾਂ ਯਾਤਰਾ ਦੇ ਦੌਰਾਨ ਵੱਖ-ਵੱਖ ਪਤੇ ਵਰਤਦੇ ਹਨ।
ਚੰਗੀ ਤਰ੍ਹਾਂ ਕੀਤਾ ਗਿਆ pincode-ਅਧਾਰਿਤ ਸੁਨੇਹਾ ਹੈਰਾਨੀਆਂ ਘਟਾਉਂਦਾ ਹੈ ਬਿਨਾਂ ਉਹ ਵਾਅਦੇ ਕਰਨ ਦੇ ਜੋ ਤੁਹਾਡੀ ops ਟੀਮ ਰੱਖ ਨਹੀਂ ਸਕਦੀ।
ਕਦਮ-ਦਰ-ਕਦਮ: ਇੱਕ ਸਧਾਰਣ pincode-ਅਧਾਰਿਤ ਉਪਲਬਧਤਾ ਫਲੋ
ਖਰੀਦਦਾਰ ਦੇ ਜਜ਼ਬਾਤੀ ਤੌਰ 'ਤੇ ਚੈਕਆਊਟ ਲਈ ਬਹੁਤੀ ਮਸਤਿਸ਼ਕੀਆਂ ਵ੍ਹਾਈਂ ਨਾ ਕਰਨ, ਪਹਿਲਾਂ ਪਿੰਕੋਡ ਪੁੱਛੋ। ਇਹ ਫੀਲਡ ਪ੍ਰੋਡਕਟ ਪੇਜ ਅਤੇ ਫਿਰ ਕਾਰਟ 'ਤੇ ਰੱਖੋ, ਅਤੇ ਹਲਕਾ-ਫੁਲਕਾ ਵੈਧਤਾ (ਲੰਬਾਈ, ਸਿਰਫ ਅੰਕ) ਕਰੋ। ਜੇ ਇਹ ਗਲਤ ਲੱਗਦਾ ਹੈ, ਤੁਰੰਤ ਦੱਸੋ, ਚੈੱਕਆਊਟ ਤੱਕ ਇੰਤਜ਼ਾਰ ਨਾ ਕਰੋ।
ਜਦੋਂ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਵੈਧ ਪਿੰਕੋਡ ਹੈ, ਤਾਂ ਆਪਣੀ ਸਰਵਿਸੇਬਿਲਟੀ ਚੈੱਕ ਕਰੋ ਅਤੇ ਸੈਸ਼ਨ ਲਈ ਚੋਣ ਸੰਭਾਲ ਕੇ ਰੱਖੋ (ਤਤੇਸ਼/)। ਇਸਨੂੰ ਯੂਜ਼ਰ ਪ੍ਰੈਫਰੰਸ ਸਮਝੋ, ਇੱਕ ਵਾਰੀ ਦੀ ਐਨਟਰੀ ਨਹੀਂ, ਤਾਂ ਜੋ ਉਹ ਹਰ ਪੇਜ 'ਤੇ ਦੁਬਾਰਾ ਨਾ ਭਰੇ।
ਇੱਕ ਸਧਾਰਣ ਫਲੋ ਜੋ ਜ਼ਿਆਦਾਤਰ ਸਟੋਰਾਂ ਨੂੰ ਕਵਰ ਕਰਦਾ ਹੈ:
- ਪਹਿਲਾਂ ਪਿੰਕੋਡ ਕੈਪਚਰ ਅਤੇ ਵੈਧ ਕਰੋ, ਫਿਰ ਇਸਨੂੰ ਪੇਜਾਂ 'ਚ ਯਾਦ ਰੱਖੋ।
- ਸਰਵਿਸੇਬਿਲਟੀ ਚੈੱਕ ਕਰੋ ਅਤੇ ਉਸ ਪਿੰਕੋਡ ਲਈ ਇੱਕ ਡਿਲਿਵਰੀ ਜ਼ੋਨ ਅਲਾਟ ਕਰੋ।
- ਜ਼ੋਨ ਅਤੇ ਉਤਪਾਦ ਸੀਮਾਵਾਂ ਜਿਵੇਂ seller SLA, fragile handling, ਜਾਂ ਵੇਅਰਹਾਊਸ ਕਟਆਫ਼ ਦੇ ਆਧਾਰ 'ਤੇ ਇੱਕ ਡਿਲਿਵਰੀ ਵਾਅਦਾ ਰੇਂਜ ਬਣਾਓ।
- ਪਿੰਕੋਡ ਅਤੇ ਕਾਰਟ ਨਿਯਮਾਂ (ਆਰਡਰ ਮੁੱਲ ਸੀਮਾਵਾਂ, ਸ਼੍ਰੇਣੀ ਪ੍ਰਤਿ) ਨੂੰ ਵਰਤ ਕੇ COD ਯੋਗਤਾ ਨਿਰਣੇ ਕਰੋ।
- ਖੇਤਰੀ ਫੀਸਾਂ ਨੂੰ ਮੁੜ-ਗਣਨਾ ਕਰੋ ਅਤੇ ਆਰਡਰ ਸਮਰੀ ਅਪਡੇਟ ਕਰੋ ਤਾਂ ਜੋ ਟੋਟਲ ਉਹੀ ਹੋ ਜਿਹੜਾ ਯੂਜ਼ਰ ਚੈਕਆਊਟ 'ਤੇ ਵੇਖੇਗਾ।
ਆਖ਼ਿਰ ਵਿੱਚ, ਜਦੋਂ ਯੂਜ਼ਰ ਚੈਕਆਊਟ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ, ਤਾਂ ਵਾਅਦਾ ਲੌਕ ਕਰੋ। ਉਹੀ ETA, ਫੀਸਾਂ ਅਤੇ COD ਨਿਰਣੇ ਰੱਖੋ ਜਦ ਤੱਕ ਕਿ ਕੁਝ ਬਦਲਦਾ ਨਾ ਹੋਵੇ: ਪਿੰਕੋਡ, ਕਾਰਟ ਆਈਟਮ, ਮਾਤਰਾ, ਸ਼ਿਪਿੰਗ ਤਰੀਕਾ, ਜਾਂ ਐਡਰੈੱਸ ਕਿਸਮ (ਘਰ vs ਦਫ਼ਤਰ)। ਜੇ ਕਿਸੇ ਚੀਜ਼ ਤੱਬਦੀ ਹੈ, ਮੁਰਾਂ ਜਾਂ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਦੱਸੋ ਕਿਉਂ ਨਤੀਜਾ ਅਪਡੇਟ ਹੋਇਆ।
ਉਦਾਹਰਨ: ਕੋਈ 560001 ਪੇਜ 'ਤੇ ਦਰਜ ਕਰਦਾ ਹੈ। ਤੁਸੀਂ “Available to 560001” ਦਿਖਾਉਂਦੇ ਹੋ ਨਾਲ ETA ਰੇਂਜ ਅਤੇ COD ਦੀ ਸਥਿਤੀ। ਕਾਰਟ ਵਿੱਚ, ਜੇ ਉਹ ਇੱਕ ਭਾਰੀ ਆਈਟਮ ਜੋ ਵੱਖਰੇ ਸਥਾਨ ਤੋਂ ਭੇਜਿਆ ਜਾਂਦਾ ਜੋੜਦਾ ਹੈ, ਤਾਂ ETA ਉੱਥੇ ਹੀ ਅਪਡੇਟ ਹੋਵੇ, ਨਾਂ ਕਿ ਭੁਗਤਾਨ 'ਤੇ।
ਐਜ ਕੇਸ ਜਿਨ੍ਹਾਂ ਬਾਰੇ ਤੁਹਾਨੂੰ ਸ਼ੁਰੂ ਤੋਂ ਫੈਸਲਾ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ
ਜਿਆਦਾਤਰ ਡਿਲਿਵਰੀ ਅਤੇ ਭੁਗਤਾਨ ਨਿਯਮ ਠੀਕ ਕੰਮ ਕਰਦੇ ਹਨ ਜਦ ਤੱਕ ਪਹਿਲੀ “ਲਗਭਗ” ਘਟਨਾ ਨਹੀਂ ਆਉਂਦੀ। ਜੇ ਤੁਸੀਂ ਐਜ ਕੇਸ ਪਹਿਲਾਂ ਤੋਂ ਨਿਰਧਾਰਤ ਕਰ ਲੈਂਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਡਾ pincode-ਅਧਾਰਿਤ ਸੁਨੇਹਾ ਸਥਿਰ ਰਹਿੰਦਾ ਹੈ ਅਤੇ ਤੁਸੀਂ ਆਖ਼ਰੀ ਮੋੜ 'ਤੇ ਹੈਰਾਨੀਆਂ ਤੋਂ ਬਚ ਸਕਦੇ ਹੋ।
ਵੰਡੇ ਹੋਏ ਸ਼ਿਪਮੈਂਟ
ਵੰਡੇ ਹੋਏ ਸ਼ਿਪਮੈਂਟ ਸਭ ਤੋਂ ਆਮ ਹਨ। ਜੇ ਕਾਰਟ ਵਿੱਚ ਆਈਟਮ ਵੱਖ-ਵੱਖ ਵੇਅਰਹਾਊਸ ਤੋਂ ਭੇਜੇ ਜਾ ਰਹੇ ਹਨ, ਤਦ ਡਿਫਾਲਟ ਰੂਪ ਵਿੱਚ ਸਭ ਤੋਂ ਧੀਮੇ ETA ਨੂੰ ਦਿਖਾਓ ਅਤੇ ਇੱਕ ਛੋਟੀ ਨੋਟ ਸ਼ਾਮਲ ਕਰੋ: “Some items may arrive separately.” ਲੋਕ ਦੋ ਡਿਲਿਵਰੀਆਂ ਨੂੰ ਇੱਕ ਖੋਈ ਵਾਅਦੇ ਨਾਲੋਂ ਵਧੀਆ ਸਹਿਮਤ ਕਰ ਲੈਂਦੇ ਹਨ।
ਅੰਸ਼ਿਕ ਉਪਲਬਧਤਾ
ਜੇ ਇੱਕ ਆਈਟਮ ਉਸ ਪਿੰਕੋਡ 'ਤੇ ਸ਼ਿਪ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ, ਤਾਂ ਪੂਰੇ ਕਾਰਟ ਨੂੰ ਬਲਾਕ ਨਾ ਕਰੋ ਬਿਨਾਂ ਵਜ੍ਹੇ ਦੱਸੇ। ਖਰੀਦਦਾਰ ਨੂੰ ਦੱਸੋ ਕਿ ਕਿਹੜਾ ਆਈਟਮ ਬਲਾਕ ਹੈ ਅਤੇ ਕਿਉਂ (ਉਦਾਹਰਨ: “Restricted for this region” ਜਾਂ “Out of service area”)। ਫਿਰ ਇੱਕ ਸਧਾਰਣ ਅਗਲਾ ਕਦਮ ਦਿਓ: ਆਈਟਮ ਹਟਾਓ, ਪਿੰਕੋਡ ਬਦਲੋ, ਜਾਂ ਬਾਅਦ ਵਿੱਚ ਸੇਵ ਕਰੋ।
ਛੁੱਟੀਆਂ ਅਤੇ ਕਟਆਫ਼
ਛੁੱਟੀਆਂ ਅਤੇ ਰੋਜ਼ਾਨਾ ਕਟਆਫ਼ ਭਰੋਸਾ ਭੰਗ ਕਰ ਸਕਦੇ ਹਨ। ਨਿਰਣਾ ਕਰੋ ਕਿ ਖਰੀਦਦਾਰ ਨੂੰ ਕਿਹੜਾ ਸੁਨੇਹਾ ਦਿਖਾਵੋਗੇ ਜਦੋਂ ਉਹ ਕਟਆਫ਼ ਤੋਂ ਬਾਅਦ ਜਾਂ ਛੁੱਟੀ ਦਿਨ 'ਤੇ ਚੈੱਕ ਕਰਦਾ ਹੈ। “Ships next business day” ਇੱਕ ਨਾਮੁਨਕਿਨ ਮਿਤੀ ਦੀ ਤੁਲਨਾ ਵਿੱਚ ਵੱਧ ਸਪਸ਼ਟ ਹੈ।
ਐਡਰੈੱਸ ਬਦਲਾਅ
ਐਡਰੈੱਸ ਬਦਲਣ 'ਤੇ ਮੁੜ-ਚੈੱਕ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਨਾ ਕਿ ਸਿਰਫ ਚੈਕਆਊਟ 'ਤੇ। ਜਦੋਂ ਪਿੰਕੋਡ ਬਦਲਦਾ ਹੈ, ਤਾਂ ਕੀ ਬਦਲਿਆ ਉਸ ਨੂੰ ਹਾਈਲਾਈਟ ਕਰੋ ਤਾਂ ਕਿ ਇਹ ਰੈਂਡਮ ਨਾ ਲੱਗੇ। ਇੱਕ ਛੋਟੀ ਸੰਖੇਪ ਜਾਣਕਾਰੀ ਕਾਫ਼ੀ ਹੈ:
- ETA ਬਦਲਿਆ (ਜਲਦੀ ਜਾਂ ਦੇਰ)
- COD ਯੋਗਤਾ ਬਦਲੀ (ਉਪਲਬਧ ਜਾਂ ਨਹੀਂ)
- ਡਿਲਿਵਰੀ ਫੀਸ ਜਾਂ ਖੇਤਰੀ ਫੀਸ ਬਦਲੀ
ਰਿਟਰਨ ਅਤੇ ਬਦਲੀਆਂ
ਰਿਟਰਨ ਅਤੇ ਬਦਲੀਆਂ ਨੂੰ ਖੇਤਰੀ ਵਾਅਦੇ ਨਾਲ ਮਿਲਾਉਣਾ ਚਾਹੀਦਾ ਹੈ। ਜੇ ਕਿਸੇ ਪਿੰਕੋਡ ਲਈ COD ਦੀ ਆਗਿਆ ਨਹੀਂ, ਤਾਂ ਇਹ ਨਿਰਣਾ ਕਰੋ ਕਿ ਉੱਥੇ ਰਿਫੰਡ ਕਿਵੇਂ ਕਰਨਗੇ (ਬੈਂਕ ਟ੍ਰਾਂਸਫਰ, ਵਾਲਿਟ, ਕਾਰਡ ਰਿਵਰਸਲ) ਅਤੇ ਇਹੀ ਨਿਯਮ ਆਰਡਰ ਵੇਰਵੇ ਵਿੱਚ ਦਿੱਤਾ ਹੋਵੇ।
ਉਦਾਹਰਨ: ਕੋਈ 560001 ਦਰਜ ਕਰਦਾ ਹੈ ਅਤੇ ਵੇਖਦਾ ਹੈ “Delivery by Tue, COD available.” ਉਹ ਇੱਕ ਭਾਰੀ ਆਈਟਮ ਜੋ ਵੱਖਰੇ ਸਥਾਨ ਤੋਂ ਭੇਜਿਆ ਜਾਂਦਾ ਜੋੜਦਾ ਹੈ। ਤੁਹਾਡਾ ਸੁਨੇਹਾ ਅਪਡੇਟ ਹੋ ਕੇ “Delivery by Thu, some items ship separately” ਹੋ ਜਾਂਦਾ ਹੈ ਅਤੇ COD “Not available for this cart” ਤੇ ਫਿਰਦਾ ਹੈ। ਇਹ ਇਸ ਲਈ ਸੱਚਾ ਲੱਗਦਾ ਹੈ ਕਿਉਂਕਿ ਬਦਲਾਅ ਵਜ੍ਹੇ ਨਾਲ ਵਿਆਖਿਆ ਕੀਤੀ ਗਈ ਹੈ।
ਆਮ ਗਲਤੀਆਂ ਜਿਹੜੀਆਂ ਭਰੋਸਾ ਘਟਾਉਂਦੀਆਂ ਹਨ
Own the implementation
Get the full source code and keep building with your team’s workflow.
ਭਰੋਸਾ ਤੇਜ਼ੀ ਨਾਲ ਘਟ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਪ੍ਰੋਡਕਟ ਪੇਜ ਇੱਕ ਗੱਲ ਦਾ ਵਾਅਦਾ ਕਰਦਾ ਹੈ ਅਤੇ ਚੈਕਆਊਟ ਦੂਜਾ ਦਿਖਾਉਂਦਾ ਹੈ। ਜ਼ਿਆਦਾਤਰ ਖਰੀਦਦਾਰ ਪਹਿਲਾਂ ਦੱਸ ਦਿੱਤੀ ਪਾਬੰਦੀਆਂ ਨੂੰ ਮੰਨ ਲੈਂਦੇ ਹਨ ਜੇ ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਪਹਿਲਾਂ, ਸਧਾਰਣ ਭਾਸ਼ਾ ਵਿੱਚ ਦੱਸੋ ਅਤੇ ਨਿਯਮ ਇੱਕਸਾਰ ਰੱਖੋ।
ਇੱਕ ਆਮ ਸਮੱਸਿਆ ਇਹ ਹੈ ਕਿ “Delivery in 1 day” ਵਰਗਾ ਆਸਾ-ਪ੍ਰਧਾਨ ETA ਹਰ ਇੱਕ ਲਈ ਦਿਖਾਇਆ ਜਾ ਰਿਹਾ ਹੈ। ਉਹ ਆਮ ਤੌਰ 'ਤੇ ਸਰੇਸ਼ਠ-ਕੇਸ ਜ਼ੋਨ ਹੈ, ਨਾ ਕਿ ਖਰੀਦਦਾਰ ਦੇ ਅਸਲ ਪਿੰਕੋਡ ਲਈ। ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਸਿਰਫ਼ ਇੱਕ ਰੇਂਜ ਹੈ, ਤਾਂ ਇਹ ਦੱਸੋ। ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਕਈ ਕੈਰੀਅਰ ਹਨ, ਤਾਂ ਉਸ ਪਤੇ ਲਈ ਹਕੀਕਤੀ ਸਬ ਤੋਂ ਤੇਜ਼ ਵਿਕਲਪ ਦਿਖਾਓ, ਸਿਰਫ਼ ਹਾਈਲਾਈਟ ਨੰਬਰ ਨਹੀਂ।
ਇੱਕ ਹੋਰ ਭਰੋਸਾ-ਨੁਕਸਾਨ ਕਰਨ ਵਾਲੀ ਗਲਤੀਆਂ ਹੈ COD ਨਿਯਮਾਂ ਨੂੰ ਕੇਵਲ ਭੁਗਤਾਨ ਕਦਮ 'ਤੇ ਛੁਪਾ ਦੇਣਾ। ਲੋਕ ਅਕਸਰ ਸਾਮਾਨ ਚੁਣਦੇ ਸਮੇਂ ਮੰਨ ਲੈਂਦੇ ਹਨ ਕਿ COD ਉਪਲਬਧ ਹੋਵੇਗਾ, ਅਤੇ ਫਿਰ ਜਦੋਂ ਉਹ ਗਾਇਬ ਹੋ ਜਾਂਦਾ ਹੈ ਤਾਂ ਠੱਗਿਆ ਮਹਿਸੂਸ ਕਰਦੇ ਹਨ। ਜੇ COD ਪਿੰਕੋਡ, ਕਾਰਟ ਮੁੱਲ, ਉਤਪਾਦ ਕਿਸਮ, ਜਾਂ ਪਹਿਲੀ ਵਾਰ ਆਦੇਸ਼ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ, ਤਾਂ COD ਯੋਗਤਾ ਚੈੱਕ ਨੂੰ ਤੁਰੰਤ ਪਿੰਕੋਡ ਦਰਜ ਕਰਨ ਤੋਂ ਬਾਅਦ ਸਾਹਮਣੇ ਲਿਆਓ।
ਫੀਸਾਂ ਦੀਆਂ ਹੈਰਾਨੀਆਂ ਵੀ ਬਰਾਬਰ ਖਰਾਬ ਹਨ। ਸ਼ਿਪਿੰਗ, ਹੈਂਡਲਿੰਗ, ਅਤੇ ਭੁਗਤਾਨ ਫੀਸਾਂ ਆਖ਼ਰੀ ਸਕ੍ਰੀਨ 'ਤੇ ਇਸ ਲਈ ਨਹੀਂ ਬਦਲਣੀਆਂ ਚਾਹੀਦੀਆਂ ਕਿ ਖੇਤਰੀ ਨਿਯਮ ਗੁੰਮ ਰਹੇ ਸਨ ਜਾਂ ਦੇਰ ਨਾਲ ਲਾਗੂ ਕੀਤੇ ਗਏ। ਜੇ ਸਹੀ ਫੀਸਾਂ ਅਜੇ ਪਤਾ ਨਹੀਂ, ਤਾਂ ਇੱਕ ਸਪਸ਼ਟ ਅਨੁਮਾਨ ਦਿਖਾਓ ਅਤੇ ਕੀ ਬਦਲ ਸਕਦਾ ਹੈ ਦਸੋ (ਉਦਾਹਰਨ: ਦੂਰੇ ਖੇਤਰ ਦਾ ਸੁਰਚਾਰਜ)।
ਅਕਸਰ ਇਕੱਠੇ ਆਉਣ ਵਾਲੀਆਂ ਗਲਤੀਆਂ:
- ETA ਬੇਸ-ਕੇਸ ਜ਼ੋਨ ਦੇ ਆਧਾਰ ਤੇ ਦਿਖਾਈ ਗਈ ਨਾ ਕਿ ਦਰਜ ਪਿੰਕੋਡ ਦੇ ਅਧਾਰ 'ਤੇ
- COD ਸੀਮਾਵਾਂ ਕੇਵਲ ਭੁਗਤਾਨ ਕਦਮ 'ਤੇ ਖੁਲਾਸਾ ਕੀਤੀਆਂ ਗਈਆਂ
- ਫੀਸਾਂ ਆਖ਼ਰੀ ਕਦਮ 'ਤੇ ਬਦਲਦੀਆਂ ਕਿਉਂਕਿ ਖੇਤਰੀ ਨਿਯਮ ਦੇਰ ਨਾਲ ਲਾਗੂ ਹੋਏ
- ਕਾਰਟ ਬਦਲਣ 'ਤੇ ਮੁੜ-ਚੈੱਕ ਨਾ ਹੋਣਾ (ਵਜ਼ਨ, ਮੁੱਲ, ਰਿਸਟ੍ਰਿਕਟਿਡ ਆਈਟਮ)
- ਅਸਪਸ਼ਟ ਐਰਰਾਂ ਜਿਵੇਂ “Something went wrong” ਬਿਨਾਂ ਅਗਲੇ ਕਦਮ ਦੇ
ਸੁਨੇਹੇ ਕਾਰਵਾਈਯੋਗ ਰੱਖੋ। ਜਨਰਿਕ ਐਰਰ ਦੀ ਥਾਂ ਲੋਕਾਂ ਨੂੰ ਦੱਸੋ ਕੀ ਕਰਨ: “COD is not available for 560001. Choose prepaid or try another address.” ਨਿਰੰਤਰਤਾ ਪੂਰੀ ਤੋ ਤਕਨੀਕੀ ਨਿਖਰ ਤੋਂ ਜ਼ਿਆਦਾ ਮਹੱਤਵਪੂਰਨ ਹੈ: ਜਦੋਂ ਕਾਰਟ ਅਪਡੇਟ ਹੁੰਦਾ ਹੈ ਤਾਂ ਮੁੜ-ਚੈੱਕ ਕਰੋ, ਅਤੇ ਉਨ੍ਹਾਂੀ ਨਿਯਮਾਂ ਨੂੰ ਪ੍ਰੋਡਕਟ ਪੇਜ ਤੋਂ ਚੈਕਆਊਟ ਤੱਕ ਇੱਕਸਾਰ ਰੱਖੋ।
ਲਾਂਚ ਕਰਣ ਤੋਂ ਪਹਿਲਾਂ ਤੁਰੰਤ ਚੈਕਲਿਸਟ
ਇੱਕ ਖਰੀਦਦਾਰ ਵਾਂਗ ਅੰਤੀਮ ਜਾਂਚ ਕਰੋ। ਮੋਬਾਈਲ 'ਤੇ ਪ੍ਰੋਡਕਟ ਪੇਜ਼ ਖੋਲ੍ਹੋ, ਇੱਕ ਹੱਥ ਨਾਲ ਪਿੰਕੋਡ ਟਾਈਪ ਕਰੋ, ਅਤੇ ਦੇਖੋ ਕਿ ਵਾਅਦਾ 5 ਸਕਿੰਟ 'ਚ ਸਪਸ਼ਟ ਹੈ ਕਿ ਨਹੀਂ।
ਚੈਕਲਿਸਟ:
- ਕੀ ਖਰੀਦਦਾਰ ਪਿੰਕੋਡ ਚੈਕ ਨੂੰ ਪ੍ਰੋਡਕਟ ਪੇਜ ਅਤੇ ਕਾਰਟ 'ਤੇ ਆਸਾਨੀ ਨਾਲ ਲੱਭ ਸਕਦੇ ਹਨ, ਬਿਨਾਂ ਜ਼ਿਆਦਾ ਸਕ੍ਰੋਲਿੰਗ ਦੇ?
- ਪਿੰਕੋਡ ਦਰਜ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਕੀ ਤੁਸੀਂ ਇੱਕਠੇpromise ਦਿਖਾਉਂਦੇ ਹੋ: ਐਨ-ਸਟਾਕ ਜਾਂ ਨਹੀਂ, ਇੱਕ ETA ਰੇਂਜ, COD ਹਾਂ/ਨਹੀਂ, ਅਤੇ ਕੋਈ ਡਿਲਿਵਰੀ ਫੀਸ (ਜਾਂ ਮੁਫ਼ਤ ਡਿਲਿਵਰੀ)?
- ਜਦੋਂ ਖਰੀਦਦਾਰ ਪਿੰਕੋਡ ਬਦਲਦਾ ਹੈ, ਕੀ ਸੁਨੇਹਾ ਤੁਰੰਤ ਅਪਡੇਟ ਹੁੰਦਾ ਹੈ ਅਤੇ ਫਰਕ ਸਪਸ਼ਟ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ (ਉਦਾਹਰਨ: “COD not available” ਜਾਂ “Delivery in 5 to 7 days”) ਬਜਾਏ ਕਿ ਚੁਪਚਾਪ ਤਕਸਟ ਬਦਲਣ ਦੇ?
- ਜੇ ਖੇਤਰ ਸੇਵਾਜੋਗ ਨਹੀਂ, ਤਾਂ ਕੀ ਤੁਸੀਂ ਸਪਸ਼ਟ ਦੱਸਦੇ ਹੋ ਅਗਲੇ ਕਦਮ ਕੀ ਹਨ (ਆਈਟਮ ਹਟਾਉ, ਉਪਲਬਧ ਹੋਣ 'ਤੇ ਸੂਚਿਤ ਕਰੋ, ਪ੍ਰੀਪੇਡ ਚੁਣੋ, ਬਦਲ ਪਤਾ) ਨਾ ਕਿ ਯੂਜ਼ਰ ਨੂੰ ਫਸਾ ਛੱਡਦੇ ਹੋ?
- ਕੀ ਉਹੀ ਨਿਯਮ ਬਾਅਦ ਵਿੱਚ ਚੈਕਆਊਟ ਅਤੇ ਪੁਸ਼ਟੀ ਸੁਨੇਹੇ ਵਿੱਚ ਵੀ ਆਉਂਦੇ ਹਨ, ਤਾਂ ਕਿ ਆਖ਼ਰੀ ਕਦਮ 'ਤੇ ਵਾਅਦਾ ਨਾ ਬਦਲੇ?
ਮੁੱਢਲੀ ਗੱਲਾਂ ਪਾਸ ਹੋਣ ਤੋਂ ਬਾਅਦ, ਕੁਝ ਹਕੀਕਤੀ ਦ੍ਰਿਸ਼ਾਂ ਦੀ ਜਾਂਚ ਕਰੋ, ਸਿਰਫ ਖੁਸ਼ ਰਹਿਣ ਵਾਲਾ ਰਸਤਾ ਹੀ ਨਹੀਂ। ਇੱਕ ਮੈਟਰੋ ਪਿੰਕੋਡ, ਇੱਕ ਦੂਰ-ਦਰਾਜ਼ ਪਿੰਕੋਡ, ਅਤੇ ਇੱਕ ਜੋ COD ਲਈ ਬਲੌਕ ਹੈ, ਇਨ੍ਹਾਂ ਨੂੰ ਟੈਸਟ ਕਰੋ। ਦੋ ਆਈਟਮ ਜੋ ਵੱਖ-ਵੱਖ ਥਾਵਾਂ ਤੋਂ ਭੇਜੇ ਜਾਂਦੇ ਹਨ ਜੋੜੋ ਅਤੇ ਪੱਕਾ ਕਰੋ ਕਿ ETA ਅਤੇ ਫੀਸਾਂ ਸਮਝਣਯੋਗ ਹੀ ਰਹਿੰਦੀਆਂ ਹਨ।
ਟੀਮਾਂ ਵਿਚ ਸ਼ਬਦ-ਚੋਣ ਨੂੰ ਏਕ ਰੱਖੋ। ਜੇ ਤੁਹਾਡੀ ਕੋਰੀਅਰ ਡੇਟਾ ਕਹਿੰਦੀ ਹੈ “2 to 4 business days,” ਤਾਂ ਇਸਨੂੰ “Arrives by Friday” ਵਿੱਚ ਨਾਂ ਬਦਲੋ ਜੇ ਤੁਸੀਂਸਥਿਰ ਤੌਰ 'ਤੇ ਇਹ ਪੂਰਾ ਨਹੀਂ ਕਰ ਸਕਦੇ। ਪ੍ਰੋਡਕਟ ਪੇਜ 'ਤੇ ਇੱਕ ਵਾਅਦਾ ਅਤੇ ਭੁਗਤਾਨ 'ਤੇ ਦੂਜਾ ਦਿਖਾਉਣਾ ਭਰੋਸਾ ਖੋਣ ਦਾ ਸਭ ਤੋਂ ਤੇਜ਼ੀ ਭਰਾ ਤਰੀਕਾ ਹੈ।
ਇੱਕ ਅਸਲ ਉਦਾਹਰਨ: ਇੱਕ ਖਰੀਦਦਾਰ ਕਿਵੇਂ ਅਨੁਭਵ ਕਰਦਾ ਹੈ
Test it end to end
Deploy your prototype so product, cart, and checkout show the same promise.
Asha ਇੱਕ ਪ੍ਰੋਡਕਟ ਪੇਜ਼ 'ਤੇ ਆਉਂਦੀ ਹੈ ਇੱਕ ਜੋੜੇ ਦੌੜਣ ਵਾਲੇ ਜੁੱਤਿਆਂ ਲਈ। ਖਰੀਦਣ ਦੀ ਸੋਚ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਉਹ ਕੀਮਤ ਹੇਠਾਂ ਇੱਕ ਸਧਾਰਣ ਪਿੰਕੋਡ ਬਾਕਸ ਵੇਖਦੀ ਹੈ। ਉਹ 560001 ਦਰਜ ਕਰਦੀ ਹੈ।
ਪੇਜ਼ ਤੁਰੰਤ ਅਪਡੇਟ ਹੁੰਦਾ ਹੈ: “Delivery in 2-4 days. COD available.” ਕੋਈ ਲੰਬਾ ਛਪਿਆ ਨੋਟ ਨਹੀਂ, ਕੋਈ ਛੁਪੇ ਹੋਏ ਨਿਯਮ ਨਹੀਂ। ਹੁਣ ਉਹ ਜਾਣਦੀ ਹੈ ਕਿ ਆਈਟਮ ਉਸ ਤੱਕ ਪਹੁੰਚ ਸਕਦਾ ਹੈ, ਢੰਗ ਨਾਲ ਕਦੋਂ, ਅਤੇ ਨਗਦ ਭੁਗਤਾਨ ਇੱਕ ਵਿਕਲਪ ਹੈ।
ਉਹ ਜੁੱਤੇ ਕਾਰਟ ਵਿੱਚ ਜੋੜਦੀ ਹੈ, ਬਰਾਊਜ਼ ਕਰਦੀ ਰਹਿੰਦੀ ਹੈ, ਅਤੇ ਇੱਕ ਦੂਜਾ ਆਈਟਮ ਜੋੜਦੀ ਹੈ: ਇੱਕ ਸਕਿਨਕੇਅਰ ਸੈੱਟ ਜੋ ਵੱਖਰੇ ਵਿਕਰੇਤਾ ਵੱਲੋਂ ਵਿੱਕਣ ਵਾਲਾ ਹੈ। ਕਾਰਟ ਦੁਬਾਰਾ ਗਿਣਤਾ ਹੈ ਅਤੇ ਹਰ ਆਈਟਮ ਦੇ ਨੇੜੇ ਇੱਕ ਛੋਟਾ, ਸਪਸ਼ਟ ਅਪਡੇਟ ਦਿਖਾਉਂਦਾ ਹੈ। ਜੁੱਤੇ ਹੋਰ ਹੀ ਰਹਿੰਦੇ ਹਨ: “2-4 days, COD available.” ਸਕਿਨਕੇਅਰ ਸੈੱਟ ਦਿਖਾਉਂਦਾ “3-5 days, COD not available.” ਇੱਕ ਛੋਟਾ ਨੋਟ ਕਾਰਨ ਦੱਸਦਾ ਹੈ: “COD not supported for this item in your area.”
ਫੀਸਾਂ ਵੀ ਇੱਕੋ ਸਮੇਂ ਅਪਡੇਟ ਹੁੰਦੀਆਂ ਹਨ। ਕਾਰਟ ਸਕਿਨਕੇਅਰ ਸੈੱਟ ਲਈ ਇੱਕ ਡਿਲਿਵਰੀ ਫੀਸ ਦਿਖਾਂਦਾ ਹੈ, ਅਤੇ ਕੁੱਲ ਰਕਮ ਤੁਰੰਤ ਬਦਲ ਜਾਂਦੀ ਹੈ। ਕਿਉਂਕਿ ਉਹ ਪਹਿਲੇ ਹੀ ਪੂਰੀ ਕੀਮਤ ਅਤੇ ਭੁਗਤਾਨ ਵਿਕਲਪ ਵੇਖ ਸਕਦੀ ਹੈ, ਉਹ ਆਨਲਾਈਨ ਭੁਗਤਾਨ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕਰਦੀ ਹੈ ਅਤੇ ਅੱਗੇ ਵੱਧਦੀ ਹੈ।
ਚੈਕਆਊਟ 'ਚ ਕੁਝ ਵੀ ਬਦਲਦਾ ਨਹੀਂ। ਉਹੀ ਡਿਲਿਵਰੀ ਵਾਅਦੇ ਅਤੇ COD ਨਿਯਮ ਦੁਬਾਰਾ ਦਿਖਾਏ ਜਾਂਦੇ ਹਨ, ਜੋ ਉਸਨੇ ਪਹਿਲਾਂ ਪ੍ਰੋਡਕਟ ਪੇਜ ਅਤੇ ਕਾਰਟ 'ਚ ਵੇਖੇ ਸਨ। ਭੁਗਤਾਨ 'ਤੇ ਕੋਝ-ਮੋਟ ਨਹੀਂ ਆਉਂਦੀ ਕਿ “COD not eligible.”
ਇਹੀ pincode-ਅਧਾਰਿਤ ਡਿਲਿਵਰੀ ਸੁਨੇਹੇ ਦਾ ਮਕਸਦ ਹੈ: ਉਮੀਦਾਂ ਪਹਿਲਾਂ ਸੈਟ ਕਰੋ, ਉਨ੍ਹਾਂ ਨੂੰ ਇੱਕਸਾਰ ਰੱਖੋ, ਅਤੇ ਉਹ ਹੈਰਾਨੀ ਦੇ ਪੜਾਵਾਂ ਹਟਾਓ ਜੋ ਲੋਕਾਂ ਨੂੰ ਆਖ਼ਰੀ ਸਮੇਂ ਕਾਰਟ ਛੱਡਣ ਲਈ ਮਜਬੂਰ ਕਰਦੇ ਹਨ।
ਅਗਲੇ ਕਦਮ: ਨਿਯਮਾਂ ਨੂੰ ਕਾਰਗਰ ਤਜ਼ਰਬੇ ਵਿੱਚ ਬਦਲੋ
ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਆਪਣੇ ਵਿਚਾਰਾਂ ਨੂੰ ਲਿਖਤ ਨਿਯਮਾਂ ਵਿੱਚ ਬਦਲੋ। ਜੇ ਨਿਯਮ ਸਿਰਫ਼ ਲੋਕਾਂ ਦੇ ਮਨ ਵਿੱਚ ਹਨ, ਤਾਂ UI ਭਟਕ ਜਾਵੇਗਾ, ਅਤੇ ਗਾਹਕ ਨੋਟਿਸ ਕਰਨਗੇ। ਦੱਸੋ ਕਿ “serviceable” ਦਾ ਕੀ ਮਤਲਬ ਹੈ, ਤੁਸੀਂ ETA ਕਿਵੇਂ ਚੁਣਦੇ ਹੋ, COD ਕਦੋਂ ਮਨਜ਼ੂਰ ਹੈ, ਅਤੇ ਖੇਤਰੀ ਤੌਰ 'ਤੇ ਫੀਸ ਕਿਵੇਂ ਬਦਲਦੀਆਂ ਹਨ।
ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਤਰੀਕ ਇਹ ਹੈ ਕਿ ਤੱਥਾਂ ਨੂੰ ਫੈਸਲਾਂ ਤੋਂ ਵੱਖ ਕਰੋ। ਤੱਥ ਉਹ ਹਨ ਜੋ ਤੁਸੀਂ ਲੁੱਕ ਅਪ ਕਰਦੇ ਹੋ (ਕੈਰੀਅਰ ਕਵਰੇਜ, ਵੇਅਰਹਾਊਸ ਸਟਾਕ, pin-to-zone मैਪ), ਫੈਸਲੇ ਉਹ ਹਨ ਜੋ ਤੁਸੀਂ ਪੇਜ਼ 'ਤੇ ਵਾਅਦਾ ਕਰਦੇ ਹੋ (ਉਪਲਬਧ/ਨਹੀਂ, ETA ਰੇਂਜ, COD ਹਾਂ/ਨਹੀਂ, ਵਾਧੂ ਖ਼ਰਚ)।
ਜਲਦੀ ਵਿੱਚ “ਪਰਯਾਪਤ” ਕਿਹੜਾ ਹੈ, ਇਹ ਪਰਭਾਸ਼ਿਤ ਕਰੋ
ਤੁਹਾਨੂੰ ਪ੍ਰੋਡਕਟ ਪੇਜ 'ਤੇ ਸੰਪੂਰਨਤਾ ਦੀ ਲੋੜ ਨਹੀਂ। ਤੁਹਾਨੂੰ ਹੈਰਾਨੀਆਂ ਘਟਾਉਣੀਆਂ ਹਨ। ਜਦੋਂ ਲੋੜ ਹੋਵੇ, ਰੇਂਜ ਵਰਤੋ (ਉਦਾਹਰਨ: “Delivers in 3-5 days”) ਅਤੇ ਇਹ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਵਾਅਦਾ ਚੈਕਆਊਟ ਨਾਲ ਮਿਲਦਾ ਹੈ। ਜੇ ਸਿਸਟਮ ਅਣਿਸ਼ਚਿਤ ਹੈ, ਤਾਂ ਸਪਸ਼ਟ ਦੱਸੋ (“ETA confirmed at checkout”) ਬਜਾਏ ਕਿ ਅਨੁਮਾਨ ਲਗਾਉਣ ਦੇ।
ਉਹ ਮੋਮੈਂਟ ਮਾਪੋ ਜੋ ਗੱਲ ਬਣਾਉਂਦੇ ਹਨ
ਸ਼ਿਪ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਕੁਝ ਮੁੱਖ ਟਰੇਕਿੰਗ ਸ਼ਾਮਲ ਕਰੋ ਤਾਂ ਤੁਸੀਂ ਵੇਖ ਸਕੋ ਕਿ ਲੋਕ ਕਿੱਥੇ ਘੁਮਦੇ ਹਨ ਅਤੇ ਕਿੱਥੇ ਵਾਅਦੇ ਫੇਲ ਹੋ ਰਹੇ ਹਨ:
- Pincode entered (ਅਤੇ ਕੀ ਇਹ ਵੈਧ ਫਾਰਮੈਟ ਨੂੰ ਮਿਲਦਾ ਸੀ)
- Promise shown (availability, ETA range, COD status, fees)
- Pincode changed after viewing the promise
- Checkout started after seeing the promise
- Checkout blocked due to a rule change (ਉਦਾਹਰਨ: COD removed)
ਰਿਸਕ ਘਟਾਉਣ ਲਈ ਫੇਜ਼ ਵਾਈਜ਼ ਰੋਲ ਆਫ਼ ਕਰੋ। ਪਹਿਲਾਂ “Deliverable + ETA range” ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਕਿਉਂਕਿ ਇਹ ਜ਼ਿਆਦਾਤਰ ਹੈਰਾਨੀਆਂ ਹੱਲ ਕਰਦਾ ਹੈ। ਫਿਰ COD ਯੋਗਤਾ ਚੈੱਕ ਸ਼ਾਮਲ ਕਰੋ, ਫਿਰ ਖੇਤਰੀ ਫੀਸਾਂ ਅਤੇ ਕੀਮਤ ਵੇਰਵੇ। ਹਰ ਫੇਜ਼ ਲਈ ਅਣਜਾਣ ਮਾਮਲਿਆਂ ਦਾ ਸਪਸ਼ਟ ਬੈਕਅਪ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ ਤੁਰੰਤ ਬਣਾਉਣਾ ਅਤੇ ਦੁਹਰਾਉਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਇੱਕ vibe-coding ਪਲੇਟਫਾਰਮ ਜਿਵੇਂ Koder.ai ਤੁਹਾਨੂੰ ਚੈਟ ਇੰਟਰਫੇਸ ਤੋਂ ਇੱਕ ਅੰਤ ਤੇ ਅੰਤ ਤੱਕ ਫਲੋ ਪ੍ਰੋਟੋਟਾਈਪ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ React UI module ਲਈ pincode check ਅਤੇ Go backend ਨਾਲ PostgreSQL ਨਿਯਮਾਂ ਨੂੰ ਸਟੋਰ ਕਰਨ ਦੀ ਯੋਗਤਾ ਸ਼ਾਮਲ ਹੈ। Snapshots ਅਤੇ rollback ਵੀ ਤਾਜ਼ਾ ਕੋਰੀਅਰ ਅਤੇ ਭੁਗਤਾਨ ਡੇਟਾ ਦੇ ਖਿਲਾਫ਼ ਲਾਜਿਕ ਅਨੁਕੂਲ ਕਰਨ ਵੇਲੇ ਮਦਦਗਾਰ ਹੁੰਦੇ ਹਨ।
ਅਕਸਰ ਪੁੱਛੇ ਜਾਣ ਵਾਲੇ ਸਵਾਲ
What information should I show after a shopper enters their pincode?
Show the four things shoppers care about most, right after they enter a pincode:
- Availability: deliverable or not, plus any item-specific restriction
- ETA: a realistic range (e.g., “2–4 days”)
- COD: available/not available, plus the one key rule if limited
- Fees: shipping/COD fees and any minimum order threshold
If you can’t compute something yet, say what’s confirmed now and what will be confirmed later.
Where should the pincode check live—product page, cart, or checkout?
Put it where it affects the buy decision, not as a hidden condition.
- Product page (highest impact): near price and Add to Cart
- Cart: repeat the same promise in one combined summary
- Checkout: restate only—don’t introduce new rules
Also keep the chosen pincode visible (e.g., “Delivering to 560001”) so people know what location you’re using.
Why do pincode-based messages reduce checkout abandonment?
Because checkout is where users feel most “locked in.” If they learn late that delivery isn’t possible, the ETA is worse, COD disappears, or fees increase, it feels like the rules changed.
Showing pincode-based answers early reduces:
- Cart abandonment
- Post-order cancellations
- “Why didn’t you tell me?” support tickets
How do I show ETA without overpromising?
Default to ranges, not exact dates.
- Prefer “Delivers in 2–4 days” over “Arrives Tuesday”
- Add a cutoff note only if it changes behavior (e.g., “Order before 4pm for same-day dispatch”)
- If you’re uncertain, say “ETA confirmed at checkout” instead of guessing
A slightly wider range you consistently hit builds more trust than a tight promise you miss.
How should I explain COD eligibility without annoying users?
Show COD status immediately after the pincode check and keep it simple:
- “COD available” (optionally add “up to ₹5,000”)
- or “COD not available” + one clear reason/rule (value limit, category restriction, pincode risk)
Avoid revealing COD restrictions only on the payment step—that’s one of the biggest sources of surprise.
How do I display region-based fees without causing fee shock?
Show what truly changes by location and keep it readable:
- Shipping fee (or free shipping threshold)
- COD fee (if any)
- Any remote area surcharge or minimum order rule
If you can’t calculate exact tax/fees yet, don’t invent numbers. Use wording like:
- “Estimated at checkout (final amount depends on address details)”
What should I show if I can’t compute an ETA yet?
Pick a clear fallback and keep the UI consistent:
- Confirm delivery availability without a date, or show a conservative range
- Ask for more input only when necessary (e.g., “Enter full address at checkout for exact ETA”)
- If blocked, show a specific reason (item restriction, pincode not served, COD rule)
The key is to avoid blank states or vague errors that leave the shopper stuck.
What data do I need behind the scenes to make these messages accurate?
Create one shared “source of truth” for each rule so product page, cart, and checkout don’t disagree:
- Pincode → zone/serviceability (Ops/Logistics)
- Product constraints (Catalog/Fulfillment)
- COD rules (Payments/Risk)
- Shipping/COD fees and thresholds (Finance/Growth)
- Inventory and cutoffs (Warehouse Ops)
Even a small internal API that returns availability/ETA/COD/fees for a pincode + cart can prevent inconsistent messaging.
How do I handle split shipments and partial availability in the cart?
Default to clarity and next actions:
- Split shipments: show the slowest ETA as the default and note “Some items may arrive separately.”
- Partial availability: identify the blocked item and offer actions (remove item, change pincode, save for later).
- Holidays/cutoffs: use “Ships next business day” when appropriate.
- Pincode/address changes: re-check and highlight what changed (ETA, COD, fee).
This prevents shoppers from feeling like things changed “randomly.”
What’s the simplest implementation plan for a pincode-based delivery promise?
Build it as one reusable flow so the same promise appears everywhere:
- Validate pincode (digits/length) and store it for the session
- Call a single service to return: availability, ETA range, COD eligibility, fees
- Re-check when the cart changes (items, quantity, value) or when the pincode changes
- “Lock” the promise when checkout starts, and only change it if inputs change
If you’re prototyping, a vibe-coding platform like Koder.ai can help you ship a React UI for the pincode box plus a Go/PostgreSQL rules service quickly, with snapshots/rollback when you adjust logic.