KoderKoder.ai
ਕੀਮਤਾਂਐਂਟਰਪ੍ਰਾਈਜ਼ਸਿੱਖਿਆਨਿਵੇਸ਼ਕਾਂ ਲਈ
ਲੌਗ ਇਨਸ਼ੁਰੂ ਕਰੋ

ਉਤਪਾਦ

ਕੀਮਤਾਂਐਂਟਰਪ੍ਰਾਈਜ਼ਨਿਵੇਸ਼ਕਾਂ ਲਈ

ਸਰੋਤ

ਸਾਡੇ ਨਾਲ ਸੰਪਰਕ ਕਰੋਸਹਾਇਤਾਸਿੱਖਿਆਬਲੌਗ

ਕਾਨੂੰਨੀ

ਗੋਪਨੀਯਤਾ ਨੀਤੀਵਰਤੋਂ ਦੀਆਂ ਸ਼ਰਤਾਂਸੁਰੱਖਿਆਸਵੀਕਾਰਯੋਗ ਵਰਤੋਂ ਨੀਤੀਦੁਰਵਰਤੋਂ ਦੀ ਰਿਪੋਰਟ ਕਰੋ

ਸੋਸ਼ਲ

LinkedInTwitter
Koder.ai
ਭਾਸ਼ਾ

© 2026 Koder.ai. ਸਾਰੇ ਅਧਿਕਾਰ ਰਾਖਵੇਂ ਹਨ।

ਹੋਮ›ਬਲੌਗ›ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਸਕਿਪ, ਪੌਜ਼ ਅਤੇ ਐਡਰੈੱਸ ਬਦਲਾਅ: ਨਿਯਮ ਅਤੇ ਯੂਆਈ
03 ਨਵੰ 2025·8 ਮਿੰਟ

ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਸਕਿਪ, ਪੌਜ਼ ਅਤੇ ਐਡਰੈੱਸ ਬਦਲਾਅ: ਨਿਯਮ ਅਤੇ ਯੂਆਈ

ਜਦ ਨਿਯਮ ਸਪਸ਼ਟ ਹੋਣ, ਯੂਆਈ ਪੂਰਵਾਨੁਮਾਨਯੋਗ ਹੋਵੇ ਅਤੇ ਏਜ ਕੇਸ ਪਹਿਲਾਂ ਹੱਲ ਕੀਤੇ ਜਾਣ, ਤਾਂ ਸਕਿਪ, ਪੌਜ਼ ਅਤੇ ਐਡਰੈੱਸ ਬਦਲਾਅ ਚਰਨ ਅਤੇ ਸਪੋਰਟ ਲੋਡ ਘਟਾ ਸਕਦੇ ਹਨ।

ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਸਕਿਪ, ਪੌਜ਼ ਅਤੇ ਐਡਰੈੱਸ ਬਦਲਾਅ: ਨਿਯਮ ਅਤੇ ਯੂਆਈ

ਕਿਉਂ ਇਹ ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਨਿਯੰਤਰਣ ਰੀਟੇਨਸ਼ਨ ਨੂੰ ਬਣਾਉਂਦੇ ਜਾਂ ਤੋੜਦੇ ਹਨ

ਇਕ ਖਪਤਯੋਗ ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਓਦੋਂ ਹੀ ਚਲਦਾ ਹੈ ਜਦ ਲੋਕ ਲੰਮੇ ਸਮੇਂ ਲਈ ਰੁਕਣ ਵਿੱਚ ਸੁਰੱਖਿਅਤ ਮਹਿਸੂਸ ਕਰਨ। ਇਹ ਗੱਲ ਪ੍ਰੋਟੀਨ ਪਾਊਡਰ, ਵਿੱਟਾਮਿਨ, ਕੌਫੀ, ਰੇਜ਼ਰ ਰੀਫਿਲ ਜਾਂ ਸਕਿੰਕੇਅਰ—ਹਰ ਕਿਸੇ ਲਈ ਸਚ ਹੈ। ਲੋਕ ਹਰ ਮਹੀਨੇ ਆਪਣੀਆਂ ਲੋੜਾਂ ਬਦਲਦੇ ਹਨ, ਅਤੇ ਉਹ ਤੁਹਾਨੂੰ ਇਸ ਅਧਾਰ ’ਤੇ ਅੰਕਿਤ ਕਰਦੇ ਹਨ ਕਿ ਢਾਲਨਾ ਕਿੰਨੀ ਆਸਾਨ ਹੈ।

ਜਦੋਂ ਸਕਿਪ, ਪੌਜ਼ ਅਤੇ ਐਡਰੈੱਸ ਐਡਿਟ ਰਿਸਕੀ ਮਹਿਸੂਸ ਹੁੰਦੇ ਹਨ ਤਾਂ ਉਨ੍ਹਾਂ ਤੋਂ ਚਰਨ ਬਣਦਾ ਹੈ। ਜੇ ਗਾਹਕੀਂ ਨੂੰ ਪਤਾ ਨਹੀਂ ਕਿ ਬਦਲਾਅ ਅਗਲੇ ਚਾਰ्ज ਤੋਂ ਪਹਿਲਾਂ “ਟਿਕੇਗਾ” ਜਾਂ ਨਹੀਂ, ਤਾਂ ਉਹ ਅਜ਼ਮਾਇਸ਼ ਕਰਨ ਦੀ ਥਾਂ ਰੱਦ ਕਰ ਦੇਂਦੇ ਹਨ। ਜੇ ਉਹ ਡਰਦੇ ਹਨ ਕਿ ਆਰਡਰ ਗਲਤ ਥਾਂ ਭੇਜਿਆ ਜਾਵੇਗਾ ਜਾਂ ਉਹ ਗੈਰਹਾਜ਼ਿਰ ਹੋਣ ਸਮੇਂ ਆ ਜਾਵੇਗਾ, ਤਾਂ ਉਹ ਤਣਾਅ ਤੋਂ ਬਚਣ ਲਈ ਰੱਦ ਕਰਦੇ ਹਨ।

"ਸਪੋਰਟ ਕਾਓਸ" ਉਦਾਹਰਨ ਉਹ ਹੈ ਜਦ ਨਿਯਮ ਅਸਪਸ਼ਟ ਹੋਣ ਅਤੇ ਯੂਆਈ ਨਤੀਜੇ ਛੁਪਾਉਂਦਾ ਹੋਵੇ। ਇਹ ਅਕਸਰ ਬਿੱਲਿੰਗ ਅਤੇ ਫਲਫਿਲਮੈਂਟ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਤੇਜ਼ੀ ਨਾਲ ਉੱਭਰਦਾ ਹੈ।

ਆਮ ਲੱਛਣ ਐਸੇ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ:

  • ਗਾਹਕਾਂ ਦੀ ਈਮੇਲ “ਕਿਰਪਾ ਕਰਕੇ ਮੇਰਾ ਅਗਲਾ ਬਾਕਸ ਰੋਕੋ” ਜਾਂ ਚਾਰਜ ਹੋ ਚੁੱਕਣ ਤੋਂ ਬਾਅਦ
  • ਡੁਪ্লਿਕੇਟ ਸ਼ਿਪਮੈਂਟ ਕਿਉਂਕਿ ਗਾਹਕ ਨੇ ਸਕਿਪ ਕੀਤਾ ਪਰ ਸਿਸਟਮ ਨੇ ਹਾਲੇ ਵੀ ਆਰਡਰ ਬਣਾਇਆ
  • ਐਡਰੈੱਸ ਬਦਲਾਅ ਦੀਆਂ ਬੇਨਤੀਆਂ ਸੈਲਫ-ਸਰਵ ਦੀ ਥਾਂ ਸਪੋਰਟ ਨੂੰ ਭੇਜੀਆਂ ਗਈਆਂ
  • ਅਚਾਨਕ ਡਿਲਿਵਰੀਆਂ ਤੋਂ ਬਾਅਦ ਰੀਫੰਡ ਦੀਆਂ ਮੰਗਾਂ, ਚਾਰਜਬੈਕ, ਅਤੇ ਗੁੱਸੇ ਭਰੇ ਰਿਵਿਊਜ਼
  • ਏਜੰਟ ਨੀਤੀ ਸਮਝਾਉਂਦੇ ਸਮੇਂ ਬਹੁਤ ਵਕਤ ਗੁਜ਼ਾਰਦੇ ਹਨ ਬਜਾਏ ਅਸਲੀ ਏਜ ਕੇਸ ਹੱਲ ਕਰਨ ਦੇ

ਮਕਸਦ ਸਾਫ਼ ਹੈ: ਬਦਲਾਅ ਸੈਲਫ-ਸਰਵ ਹੋਣ ਅਤੇ ਪੂਰਵਾਨੁਮਾਨਯੋਗ ਹੋਣ। ਪੂਰਵਾਨੁਮਾਨਯੋਗ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਗਾਹਕ ਬਿਨਾਂ ਅਨੁਮਾਨ लगाए ਤਿੰਨ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਦੇ ਸਕੇ: ਕੀ ਹੋਵੇਗਾ, ਕਦੋਂ ਹੋਵੇਗਾ, ਅਤੇ ਇਸ ਦੀ ਕੀ ਕੀਮਤ ਹੋਵੇਗੀ।

ਇਸ ਲਈ “ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਸਕਿਪ ਪੌਜ਼ ਅਤੇ ਐਡਰੈੱਸ ਬਦਲਾਅ” ਨੂੰ ਸਿਰਫ਼ ਵਾਧੂ ਸੈਟਿੰਗਾਂ ਵਜੋਂ ਨਹੀਂ ਦੇਖਣਾ ਚਾਹੀਦਾ। ਇਹ ਰੀਟੇਨਸ਼ਨ ਨਿਯੰਤਰਣ ਹਨ। ਜਦੋਂ ਇਹ ਸਪਸ਼ਟ ਹੁੰਦੇ ਹਨ, ਗਾਹਕ ਇੱਕ ਵਿਅਸਤ ਮਹੀਨੇ ਲਈ ਪਹਿਲਾਂ ਰੱਦ ਕਰਨ ਦੀ ਥਾਂ ਪੌਜ਼ ਕਰ ਲੈਂਦੇ ਹਨ। ਜਦੋਂ ਇਹ ਗੁੰਝਲਦਾਰ ਹੁੰਦੇ ਹਨ, ਹਰ ਜੀਵਨ ਘਟਨਾ (ਸਫਰ, ਮੁਵਿੰਗ, ਨਵਾਂ ਫਲੇਵਰ ਟ੍ਰਾਈ ਕਰਨਾ, ਬਜਟ ਕੱਸਣਾ) ਰੱਦ ਕਰਨ ਦਾ ਮੌਕਾ ਬਣ ਜਾਂਦੀ ਹੈ।

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

ਯੂਆਈ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਜੋ ਨਿਯਮ ਤੁਸੀਂ ਤੈਅ ਕਰਨੇ ਹਨ

ਇਕ ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਸਕ੍ਰੀਨ ਇਸ ਤੋਂ ਜ਼ਿਆਦਾ ਸਪਸ਼ਟ ਨਹੀਂ ਹੋ ਸਕਦੀ ਜਿੰਨੇ ਸਪਸ਼ਟ ਨਿਯਮ ਪਿੱਛੇ ਹਨ। ਜੇ ਤੁਸੀਂ ਨਿਯਮਾਂ ਦੀ ਲਿਖਤ ਛੱਡ ਦਿੰਦੇ ਹੋ, ਗਾਹਕ ਅਨੁਮਾਨ ਲਗਾਉਂਦੇ ਹਨ, ਹੈਰਾਨ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਸਪੋਰਟ ਨੂੰ ਸੰਪਰਕ ਕਰਦੇ ਹਨ।

ਆਪਣੀਆਂ ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਟਰਮਜ਼ ਨੂੰ ਸਾਫ਼ ਭਾਸ਼ਾ ਵਿੱਚ ਲਿਖੋ ਜੋ ਗਾਹਕ ਦੁਹਰਾ ਸਕੇ। ਅੰਦਰੂਨੀ ਸ਼ਬਦਾਵਲੀ ਜਿਵੇਂ “billing cadence” ਜਾਂ “fulfillment batch” ਵਰਗੇ ਇਸ਼ਤਿਹਾਰ ਨਾ ਕਰੋ। ਲੋਕਾਂ ਨੂੰ ਸਮੇਂ ਦਾ ਇੱਕ ਸਾਦਾ ਮੈਨਟਲ ਮਾਡਲ ਚਾਹੀਦਾ ਹੈ ਕਿ ਅਗਲੇ ਕੀ ਹੋਵੇਗਾ।

ਘੱਟੋ-ਘੱਟ ਪਰਿਭਾਸ਼ਾਵਾਂ ਜੋ ਲਾਕ ਕਰਨੀਆਂ ਹਨ:

  • Cycle: ਆਰਡਰ ਕਿੰਨੇ ਅੰਤਰਾਲ 'ਤੇ ਦੁਹਰਾਇਆ ਜਾਂਦਾ ਹੈ (ਹਰ 4 ਹਫ਼ਤੇ, 15 ਤਾਰੀਖ ਨੂੰ ਮਾਸਿਕ ਆਦਿ)
  • Cutoff: ਉਹ ਆਖਰੀ ਸਮਾਂ ਜਦ ਬਦਲਾਅ ਅਗਲੇ ਆਰਡਰ 'ਤੇ ਪ੍ਰਭਾਵ ਪਾਵੇਗਾ
  • Next ship date: ਅਗਲਾ ਬਾਕਸ ਕਦੋਂ ਭੇਜਿਆ ਜਾਣ ਦੀ ਉਮੀਦ ਹੈ (ਸਿਰਫ ਚਾਰਜ ਨਹੀਂ)
  • Next charge date (ਜੇ ਵੱਖ ਹੈ): ਭੁਗਤਾਨ ਕਦੋਂ ਕੈਪਚਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ
  • Eligible changes: ਕੀ-ਕੀ ਸੋਧ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ (ਆਈਟਮ, ਮਾਤਰਾ, ਐਡਰੈੱਸ, ਤਾਰੀਖ)

ਅਗਲੇ, ਉਹ ਕਾਰਵਾਈਆਂ ਵੱਖ ਕਰੋ ਜੋ ਇੱਕੋ ਜਿਹੀਆਂ ਲੱਗਦੀਆਂ ਹਨ ਪਰ ਵੱਖ ਵਿਹਾਰ ਕਰਦੀਆਂ ਹਨ। ਗਾਹਕ ਉਮੀਦ ਕਰਦੇ ਹਨ ਕਿ “Skip”, “Pause”, ਅਤੇ “Cancel” ਵੱਖ-ਵੱਖ ਹੋਣਗੇ, ਇਸ ਲਈ ਤੁਹਾਡਾ ਪ੍ਰੋਡਕਟ ਵੀ ਉਹਨਾਂ ਨੂੰ ਅਲੱਗ ਟਰੀਟ ਕਰੇ।

  • Skip = ਸਿਰਫ ਅਗਲਾ ਆਰਡਰ ਸਕਿਪ ਕਰੋ, ਫਿਰ ਆਪਮਾਤਰ ਮੁੜ ਚੱਲ ਪਏਗਾ
  • Pause = ਭਵਿੱਖ ਦੇ ਆਰਡਰ ਰੋਕੋ ਤਾਂਕਿ ਨਿਰਧਾਰਤ ਤਾਰੀਖ ਤੱਕ ਜਾਂ ਜਦ ਗਾਹਕ ਮੁੜ ਚਾਲੂ ਕਰੇ
  • Cancel = ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਖਤਮ ਕਰੋ (ਪਰ ਇਹ ਪਰਿਭਾਸ਼ਾ ਕਰੋ ਕਿ ਕੀ ਇਹ ਸਿਰਫ ਭਵਿੱਖ ਦੇ ਆਰਡਰ ਰੋਕਦਾ ਹੈ ਜਾਂ ਪਹਿਲਾਂ ਤੋਂ ਤਿਆਰ ਕਿਸੇ ਅਜੇਕਾ ਆਰਡਰ ਨੂੰ ਵੀ ਰੋਕਦਾ ਹੈ)

ਹੁਣ ਇਹ ਵੀ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ ਕਿ ਐਡਰੈੱਸ ਬਦਲਾਅ ਕਿਸ 'ਤੇ ਅਸਰ ਕਰਦਾ ਹੈ, ਅਤੇ ਉਸ ਤੇ ਅਟੱਲ ਰਹੋ। ਇਥੇ ਜ਼ਿਆਦਾ ਗੁੰਝਲ ਪੈਦਾ ਹੁੰਦੀ ਹੈ। ਨਿਰਧਾਰਿਤ ਕਰੋ ਕਿ ਕੀ ਐਡਰੈੱਸ ਬਦਲਾਅ ਲਾਗੂ ਹੁੰਦਾ ਹੈ:

  • ਸਿਰਫ ਅਗਲੇ ਆਰਡਰ ਤੇ (ਸਫਰ ਲਈ ਉਪਯੋਗੀ)
  • ਸਭ ਭਵਿੱਖ ਆਰਡਰਾਂ ਲਈ (ਮੂਵ ਕਰਨ ਲਈ ਉਪਯੋਗੀ)

ਕਿਸੇ ਵੀ ਬਦਲਾਅ 'ਤੇ ਪ੍ਰੋਮੋ ਅਤੇ ਐਕਸਟ੍ਰਾ ਬਾਰੇ ਖੁੱਲ ਕੇ ਦੱਸੋ। ਜੇ ਕਿਸੇ ਨੇ “3 ਮਹੀਨੇ ਖਰੀਦੋ, ਇੱਕ ਮੁਫ਼ਤ ਗਿਫਟ” ਦਰਮਿਆਨ ਸਕਿਪ ਕੀਤਾ, ਤਾਂ ਕੀ ਗਿਫਟ ਅੱਗੇ ਚਲੇਗਾ ਜਾਂ ਆਫਰ ਖਤਮ ਹੋ ਜਾਵੇਗਾ? ਜੇ ਬੰਡਲ ਛੂਟ ਦੋ ਆਈਟਮਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ, ਅਤੇ ਉਨ੍ਹਾਂ ਨੇ ਇੱਕ ਹਟਾ ਦਿੱਤਾ, ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ? ਜੇ ਇਨਵੈਂਟਰੀ ਘੱਟ ਹੈ, ਕੀ ਉਹ ਬਿਨਾ ਕੀਮਤ ਗੁਆਏ ਦੇਰ ਕਰ ਸਕਦੇ ਹਨ?

ਇਕ ਸਧਾਰਣ ਟੈਸਟ: ਇੱਕ ਸ਼ੈਂਪੂ ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਲਓ ਜਿਸਦਾ 2 ਦਿਨ ਕਟਆਫ ਹੈ। ਜੇ ਕਿਸੇ ਨੇ ਕਟਆਫ ਤੋਂ ਇੱਕ ਦਿਨ ਪਹਿਲਾਂ ਪੌਜ਼ ਕੀਤਾ, ਕੀ ਤੁਸੀਂ ਫਿਰ ਵੀ ਭੇਜੋਗੇ? ਜੇ ਨਹੀਂ, ਤਾਂ ਜਦ ਉਹ ਮੁੜ ਚਾਲੂ ਕਰੇਗਾ ਕੀ ਉਹ ਆਪਣੀ ਛੂਟ ਰੱਖੇਗਾ? ਇਨ੍ਹਾਂ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦੋ ਪਹਿਲਾਂ ਤੁਸੀਂ ਯੂਆਈ ਡਿਜ਼ਾਈਨ ਕਰੋ।

ਚਟਾਫ਼ ਖਿੜਕੀਆਂ ਅਤੇ ਫਲਫਿਲਮੈਂਟ ਸਮਾਂ ਜੋ ਹੈਰਾਨੀ ਰੋਕਦੇ ਹਨ

ਜਿਆਦਾਤਰ ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਸਮੱਸਿਆਵਾਂ ਉਸ ਵਕਤ ਬਣਦੀਆਂ ਹਨ ਜਦ ਗਾਹਕ ਅਤੇ ਤੁਹਾਡੀ ਓਪਸ ਟੀਮ ਵੱਖ-ਵੱਖ ਘੜੀਆਂ ਵਰਤਦੇ ਹਨ। ਸੁਧਾਰ ਸਧਾਰਨ ਹੈ: ਇਕ ਸਾਫ਼ ਕਟਆਫ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰੋ ਜੋ ਅਗਲੇ ਸ਼ਿਪਮੈਂਟ ਨਾਲ ਜੋੜਿਆ ਹੋਇਆ ਹੋਵੇ, ਅਤੇ ਜਿੱਥੇ ਵੀ ਬਦਲਾਅ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਉਥੇ ਦਿਖਾਓ।

ਆਪਣੀ ਵੈਅਰਹਾਊਸ ਵਰਕਫਲੋਅ ਨਾਲ ਮਿਲਦਾ ਕਟਆਫ ਚੁਣੋ। “ਬਦਲਾਅ ਸ਼ਿਪਮੈਂਟ ਤੋਂ 48 ਘੰٹے ਪਹਿਲਾਂ ਬੰਦ ਹੋ ਜਾਂਦੇ ਹਨ” ਆਮ ਹੈ, ਪਰ ਠੀਕ ਵਿੰਡੋ ਪਿਕ-ਪੈੱਕ ਸਮਾਂ, ਕੈਰੀਅਰ ਪਿਕਅਪ ਅਤੇ ਲੇਬਲ ਬੈਚਿੰਗ 'ਤੇ ਨਿਰਭਰ ਹੁੰਦੀ ਹੈ।

ਕਟਆਫ ਤੋਂ ਬਾਅਦ, ਇੱਕ ਵਿਹਾਰ ਚੁਣੋ ਅਤੇ ਉਸ ਤੇ ਅਟੱਲ ਰਹੋ:

  • ਵਰਤਮਾਨ ਆਰਡਰ ਲਈ ਬਦਲਾਅ ਬਲੌਕ ਕਰੋ (ਸਾਫ਼ ਅਤੇ ਪੂਰਵਾਨੁਮਾਨਯੋਗ), ਜਾਂ
  • ਚੇਤਾਵਨੀ ਨਾਲ ਬਦਲਾਅ ਆਗਿਆ ਦਿਓ ਜੋ ਸਪਸ਼ਟ ਤੌਰ ਤੇ ਦੱਸੇ ਕਿ ਕੀ ਹੋਵੇਗਾ (ਉਦਾਹਰਣ: “ਇਹ ਅਪਡੇਟ ਬੇਲੜੇ ਹੋ ਰਹੇ ਆਰਡਰ 'ਤੇ ਨਹੀਂ ਲਾਗੂ ਹੁੰਦਾ।”)

ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਸਕਿਪ ਪੌਜ਼ ਅਤੇ ਐਡਰੈੱਸ ਬਦਲਾਅ ਸਕ੍ਰੀਨ ਦੇ ਉੱਪਰ ਨੇੜੇ ਤਿੰਨ ਚੀਜ਼ਾਂ ਦਿਖਾਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ: ਅਗਲਾ ਸ਼ਿਪ ਦੀ ਤਾਰੀਖ, ਕਟਆਫ ਤਾਰੀਖ/ਸਮਾਂ (ਟਾਈਮ ਜ਼ੋਨ ਸਮੇਤ), ਅਤੇ ਕਿਹੜੀਆਂ ਕਾਰਵਾਈਆਂ ਹਜੇ ਉਪਲਬਧ ਹਨ।

ਜੋ ਫੈਸਲੇ ਜ਼ਿਆਦਾਤਰ ਹੈਰਾਨੀਆਂ ਖਤਮ ਕਰਦੇ ਹਨ:

  • ਸਹੀ ਕਟਆਫ ਟਾਈਮਸਟੈਂਪ (ਤਾਰੀਖ + ਟਾਈਮ ਜ਼ੋਨ), ਨਾ ਕਿ ਸਿਰਫ “2 ਦਿਨ ਪਹਿਲਾਂ”
  • ਹਰ ਕਾਰਵਾਈ (skip, pause, address edit) ਲਈ ਕਟਆਫ ਤੋਂ ਬਾਅਦ ਕੀ ਹੁੰਦਾ ਹੈ
  • ਭੁਗਤਾਨ ਕਿੱਥੇ ਅਧਿਕਾਰਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਬਨਾਮ ਕੱਢਿਆ ਜਾਂਦਾ ਹੈ
  • ਜੇ ਇਨਵੈਂਟਰੀ ਘੱਟ ਹੋਵੇ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ

ਭੁਗਤਾਨ ਸਮਾਂ ਟੀਮਾਂ ਦੀ ਆਪੇ ਵਿੱਚੋਂ ਵਧ ਕੇ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦਾ ਹੈ। ਜੇ ਗਾਹਕ ਕਟਆਫ ਤੋਂ ਪਹਿਲਾਂ ਸਕਿਪ ਜਾਂ ਪੌਜ਼ ਕਰਦਾ ਹੈ, ਤਾਂ ਉਸ ਸਾਈਕਲ ਲਈ ਭੁਗਤਾਨ ਕੈਪਚਰ ਕਰਨ ਤੋਂ ਬਚੋ ਅਤੇ “ਇਸ ਸੀਜ਼ਨ ਕੋਈ ਚਾਰਜ ਨਹੀਂ” ਪੁਸ਼ਟੀ ਕਰੋ। ਜੇ ਤੁਸੀਂ ਪਹਿਲਾਂ ਪ੍ਰੀ-ਅਥੋਰਾਈਜ਼ ਕਰਦੇ ਹੋ, ਤਾਂ ਏਸ ਬਾਰੇ ਦੱਸੋ ਅਤੇ ਸਮਝਾਓ ਕਿ ਹੋਲ ਕਦੋਂ ਖਤਮ ਹੋਵੇਗਾ।

ਮੁਲਤਵੀ ਐਡਰੈੱਸ ਬਦਲਾਅ ਲਈ ਸੁਰੱਖਿਅਤ ਨੀਤੀ ਚਾਹੀਦੀ ਹੈ। ਜੇ ਕਿਸੇ ਨੇ ਸ਼ਿਪਮੈਂਟ ਤੋਂ 12 ਘੰਟੇ ਪਹਿਲਾਂ ਐਡਰੈੱਸ ਅਪਡੇਟ ਕੀਤਾ ਅਤੇ ਲੇਬਲ ਪਹਿਲਾਂ ਹੀ ਬਣ ਚੁੱਕੀ ਹੈ, ਤਦ ਤੈਅ ਕਰੋ ਕਿ ਤੁਸੀਂ ਕੀ ਕਰੋਗੇ (ਵਰਤਮਾਨ ਬਦਲਾਅ ਰੋਕੋ, ਪੇਡ ਰੀਸ਼ਿਪ ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰੋ, ਵਾਪਸ ਆਏ ਆਈਟਮਾਂ ਨੂੰ ਰੀਫੰਡ کرو) ਅਤੇ ਉਹ ਨਤੀਜਾ “Save” ਦਬਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਦਿਖਾਓ।

ਯੂਆਈ ਪੈਟਰਨ ਜੋ ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਬਦਲਾਅ ਸਧਾਰਨ ਰੱਖਦੇ ਹਨ

ਸਭ ਕੁਝ ਇੱਕ ਥਾਂ ਨੂੰ ਅੰਕਰ ਕਰੋ: ਇੱਕਲੌਤਾ Next delivery ਕਾਰਡ। ਇਸ ਵਿੱਚ ਡਿਲਿਵਰੀ ਦੀ ਤਾਰੀਖ, ਬਾਕਸ ਵਿਚ ਕੀ ਹੈ, ਕੁੱਲ ਕੀਮਤ, ਅਤੇ ਇੱਕ ਸੰਕੁਚਿਤ ਐਡਰੈੱਸ ਪ੍ਰੀਵਿਊ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਜਦ ਲੋਕ ਵੇਖ ਸਕਦੇ ਹਨ ਕਿ ਅਗਲਾ ਕੀ ਹੋਵੇਗਾ, ਉਹ ਘੱਟ ਗਲਤ ਬਦਲਾਅ ਕਰਨਗੇ ਅਤੇ ਘੱਟ ਸਪੋਰਟ ਨਾਲ ਸੰਪਰਕ ਕਰਨਗੇ।

ਮੁੱਖ ਨਿਯੰਤਰਣ ਉਹਨਾਂ ਤਿੰਨ ਕਾਰਨਾਂ 'ਤੇ ਕੇਂਦਰਤ ਰੱਖੋ ਜਿਥੇ ਲੋਕ ਆਮ ਤੌਰ 'ਤੇ ਪੰਨਾ ਖੋਲ੍ਹਦੇ ਹਨ:

  • Skip next
  • Pause
  • Change address

ਹੋਰ ਵਿਕਲਪ (ਫ੍ਰਿਕਵੈਂਸੀ ਬਦਲੋ, ਆਈਟਮ ਬਦਲੋ, ਪੇਮੈਂਟ ਸੋਧੋ) ਨੂੰ ਸੈਕੇਂਡਰੀ “Manage” ਵਿੱਚ ਰੱਖਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਮੂਲ ਕਾਰਵਾਈਆਂ ਨੂੰ ਦਫਨ ਨਾ ਕਰੋ।

ਇੱਕ ਸਧਾਰਣ ਪੈਟਰਨ ਜੋ ਅਕਸਰ ਚੰਗਾ ਕੰਮ ਕਰਦਾ ਹੈ: preview -> choose action -> confirm -> see the result. ਪੁਸ਼ਟੀ ਕਦਮ ਹੀ ਚਰਨ ਰੋਕਦਾ ਹੈ। ਨਵੀਂ ਅਗਲੀ ਡਿਲਿਵਰੀ ਦੀ ਤਾਰੀਖ ਵੱਡੇ ਅੱਖਰਾਂ ਵਿੱਚ ਦਿਖਾਓ, ਅਤੇ ਮੁੱਖ ਵੇਰਵੇ ਜਿਵੇਂ ਕੀਮਤ ਅਤੇ ਐਡਰੈੱਸ ਦੁਬਾਰਾ ਦਿਖਾਓ ਤਾਂ ਕਿ ਗਾਹਕ ਗਲਤੀਆਂ ਬਰਾਬਰ ਦੇਖ ਸਕੇ।

ਕੁਝ ਯੂਆਈ ਵਿਸਥਾਰ ਜੋ ਬਹੁਤ ਕੰਮ ਕਰਦੇ ਹਨ:

  • ਇੱਕ ਪ੍ਰਾਇਮਰੀ “Next delivery” ਕਾਰਡ ਜਿਸ ਵਿੱਚ ਤਾਰੀਖ, ਆਈਟਮ, ਕੀਮਤ, ਅਤੇ ਐਡਰੈੱਸ ਪ੍ਰੀਵਿਊ ਹੋਵੇ
  • ਤਿੰਨ ਪ੍ਰਾਇਮਰੀ ਬਟਨਾਂ ਨਾਲ ਸਪਸ਼ਟ ਲੇਬਲ (ਜਰਗਨ ਨਾ ਵਰਤੋਂ)
  • ਇੱਕ ਪੁਸ਼ਟੀਵਾਦੀ ਵੀਉ ਜੋ ਕਹੇ “ਤੁਹਾਡੀ ਅਗਲੀ ਡਿਲਿਵਰੀ ਹੁਣ…” ਨਵੀਂ ਤਾਰੀਖ ਦੇ ਨਾਲ
  • ਇੱਕ ਐਕਟਿਵਿਟੀ ਲੌਗ ਜੋ ਦਿਖਾਏ ਕਿ ਕੀ ਬਦਲਿਆ, ਕਦੋਂ, ਅਤੇ ਕਿਸਨੇ (ਤੁਸੀਂ, ਘਰ ਦਾ ਮੈਂਬਰ, ਸਪੋਰਟ)
  • ਕਾਰਵਾਈ ਦੇ ਨੇੜੇ ਛੋਟੀ ਮਾਈਕ੍ਰੋਕਾਪੀ ਜੋ ਸਮਾਂ ਅਤੇ ਨਤੀਜੇ ਦੱਸੇ

ਟਾਈਮ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਮਾਈਕ੍ਰੋਕਾਪੀ ਸਭ ਤੋਂ ਜ਼ਰੂਰੀ ਹੁੰਦੀ ਹੈ। ਜੇ ਬਦਲਾਅ ਦਾ ਇੱਕ ਕਟਆਫ ਹੈ, ਤਾਂ ਉਹ ਕਟਆਫ ਕਾਰਵਾਈ ਦੇ ਨੇੜੇ ਦੱਸੋ, ਨਾ ਕਿ ਨੀਤੀ ਟੈਕਸਟ ਵਿੱਚ ਛੁਪਾ ਕੇ। ਉਦਾਹਰਣ: “ਇਸ ਡਿਲਿਵਰੀ ਲਈ ਬਦਲਾਅ ਕੱਲ੍ਹ 5:00 PM ਨੂੰ ਬੰਦ ਹੋ ਜਾਂਦੇ ਹਨ।”

ਸਕਿਪ ਅਤੇ ਪੌਜ਼ ਲਈ ਕਦਮ-ਦਰ-ਕਦਮ ਫਲੋ (ਟੈਪ ਤੋਂ ਪੁਸ਼ਟੀ ਤੱਕ)

Ship an audit trail quickly
ਇੱਕ ਐਕਟਿਵਿਟੀ ਲੌਗ ਅਤੇ ਐਡਮਿਨ ਵ੍ਯੂ ਜੋ ਦੱਸੇ ਕਿ ਕਿਸਨੇ ਕੀ ਅਤੇ ਕਦੋਂ ਬਦਲਿਆ।
ਐਪ ਬਣਾਓ

ਇੱਕ ਚੰਗਾ ਸਕਿਪ ਜਾਂ ਪੌਜ਼ ਫਲੋ ਇੱਕ ਸਵਾਲ ਦਾ ਤੁਰੰਤ ਜਵਾਬ ਦੇਂਦਾ ਹੈ: ਮੇਰੀ ਅਗਲੀ ਡਿਲਿਵਰੀ ਨਾਲ ਕੀ ਹੋਵੇਗਾ?

ਸਧਾਰਣ ਸਟੇਟਸ ਕਾਰਡ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਦਿਖਾਓ ਕਿ ਸਬਸਕ੍ਰਿਪਸ਼ਨ Active ਹੈ ਜਾਂ Paused, ਅਗਲੀ ਚਾਰਜ ਤਾਰੀਖ, ਅਗਲੀ ship/delivery ਤਾਰੀਖ, ਅਤੇ ਅਗਲੇ ਬਾਕਸ ਵਿੱਚ ਕੀ ਹੈ। ਜੇ ਕੋਈ ਕਟਆਫ ਹੈ (“ਬਦਲਾਅ ਮੰਗਲਵਾਰ 6pm ਤੱਕ ਆਗਿਆਤ ਹਨ”), ਤਾਂ ਇਹ ਇਕੋ ਥਾਂ ਦਿਖਾਈਏ।

ਜਦ ਯੂਜ਼ਰ Skip ਜਾਂ Pause 'ਤੇ ਟੈਪ ਕਰਦਾ ਹੈ, ਉਨ੍ਹਾਂ ਨੂੰ ਨਤੀਜਾ ਅਨੁਮਾਨ ਨਾ ਕਰਨ ਦਿਓ। ਪੁਸ਼ਟੀ ਤੋਂ ਪਹਿਲਾਂ ਅਪਡੇਟ ਕੀਤਾ ਸ਼ਡਿਊਲ ਪ੍ਰੀਵਿਊ ਦਿਖਾਓ। ਸਕਿਪ ਆਮ ਤੌਰ 'ਤੇ ਅਗਲੀ ਡਿਲਿਵਰੀ ਨੂੰ ਅਗਲੇ ਸਾਈਕਲ 'ਤੇ ਲੈ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ ਅਤੇ ਇੱਕੋ ਕੈਡੈਂਸ ਰੱਖਣੀ ਚਾਹੀਦੀ ਹੈ। ਪੌਜ਼ ਕਰਨ 'ਤੇ ਇੱਕ ਸਾਫ਼ ਪ੍ਰਸ਼ਨ ਪੁੱਛੋ: ਕਿਸ ਤਾਰੀਖ ਤੱਕ ਪੌਜ਼ ਕਰੋ ਜਾਂ ਜਦ ਤੱਕ ਮੈਂ ਮੁੜ ਚਾਲੂ ਨਾ ਕਰਾਂ?

ਅਸਲੀ ਜ਼ਿੰਦਗੀ ਵਿੱਚ ਖੜ੍ਹਾ ਰਹਿਣ ਵਾਲਾ ਫਲੋ:

  1. ਮੌਜੂਦਾ ਸਥਿਤੀ ਅਤੇ “Next delivery” ਵੇਰਵੇ ਦਿਖਾਓ, ਜਿਸ ਵਿੱਚ ਆਖਰੀ ਦਿਨ ਜਦ ਬਦਲਾਅ ਆਗਿਆਤ ਹਨ ਵੀ ਹੋਵੇ।
  2. ਜਦ Skip ਜਾਂ Pause ਚੁਣਿਆ ਜਾਏ, ਅਪਡੇਟ ਕੀਤਾ ਸ਼ਡਿਊਲ ਦਿਖਾਓ (ਅਗਲੇ ਦੋ ਡਿਲਿਵਰੀਆਂ ਵੀ ਦਿਖਾ ਦੇਣਾ ਕਾਫ਼ੀ ਹੈ)।
  3. ਇਕ ਸੰਖੇਪ ਸਕ੍ਰੀਨ 'ਤੇ ਪੁਸ਼ਟੀ ਕਰੋ: ਕੀ ਵੱਧਿਆ, ਨਵੀਂ ਤਾਰੀਖਾਂ, ਅਤੇ ਭੁਗਤਾਨ 'ਤੇ ਕੀ ਅਸਰ ਪਿਆ।
  4. ਤੁਰੰਤ in-app ਪੁਸ਼ਟੀ ਭੇਜੋ, ਅਤੇ ਜੇ ਤੁਸੀਂ ਆਮ ਤੌਰ 'ਤੇ ਰਸੀਦਾਂ ਈਮੇਲ ਕਰਦੇ ਹੋ ਤਾਂ ਈਮੇਲ ਵੀ ਭੇਜੋ।
  5. ਜੇ ਫਲਫਿਲਮੈਂਟ ਸ਼ੁਰੂ ਨਹੀਂ ਹੋਇਆ ਤਾਂ ਇੱਕ ਛੋਟੀ undo ਵਿੰਡੋ ਦਿਓ, ਅਤੇ ਦਿਖਾਓ ਕਿ ਇਹ ਕਦੋਂ ਖ਼ਤਮ ਹੋਵੇਗੀ।

ਸੰਖੇਪ ਵਿਸ਼ੇਸ਼ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਉਦਾਹਰਣ: “ਤੁਸੀਂ 12 ਅਪ੍ਰੈਲ ਨੂੰ ਸਕਿਪ ਕੀਤਾ। ਤੁਹਾਡੀ ਅਗਲੀ ਡਿਲਿਵਰੀ 10 ਮਈ ਹੋਵੇਗੀ। 11 ਅਪ੍ਰੈਲ ਨੂੰ ਕੋਈ ਚਾਰਜ ਨਹੀਂ ਹੋਵੇਗਾ।” ਇਹ ਕਲਾਸਿਕ ਟਿਕਟ ਰੋਕਦਾ ਹੈ: “ਮੈਂ ਪੌਜ਼ ਕੀਤਾ ਪਰ ਫਿਰ ਵੀ ਮੈਨੂੰ ਚਾਰਜ ਕੀਤਾ ਗਿਆ।”

Undo ਨੂੰ ਸੁਰੱਖਿਅਤ ਬਣਾਓ। ਜੇ ਆਰਡਰ ਪਹਿਲਾਂ ਹੀ ਪੈਕ ਕੀਤਾ ਗਿਆ ਜਾਂ ਲੇਬਲ ਪ੍ਰਿੰਟ ਹੋ ਚੁੱਕੀ ਹੈ, ਤਾਂ “Undo” ਦੀ ਥਾਂ ਦਿਖਾਓ: “ਇਸ ਆਰਡਰ ਨੂੰ ਪਹਿਲਾਂ ਹੀ ਪ੍ਰੋਸੈਸ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ ਅਤੇ ਇਸਨੂੰ ਬਦਲਿਆ ਨਹੀਂ ਜਾ ਸਕਦਾ,” ਅਤੇ ਨਜ਼ਦੀਕੀ ਉਪਲਬਧ ਕਾਰਵਾਈ ਦਿਖਾਓ (“ਅਗਲੀ ਡਿਲਿਵਰੀ ਤੋਂ ਬਾਅਦ ਪੌਜ਼ ਕਰੋ”)।

ਐਡਰੈੱਸ ਬਦਲਾਅ: ਨਿਯਮ, ਏਜ ਕੇਸ, ਅਤੇ ਸੁਰੱਖਿਅਤ ਐੱਡਿਟ ਫਲੋ

ਐਡਰੈੱਸ ਐਡਿਟ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਇੱਕ ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਮਦਦਗਾਰ ਜਾਂ ਵਿਰੋਧੀ ਲੱਗ ਸਕਦਾ ਹੈ। ਜੇ ਲੋਕ ਗਲਤੀ ਦਾ ਡਰ ਮਹਿਸੂਸ ਕਰਦੇ ਹਨ, ਉਹ ਬਦਲਾਅ ਕਰਨ ਦੀ ਥਾਂ ਰੱਦ ਕਰ ਦੇਂਦੇ ਹਨ। ਯੂਆਈ ਨੂੰ ਇੱਕ ਗੱਲ ਸਪਸ਼ਟ ਕਰਨੀ ਹੈ: ਅਗਲੇ ਡਿਲਿਵਰੀ ਲਈ ਕਿਹੜਾ ਐਡਰੈੱਸ ਵਰਤਿਆ ਜਾਵੇਗਾ, ਅਤੇ ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ ਕੀ ਹੋਵੇਗਾ।

ਪਹਿਲਾਂ ਤੈਅ ਕਰਨ ਵਾਲੇ ਨਿਯਮ

ਹਰ ਐਡਰੈੱਸ ਐਡਿਟ ਨੂੰ ਇੱਕ ਸਪਸ਼ਟ ਚੋਣ ਨਾਲ ਸ਼ੁਰੂ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ: ਕੀ ਇਹ ਸਿਰਫ ਅਗਲੇ ਆਰਡਰ ਲਈ ਬਦਲਣਾ ਹੈ, ਜਾਂ ਸਾਰੇ ਭਵਿੱਖ ਆਰਡਰਾਂ ਲਈ? ਬਹੁਤ ਸਾਰੇ ਗਾਹਕ ਸਫਰ ਕਰਦੇ ਹਨ, ਅਸਥਾਈ ਤੌਰ 'ਤੇ ਮੂਵ ਕਰਦੇ ਹਨ, ਜਾਂ ਇੱਕ ਵਾਰੀ ਦਾ ਗਿਫਟ ਭੇਜਦੇ ਹਨ। ਸਥਾਈ ਬਦਲਾਅ ਲਾਗੂ ਕਰਨ ਜ਼ਬਰਦਸਤੀ ਗਲਤੀਆਂ ਅਤੇ ਟਿਕਟਾਂ ਬਣਾਉਂਦਾ ਹੈ।

ਕਟਆਫ ਮਹੱਤਵਪੂਰਨ ਹਨ। ਜੇ ਅਗਲਾ ਆਰਡਰ ਪਹਿਲਾਂ ਹੀ ਪ੍ਰੋਸੈਸ ਹੋ ਰਿਹਾ ਹੈ, ਤਾਂ ਸੇਵ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਦੱਸੋ। ਸਾਦੀ ਭਾਸ਼ਾ ਵਰਤੋ: “ਇਹ ਆਰਡਰ ਪਹਿਲਾਂ ਹੀ ਤਿਆਰ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ। ਤੁਹਾਡਾ ਬਦਲਾਅ ਅਗਲੇ ਮਹੀਨੇ ਤੋਂ ਲਾਗੂ ਹੋਵੇਗਾ,” ਅਤੇ ਉਸ ਤਾਰੀਖ ਨੂੰ ਦਿਖਾਓ ਜਿਸ ਤੇ ਇਹ ਪ੍ਰਭਾਵੀ ਹੋਵੇਗਾ।

ਅਕਸਰ ਜਾਂਚ ਪਹਿਲਾਂ ਕਰੋ, ਨਾ ਕਿ ਆਖ਼ਰ 'ਚ। ਜਦ ਗਾਹਕ ਟਾਈਪ ਕਰ ਰਿਹਾ ਹੋਵੇ ਤਾਂ ਗੁੰਮ ਹੋਏ ਫੀਲਡ ਫੜੋ, ਅਤੇ ਆਮ ਯੂਨਿਟ ਫਾਰਮੈਟ (Apt, Unit, #, Floor) ਸਵੀਕਾਰ ਕਰੋ। ਐਡਰੈੱਸ ਗਲਤੀਆਂ ਅਕਸਰ ਛੋਟੀ ਲੱਗਦੀਆਂ ਹਨ ਪਰ ਨਾਕਾਮ ਡਿਲਿਵਰੀਆਂ ਵੱਜੋਂ ਨਤੀਜੇ ਲਿਆਉਂਦੀਆਂ ਹਨ।

ਇੱਕ ਸੁਰੱਖਿਅਤ ਐਡਿਟ ਫਲੋ (ਜੋ ਹੈਰਾਨੀਆਂ ਰੋਕੇ)

ਸਕ੍ਰੀਨ ਨੂੰ ਪੈਟਿਤਿਤ ਰੱਖੋ:

  • ਉੱਪਰ Next delivery address ਦਾ ਇੱਕ ਸਪਸ਼ਟ ਪ੍ਰੀਵਿਊ ਦਿਖਾਓ।
  • ਯੂਜ਼ਰ ਨੂੰ ਆਗਿਆ ਦਿਓ ਕਿ ਓਹ Next order only ਜਾਂ All future orders ਚੁਣ ਸਕਦਾ ਹੈ, ਹਰ ਇਕ ਦੀ ਇੱਕ ਲਾਈਨ ਸਮਝਾਓ।
  • ਜੇ ਇਹ ਕਟਆਫ ਤੋਂ ਬਾਅਦ ਹੈ, ਤਾਂ ਸਪਸ਼ਟ ਚੇਤਾਵਨੀ ਦਿਖਾਓ ਅਤੇ ਪਹਿਲੀ ਡਿਲਿਵਰੀ ਜੋ ਇਸ 'ਤੇ ਪ੍ਰਭਾਵਿਤ ਹੋਵੇਗੀ ਦਿਖਾਓ।
  • ਜੇ ਤੁਸੀਂ ਸੇਵਡ ਐਡਰੈੱਸ ਸਪੋਰਟ ਕਰਦੇ ਹੋ, ਤਾਂ ਗਾਹਕਾਂ ਨੂੰ ਇਕ ਚੋਣ ਦਿਓ ਤਾਂ ਕਿ ਉਹ ਦੁਬਾਰਾ ਟਾਈਪ ਨਾ ਕਰਨ।
  • ਅੰਤ ਵਿੱਚ ਇੱਕ ਅਖੀਰੀ ਸੰਖੇਪ ਦਿਖਾਓ: “ਅਗਲੀ ਡਿਲਿਵਰੀ X ਨੂੰ X ਪਤੇ ਤੇ ਭੇਜੀ ਜਾਵੇਗੀ।”

ਮਲਟੀ-ਐਡਰੈੱਸ ਕੇਸਾਂ ਨੂੰ ਸਪਸ਼ਟ ਲੇਬਲ ਦੇਵੋ। ਜੇ ਤੁਸੀਂ ਗਿਫਟਿੰਗ ਜਾਂ ਵੰਡਾ-ਸ਼ਿਪਮੈਂਟ ਸਹਾਇਤਾ ਕਰਦੇ ਹੋ, ਤਾਂ ਹਰ ਇਕ ਸ਼ਿਪਮੈਂਟ ਲਾਈਨ ਨਾਲ ਆਪਣਾ ਐਡਰੈੱਸ ਦਿਖਾਓ। ਜੇ ਨਹੀਂ, ਤਾਂ ਕਹੋ “ਇਕ ਆਰਡਰ ਲਈ ਇੱਕ ਐਡਰੈੱਸ” ਅਤੇ ਗਾਹਕ ਨੂੰ ਇੱਕ ਵੱਖਰਾ ਇੱਕ-ਵਾਰੀ ਆਰਡਰ ਬਣਾਉਣ ਲਈ ਮਾਰਗ ਦਰਸ਼ਨ ਦਿਓ।

ਉਦਾਹਰਣ: ਸਕਿੰਕੇਅਰ ਸਬਸਕ੍ਰਿਪਸ਼ਨ 'ਤੇ ਕੋਈ ਮਾਸਿਕ ਯਾਤਰਾ ਲਈ ਦੋ ਹਫ਼ਤੇ ਜਾ ਰਿਹਾ ਹੈ। ਉਹ “next order only” ਚੁਣਦਾ ਹੈ, ਹੋਟਲ ਐਡਰੈੱਸ ਦਿੰਦਾ ਹੈ, ਇੱਕ ਚੇਤਾਵਨੀ ਦੇਖਦਾ ਹੈ ਕਿ ਇਸ ਮਹੀਨੇ ਦਾ ਆਰਡਰ ਅਜੇ ਵੀ ਪ੍ਰੋਸੈਸ ਹੋ ਰਿਹਾ ਹੈ, ਅਤੇ ਪੁਸ਼ਟੀ ਦਿਖਾਉਂਦੀ ਹੈ ਕਿ ਇਸ ਡਿਲਿਵਰੀ ਲਈ ਘਰ ਦਾ ਐਡਰੈੱਸ ਰਹੇਗਾ ਪਰ ਅਗਲੇ ਮਹੀਨੇ ਤੋਂ ਹੋਟਲ ਐਡਰੈੱਸ ਲਾਗੂ ਹੋਵੇਗਾ। ਇਹ ਸਪਸ਼ਟਤਾ ਹੀ ਐਡਰੈੱਸ ਬਦਲਾਅ ਨੂੰ ਸੈਲਫ-ਸਰਵ ਬਣਾਉਂਦੀ ਹੈ ਬਜਾਏ ਸਪੋਰਟ ਕਾਓਸ ਦੇ।

ਕੀਮਤ, ਪ੍ਰੋਮੋ ਅਤੇ ਇਨਵੈਂਟਰੀ ਮਾਮਲੇ ਜੋ ਟੀਮਾਂ ਨੂੰ ਫਸਾਉਂਦੇ ਹਨ

ਜ਼ਿਆਦਾਤਰ ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਸ਼ਿਕਾਇਤਾਂ ਸਕਿਪ ਜਾਂ ਪੌਜ਼ ਬਟਨ ਬਾਰੇ ਨਹੀਂ ਹੁੰਦੀਆਂ। ਇਹ ਪੈਸੇ ਅਤੇ ਉਪਲਬਧਤਾ ਬਾਰੇ ਹੁੰਦੀਆਂ ਹਨ।

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

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

ਐਡ-ਓਨ ਅਤੇ ਇੱਕ-ਵਾਰੀ ਆਈਟਮ ਇੱਕ ਹੋਰ ਆਮ ਫੰਸ ਹਨ। “ਅਗਲਾ ਆਰਡਰ” ਤੁਹਾਡੇ ਸਿਸਟਮ ਵਿੱਚ ਕੀ ਮਾਣਦਾ ਹੈ ਇਹ ਸਪਸ਼ਟ ਵਾਅਦਾ ਕਰੋ, ਖ਼ਾਸ ਕਰਕੇ ਜਦ ਅਗਲਾ ਆਰਡਰ ਸਕਿਪ ਹੋ ਜਾਂ ਪੌਜ਼ ਕੀਤਾ ਜਾਵੇ।

ਆਊਟ-ਆਫ-ਸਟਾਕ ਸੰਭਾਲਵਾਂ ਨੂੰ ਯੂਜ਼ਰ ਦੀ ਚੋਣ ਵਰਗਾ ਮਹਿਸੂਸ ਕਰਵਾਓ, ਨਾ ਕਿ ਹੈਰਾਨੀ। ਕੁਝ ਛੋਟੇ ਵਿਕਲਪ ਦਿਓ: ਬਦਲਾਅ, ਇਸ ਸ਼ਿਪਮੈਂਟ ਨੂੰ ਸਕਿਪ ਕਰੋ, ਜਾਂ ਆਊਟ-ਆਫ-ਸਟਾਕ ਆਈਟਮ ਹਟਾਓ। ਜੇ ਬਦਲਾਅ ਕੀਮਤ ਬਦਲਦਾ ਹੈ, ਸਪਸ਼ਟ ਪੁਸ਼ਟੀ ਲੋੜੀਦੀ ਹੈ।

ਰੀਜਨ ਨਿਯਮ ਤੇਜ਼ੀ ਨਾਲ ਭਰੋਸਾ ਤੋੜ ਸਕਦੇ ਹਨ। ਜੇ ਸ਼ਿਪਿੰਗ ਦੇ ਦੇਸ਼ ਜਾਂ ਉਤਪਾਦ ਨਿਯਮ ਵੱਖਰੇ ਹਨ, ਗਲਤ ਸਵੈਪ ਨੂੰ ਬਲੌਕ ਕਰੋ ਅਤੇ ਸਾਦੀ ਭਾਸ਼ਾ ਵਿੱਚ ਸਮਝਾਓ (“ਤੁਹਾਡੇ ਖੇਤਰ ਵਿੱਚ ਉਪਲਬਧ ਨਹੀਂ”)। ਜੇ ਗਾਹਕ ਐਡਰੈੱਸ ਬਦਲਦਾ ਹੈ ਕਿਸੇ ਰੋਕੀਏ ਖੇਤਰ ਵੱਲ, ਤਾਂ ਉਸ ਅਗਲੇ ਸ਼ਿਪਮੈਂਟ ਨਾਲ ਕੀ ਹੋਵੇਗਾ ਦੱਸੋ: ਉਤਪਾਦ ਬਦਲੇਗਾ, ਦੇਰੀ ਹੋਏਗੀ, ਜਾਂ ਰੱਦ ਹੋ ਜਾਵੇਗਾ।

ਉਦਾਹਰਣ: ਗਾਹਕ ਪੌਜ਼ ਕਰਦਾ ਹੈ, ਫਿਰ ਮੁੜ ਚਾਲੂ ਕਰਦਾ ਹੈ ਅਤੇ ਉਮੀਦ ਕਰਦਾ ਹੈ ਕਿ ਉਨ੍ਹਾਂ ਦੀ "ਪਹਿਲੀ ਮਹੀਨਾ 20% ਛੂਟ" ਵਾਪਸ ਆ ਜਾਵੇਗੀ। ਜੇ ਤੁਹਾਡੀ ਯੂਆਈ ਉਨ੍ਹਾਂ ਨੂੰ ਦਿਖਾਏ “ਪ੍ਰੋਮੋ 31 ਅਕਤੂਬਰ ਨੂੰ ਮਿਆਦ ਖਤਮ ਹੋ ਗਿਆ” ਪਹਿਲਾਂ ਹੀ ਉਹ ਪੁੱਛੋੜੀ ਮੁੜ ਚਾਲੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਤੁਸੀਂ ਚਾਰਜਬੈਕ ਅਤੇ ਗੁੱਸੇ ਭਰੇ ਈਮੇਲ ਨੂੰ ਰੋਕ ਸਕਦੇ ਹੋ।

ਆਮ ਗਲਤੀਆਂ ਜੋ ਚਰਨ ਅਤੇ ਸਪੋਰਟ ਟਿਕਟ ਬਣਾਉਂਦੀਆਂ ਹਨ

Make skip and pause reliable
ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਰਾਜਿਆਂ ਦੇ ਬਦਲਾਅ ਮਾਡਲ ਕਰੋ ਤਾਂ ਕਿ ਬਿਲਿੰਗ ਅਤੇ ਫਲਫਿਲਮੈਂਟ ਜਾਬਜ਼਼ ਕਿਸੇ ਵੀ ਸਕਿਪ ਜਾਂ ਪੌਜ਼ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਨਾ ਕਰਨ।
ਪ੍ਰੋਜੈਕਟ ਬਣਾਓ

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

ਇੱਕ ਆਮ ਫੰਸ ਕਟਆਫ ਨੂੰ ਅਖੀਰਲੇ ਕਦਮ ਤੱਕ ਛੁਪਾਉਣਾ ਹੈ। ਜੇ ਕਿਸੇ ਨੇ Skip 'ਤੇ ਟੈਪ ਕੀਤਾ, ਪੁਸ਼ਟੀ ਦੇ ਨੇੜੇ ਹੀ ਵੇਖਿਆ ਕਿ “ਹੁਣ ਬਹੁਤ ਦੇਰ ਹੋ ਚੁੱਕੀ ਹੈ,” ਤਾਂ ਉਹ ਸਬਸਕ੍ਰਿਪਸ਼ਨ 'ਤੇ ਦੁਬਾਰਾ ਭਰੋਸਾ ਨਹੀਂ ਕਰੇਗਾ। ਅਗਲੀ ਚਾਰਜ ਤਾਰੀਖ ਅਤੇ ਸੰਪਾਦਨ ਦੀ ਮਿਆਦ ਮੁੱਖ ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਕਾਰਡ 'ਤੇ ਦਿਖਾਓ।

ਹੋਰ ਦੁਹਰਾਉਣ ਵਾਲੀ ਗਲਤੀ ਹੈ ਕਿ ਐਡਰੈੱਸ ਬਦਲਾਅ ਸਵੀਕਾਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਪਰ ਇਹ ਨਹੀਂ ਦੱਸਿਆ ਜਾਂਦਾ ਕਿ ਇਹ ਕਿਸ ਸ਼ਿਪਮੈਂਟ 'ਤੇ ਲਾਗੂ ਹੋਏਗਾ। ਜੇ ਸਿਸਟਮ ਪਹਿਲਾਂ ਹੀ ਪਿਕ ਅਤੇ ਪੈਕ ਕਰ ਰਿਹਾ ਹੈ, ਤਾਂ ਕਹੋ ਅਤੇ ਦਸੋ ਕਿ ਬਦਲਾਅ ਕਦੋਂ ਲਾਗੂ ਹੋਵੇਗਾ (“ਇਹ ਬਦਲਾਅ 12 ਫਰਵਰੀ ਦੇ ਆਰਡਰ ਤੋਂ ਲਾਗੂ ਹੋਵےਗਾ”)। ਇਹ ਉਹੀ ਗੱਲ ਡਿਲਿਵਰੀ ਨੋਟਸ, ਗੇਟ ਕੋਡ, ਅਤੇ ਅਪਾਰਟਮੈਂਟ ਨੰਬਰਾਂ ਲਈ ਵੀ ਲਾਗੂ ਹੁੰਦੀ ਹੈ।

ਅਸਪਸ਼ਟ ਸ਼ਬਦ confusion ਵੀ ਗਲਤੀਆਂ ਪੈਦਾ ਕਰਦੇ ਹਨ। ਲੇਬਲ ਜਿਵੇਂ “hold” ਜਾਂ “snooze” ਲੋਕਾਂ ਲਈ ਵੱਖ-ਵੱਖ ਮਤਲਬ ਰੱਖਦੇ ਹਨ। ਤਾਰੀਖਾਂ ਅਤੇ ਨਤੀਜਿਆਂ ਵਰਤੋਂ: “Pause until Mar 10” ਜਾਂ “Skip next order (Jan 15).” ਗਾਹਕਾਂ ਨੂੰ ਕਦੇ ਵੀ ਅਨੁਮਾਨ ਨਹੀਂ ਲੱਗਣਾ ਚਾਹੀਦਾ ਕਿ ਉਹਨਾਂ ਨੂੰ ਚਾਰਜ ਕੀਤਾ ਜਾਵੇਗਾ ਜਾਂ ਨਹੀਂ।

ਗਲਤੀਆਂ ਜੋ ਅਕਸਰ ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਨਿਯੰਤਰਣਾਂ ਨੂੰ ਸਪੋਰਟ ਕਾਓਸ ਬਣਾਉਂਦੀਆਂ ਹਨ:

  • ਕਟਆਫ ਨਿਯਮ ਛੁਪੇ ਹੋਏ ਹਨ ਜਾਂ ਸਿਰਫ ਉਸ ਦੇਖਣ 'ਤੇ ਦਿਖਾਉਂਦੇ ਹਨ ਜਦ ਗਾਹਕ ਪੁਸ਼ਟੀ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ
  • ਐਡਰੈੱਸ ਐਡਿਟ ਸਵੀਕਾਰ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਪਰ ਯੂਆਈ ਨਹੀਂ ਦੱਸਦਾ ਕਿ ਇਹ ਕਿਸ ਸ਼ਿਪਮੈਂਟ ਲਈ ਹੈ
  • ਕਾਰਵਾਈਆਂ ਅਨਿਸ਼ਚਿਤ ਨਾਮ ਵਰਤਦੀਆਂ ਹਨ, ਨਾ ਕੋਈ ਤਾਰੀਖਾਂ, ਨਾ ਅਗਲੀ ਚਾਰਜ ਜਾਣਕਾਰੀ, ਨਾ ਕੋਇ ਪ੍ਰੀਵਿਊ
  • ਕੋਈ ਆਡਿਟ ਟਰੇਲ ਨਹੀਂ ਹੈ, ਤਾਂ ਕਿ ਸਪੋਰਟ ਪੁੱਛ ਸਕੇ “ਇਸਨੂੰ ਕਿਸਨੇ ਅਤੇ ਕਦੋਂ ਬਦਲਿਆ?”
  • ਸਕਿਪ/ਪੌਜ਼ ਸਕ੍ਰੀਨ ਨੂੰ ਅਪਡੇਟ ਕਰਦਾ ਹੈ, ਪਰ ਬੈਕਗ੍ਰਾਊਂਡ ਜਾਬਜ਼ ਫਿਰ ਵੀ ਚਾਰਜ ਜਾਂ ਫਲਫਿਲਮੈਂਟ ਨੂੰ ਕਤਾਰਬੱਧ ਕਰ ਦਿੰਦੀਆਂ ਹਨ

ਇਹ ਆਖ਼ਰੀ ਗਲਤੀ ਸਭ ਤੋਂ ਨੁਕਸਾਨਦੇਹ ਹੈ ਕਿਉਂਕਿ ਇਹ ਇੱਕ ਟੁੱਟੇ ਵਾਅਦੇ ਵਰਗੀ ਮਹਿਸੂਸ ਹੁੰਦੀ ਹੈ। ਜੇ ਬਿਲਿੰਗ ਅਤੇ ਫਲਫਿਲਮੈਂਟ ਸ਼ੈਡਿਊਲ ਜਾਬਜ਼ 'ਤੇ ਚਲਦੇ ਹਨ, ਤਾਂ ਸਕਿਪ/ਪੌਜ਼/ਐਡਰੈੱਸ ਨੂੰ ਇੱਕ ਪਹਿਲੀ-ਕਲਾਸ ਸਥਿਤੀ ਵਜੋਂ ਲਿਆ ਜਾਵੇ ਜੋ ਹਰ ਵਾਰ ਉਹਨਾਂ ਜਾਬਜ਼ ਦੁਆਰਾ ਪੜ੍ਹੀ ਜਾਵੇ, ਨਾ ਕਿ ਕੇਵਲ ਯੂਆਈ-ਕੇਵਲ ਫਲੈਗ।

ਤੁਹਾਡੇ ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਸੈਟਿੰਗਜ਼ ਅਨੁਭਵ ਲਈ ਤੇਜ਼ ਚੈੱਕਲਿਸਟ

ਇੱਕ ਚੰਗੀ ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਸਕ੍ਰੀਨ ਬਦਲਾਅ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਦੋ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਦਿੰਦੀ ਹੈ: ਅਗਲਾ ਕੀ ਹੋਵੇਗਾ, ਅਤੇ ਕਦੋਂ।

ਸ਼ਿਪ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਕਿਸੇ ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਨੂੰ 30 ਸਕਿੰਟ ਤੋਂ ਘੱਟ ਵਿੱਚ ਮੈਨੇਜ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋ। ਤੁਸੀਂ ਅਗਲੀ ਸ਼ਿਪਮੈਂਟ ਵੇਰਵਿਆਂ ਨੂੰ ਪੁਸ਼ਟੀ ਕਰ ਸਕੋ, ਬਦਲਾਅ ਕਰੋ, ਅਤੇ ਭਰੋਸਾ ਮਹਿਸੂਸ ਕਰੋ ਕਿ ਕੁਝ ਅਣਉਮੀਦਿਤ ਨਹੀਂ ਹੋਵੇਗਾ।

ਚੈੱਕਲਿਸਟ:

  • Next order clarity: ਅਗਲੀ ਡਿਲਿਵਰੀ ਦੀ ਤਾਰੀਖ (ਅਤੇ ਅੰਦਾਜ਼ਿਤ ਆਗਮਨ ਜੇ ਤੁਸੀਂ ਦਿਖਾਉਂਦੇ ਹੋ), ਬਾਕਸ ਵਿੱਚ ਕੀ ਹੈ, ਅਤੇ ਕੁੱਲ ਕੀਮਤ ਇਕੱਠੇ ਦਿਖਾਏ ਜਾਣ
  • Change timing: ਕਟਆਫ ਤਾਰੀਖ ਅਤੇ ਸਮਾਂ (ਟਾਈਮ ਜ਼ੋਨ ਸਮੇਤ) ਆਖਰੀ ਪੁਸ਼ਟੀ ਤੋਂ ਪਹਿਲਾਂ ਦਿਖੇ ਜਾਣ, ਅਤੇ ਜਦ ਬਹੁਤ ਦੇਰ ਹੋ ਚੁੱਕੀ ਹੋਵੇ ਤਾਂ ਇਹ ਬਹੁਤ ਸਪਸ਼ਟ ਹੋਵੇ
  • Confirmation you can trust: ਸਕਿਪ ਜਾਂ ਪੌਜ਼ ਦੇ ਬਾਅਦ, ਅਪਡੇਟ ਕੀਤੀ ਅਗਲੀ ਸ਼ਿਪਮੈਂਟ ਤਾਰੀਖ ਅਤੇ ਕੀ ਗਾਹਕੋਂ ਨੂੰ ਚਾਰਜ ਕੀਤਾ ਜਾਵੇਗਾ ਉਹ ਦਿਖਾਇਆ ਜਾਵੇ
  • Mistake recovery: ਜੇ ਸੰਭਵ ਹੋਵੇ ਤਾਂ ਇੱਕ undo ਵਿਕਲਪ (ਜਾਂ ਛੋਟੀ ਗਰੇਸ ਵਿੰਡੋ) ਅਤੇ ਉਸਦੀ ਮਿਆਦ ਦਿਖਾਓ
  • Address impact: ਐਡਰੈੱਸ ਐਡਿਟ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਦੱਸੇ ਕਿ ਇਹ ਅਗਲੇ ਸ਼ਿਪਮੈਂਟ, ਭਵਿੱਖ ਸ਼ਿਪਮੈਂਟ, ਜਾਂ ਦੋਨੋਂ 'ਤੇ ਕਿਵੇਂ ਪ੍ਰਭਾਵ ਪਾਵੇਗਾ

ਇੱਕ ਵਿਅਵਹਾਰਕ ਜਾਂਚ: ਉਹ ਸਪੋਰਟ ਟਿਕਟ ਲਿਖੋ ਜੋ ਤੁਸੀਂ ਰੋਕਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਫਿਰ ਵੇਖੋ ਕਿ ਯੂਆਈ ਉਸਦਾ ਜਵਾਬ ਦਿੰਦੀ ਹੈ ਕਿ ਨਹੀਂ। ਉਦਾਹਰਣ: “ਮੈਂ ਸਕਿਪ ਕੀਤਾ, ਪਰ ਕੀ ਮੈਂ ਫਿਰ ਵੀ ਚਾਰਜ ਹੋਇਆ?” ਜੇ ਸਕ੍ਰੀਨ ਉਸ ਕਾਰਵਾਈ ਲਈ ਚਾਰਜ ਟਾਈਮਿੰਗ ਨਹੀਂ ਦਿਖਾਉਂਦੀ, ਤਾਂ ਪੁਸ਼ਟੀ ਨਜਦੀਕ ਇਕ ਲਾਈਨ ਜੋੜੋ।

ਉਦਾਹਰਣ ਮਾਮਲਾ: ਸਕਿੰਕੇਅਰ ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਅਤੇ ਇੱਕ ਆਖ਼ਰੀ-ਮਿੰਟ ਦੀ ਯਾਤਰਾ

Design safer address changes
Next order ਅਤੇ All future ਵਿਕਲਪਾਂ ਨਾਲ ਸੁਰੱਖਿਅਤ ਐਡਰੈੱਸ ਐਡਿਟ ਬਣਾਓ ਅਤੇ ਕਟਆਫ ਤੋਂ ਬਾਅਦ ਸਪਸ਼ਟ ਸੁਨੇਹਾ ਦਿਖਾਓ।
ਹੁਣ ਬਣਾਓ

ਮਾਯਾ ਇੱਕ ਮਾਸਿਕ ਸਕਿੰਕੇਅਰ ਸਬਸਕ੍ਰਿਪਸ਼ਨ 'ਤੇ ਹੈ ਜੋ 12 ਨੂੰ ਭੇਜਦਾ ਹੈ। ਅੱਜ 8 ਮਈ ਹੈ, ਅਤੇ ਉਹਨੂੰ ਹੁਣ ਪਤਾ ਲੱਗਦਾ ਹੈ ਕਿ ਉਹ 11 ਮਈ ਤੋਂ 25 ਮਈ ਤੱਕ ਯਾਤਰਾ 'ਤੇ ਹੋਵੇਗੀ। ਉਹ Manage subscription ਖੋਲ੍ਹਦੀ ਹੈ ਤਾਂ ਕਿ ਉਹ ਇਕ ਬਾਕਸ ਆਉਣ ਵੇਲੇ ਗੈਰਹਾਜ਼ਿਰ ਹੋਣ ਤੋਂ ਬਚ ਸਕੇ।

ਸਕ੍ਰੀਨ ਤੁਰੰਤ ਤਿੰਨ ਗੱਲਾਂ ਦਿਖਾਉਂਦੀ ਹੈ: Next delivery: May 12, Edit cutoff: May 9 at 11:59 pm, ਅਤੇ Estimated total: $38.00 (free shipping). ਹੇਠਾਂ ਉਹਨੂੰ ਦੋ ਸਾਫ਼ ਕਾਰਵਾਈਆਂ ਦਿਖਦੀਆ: Skip next delivery ਅਤੇ Pause subscription। ਉਹ Skip next delivery ਚੁਣਦੀ ਹੈ।

ਇਕ ਪੁਸ਼ਟੀ ਸ਼ੀਟ ਆਉਂਦੀ ਹੈ:

  • ਤੁਸੀਂ 12 ਮਈ ਦਾ ਆਰਡਰ ਸਕਿਪ ਕਰੋਗੇ।
  • ਤੁਹਾਡੀ ਅਗਲੀ ਡਿਲਿਵਰੀ ਹੁਣ 12 ਜੂਨ ਹੋਵੇਗੀ।
  • ਤੁਹਾਡੀ ਕੀਮਤ ਇਕੋ ਰਹਿੰਦੀ ਹੈ।
  • ਤੁਸੀਂ May 9 ਤੱਕ ਇਸਨੂੰ undo ਕਰ ਸਕਦੇ ਹੋ।

ਉਸਨੇ ਪੁਸ਼ਟੀ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਮੁੱਖ ਪੰਨਾ Next delivery: June 12 'ਤੇ ਅਪਡੇਟ ਹੋ ਜਾਂਦਾ ਹੈ ਅਤੇ ਇੱਕ ਛੋਟਾ ਬੈਨਰ ਸ਼ਾਮਲ ਹੋ ਗਿਆ: Skipped May 12। ਇੱਕ Activity ਪੈਨਲ ਰਿਕਾਰਡ ਕਰਦਾ ਹੈ: “May 8, 3:14 pm - Skipped May 12 delivery.” ਮਾਯਾ ਨੂੰ ਇੱਕ ਸਕ੍ਰੀਨ ਪੁਸ਼ਟੀ ਨੰਬਰ ਮਿਲਦਾ ਹੈ, ਤਾਂ ਜੋ ਉਸਨੂੰ ਸਪੋਰਟ ਨੂੰ ਈਮੇਲ ਕਰਨ ਦੀ ਲੋੜ ਨਾ ਪਏ।

ਦੋ ਦਿਨ ਬਾਅਦ (May 10), ਉਸਨੂੰ ਯਾਦ ਆਉਂਦਾ ਹੈ ਕਿ ਉਹ ਚਾਹੁੰਦੀ ਹੈ ਕਿ ਜੂਨ ਦੇ ਲਈ ਨਵਾਂ ਐਪਾਰਟਮੈਂਟ ਐਡਰੈੱਸ ਹੋਵੇ। ਉਹ Shipping address ਖੋਲ੍ਹਦੀ ਹੈ ਅਤੇ ਇੱਕ ਚੇਤਾਵਨੀ ਵੇਖਦੀ ਹੈ: Changes to the next delivery are locked. You can still set an address for future deliveries. ਯੂਆਈ ਦੋ ਚੋਣਾਂ ਦਿੰਦਾ ਹੈ: Keep current address for June 12 (ਮੁੱਕਰਰ) ਅਤੇ Use new address starting July 12।

ਜੇ ਮਾਯਾ ਜੂਨ 12 ਲਈ ਐਡਰੈੱਸ ਬਲਦੇ ਨਾਲ ਕਿਸੇ ਤਰ੍ਹਾਂ ਫੋਰਸ ਕਰਦੀ ਹੈ, ਤਾਂ ਉਹਨੂੰ ਇੱਕ ਪੱਕਾ ਅਤੇ ਮਦਦਗਾਰ ਸੁਨੇਹਾ ਮਿਲਦਾ ਹੈ: Too late to change the June 12 shipment. Cutoff was May 9. ਸਕ੍ਰੀਨ ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਵਿਕਲਪ ਦਿਖਾਉਂਦੀ: Contact support to reroute (if possible) ਜਾਂ Set the new address for July onward।

ਇਹ ਹੀ ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਮੈਨੇਜਮੈਂਟ ਮਹਿਸੂਸ ਕਰਵਾਉਣਾ ਚਾਹੀਦਾ ਹੈ: ਸਪਸ਼ਟ ਤਾਰੀਖਾਂ, ਦਿੱਖ ਰਹਿਤ ਟੋਟਲ, ਨਿਰਧਾਰਤ ਕਟਆਫ, ਅਤੇ ਇੱਕ ਐਕਟਿਵਿਟੀ ਲੌਗ ਜੋ ਦੱਸਦਾ ਹੈ ਕਿ ਕੀ ਹੋਇਆ।

ਅਗਲੇ ਕਦਮ: ਨਿਯਮਾਂ ਨੂੰ ਇੱਕ ਕੰਮ ਕਰਨ ਵਾਲੀ ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਮੈਨੇਜਮੈਂਟ ਸਕ੍ਰੀਨ ਵਿੱਚ ਬਦਲੋ

ਸਕ੍ਰੀਨ ਨਹੀਂ, ਨਿਯਮਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਹਰ ਨਿਯਮ ਨੂੰ ਇੱਕ ਛੋਟੀ ਬਿਆਨ ਰੂਪ ਵਿੱਚ ਲਿਖੋ ਜੋ ਇੱਕ ਸਪੋਰਟ ਏਜੰਟ ਬਿਲਕੁਲ ਇੱਕੋ ਹੀ ਸ਼ਬਦਾਂ ਵਿੱਚ ਦੁਹਰਾ ਸਕੇ। ਜੇ ਤੁਹਾਡੀ ਟੀਮ ਦੇ ਦੋ ਲੋਕ ਇਕੋ ਸਥਿਤੀ ਨੂੰ ਵੱਖਰੇ ਢੰਗ ਨਾਲ ਸਮਝਾਉਂਦੇ ਹਨ, ਤਾਂ ਤੁਹਾਡੀ ਯੂਆਈ ਵੀ ਗੁੰਝਲਦਾਰ ਹੋਵੇਗੀ।

ਇੱਕ ਚੰਗੀ ਨਿਯਮ ਸੈਟ ਇਸ ਤਰ੍ਹਾਂ ਲੱਗਦੀ ਹੈ: “Changes to the next order must be made before 6pm two days prior,” ਜਾਂ “A pause stops future orders but doesn’t cancel the subscription.” ਸੂਚੀ ਛੋਟੀ ਰੱਖੋ ਅਤੇ ਡਿਜ਼ਾਈਨ ਤੋਂ ਪਹਿਲਾਂ ਫੈਸਲਾ ਕਰੋ।

ਪਹਿਲਾਂ ਅਨਿਵਾਰ ਜ਼ਰੂਰੀਆਂ ਦਾ ਪ੍ਰੋਟੋਟਾਈਪ ਬਣਾਓ

ਇੱਕ ਕਾਰਡ ਬਣਾਓ ਜੋ ਗਾਹਕ ਦੇ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦਾ: “ਅਗਲਾ ਕੀ ਹੋਵੇਗਾ?” ਤੁਹਾਡਾ “Next delivery” ਕਾਰਡ ਤਾਰੀਖ, ਐਡਰੈੱਸ, ਆਈਟਮ, ਕੀਮਤ, ਅਤੇ ਇਸ ਨੂੰ ਬਦਲਣ ਦਾ ਕਟਆਫ ਟਾਈਮ ਦਿਖਾਏ।

ਫਿਰ ਤਿੰਨ ਕਾਰਵਾਈਆਂ ਦਾ ਪ੍ਰੋਟੋਟਾਈਪ ਬਣਾਓ: Skip next, Pause for a period, ਅਤੇ Change address. ਹਰ ਕਾਰਵਾਈ ਪੁਸ਼ਟੀ ਨਾਲ ਖਤਮ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਜੋ ਨਵੀਂ ਅਗਲੀ ਤਾਰੀਖ ਅਤੇ ਜੇ ਗਾਹਕ ਨਢ਼ਲੇ ਤਾਂ ਕੀ ਹੋਵੇਗਾ ਉਹ ਦੋਹਰਾਏ।

ਟੈਸਟ ਕਰੋ, ਫਿਰ ਵੇਖਣਯੋਗਤਾ ਸ਼ਾਮਲ ਕਰੋ ਪਹਿਲਾਂ ਕਿ ਤੁਸੀਂ ਸਕੇਲ ਕਰੋ

5 ਤੋਂ 10 ਅਸਲੀ ਗਾਹਕਾਂ ਨਾਲ ਤੇਜ਼ ਟੈਸਟ ਚਲਾਓ (ਟੀਮਮੇਟਾਂ ਨਹੀਂ)। ਉਨ੍ਹਾਂ ਨੂੰ ਕੰਮ ਦਿਉ ਜਿਵੇਂ “ਅਗਲਾ ਆਰਡਰ ਸਕਿਪ ਕਰੋ” ਅਤੇ ਚੁਪ ਰਹੋ। ਵੇਖੋ ਕਿ ਉਹ ਕਿੱਥੇ ਹਿੱਕ-ਚੁੱਕ ਕਰਦੇ ਹਨ: ਸ਼ਬਦਾਵਲੀ, ਕਟਆਫ ਦੀ ਵਿਆਖਿਆ, ਛੂਟ ਗੁੰਮ ਹੋਣ ਦਾ ਡਰ। ਉਹਨਾਂ ਲਹਿਜ਼ਿਆਂ ਨੂੰ ਸੁਧਾਰੋ ਪਹਿਲਾਂ ਕਿ ਤੁਸੀਂ ਹੋਰ ਵਿਕਲਪ ਜੋੜੋ।

ਪੰਨੇ 'ਤੇ ਜਾਅਮਤ ਨੂੰ ਵਧਾਉਣ ਤੋਂ ਪਹਿਲਾਂ, ਦੋ ਚੀਜ਼ਾਂ ਸ਼ਾਮਲ ਕਰੋ ਜੋ ਸਪੋਰਟ ਕਾਓਸ ਰੋਕਣ:

  1. ਹਰ ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਬਦਲਾਅ ਲਈ ਲੌਗਿੰਗ (ਕਿਸਨੇ, ਕੀ, ਕਦੋਂ, ਪਿਛਲਾ ਮੁੱਲ, ਨਵਾਂ ਮੁੱਲ, ਕਟਆਫ ਸਥਿਤੀ)

  2. ਇੱਕ ਸਧਾਰਨ ਐਡਮਿਨ ਵ੍ਯੂ ਜੋ ਅਗਲਾ ਸ਼ਡਿਊਲ ਆਰਡਰ, ਆਖਰੀ ਕੁਝ ਬਦਲਾਅ, ਅਤੇ ਇਹ ਦਿੱਖ ਦਿੰਦਾ ਹੈ ਕਿ ਹਰ ਬਦਲਾਅ ਅਗਲੇ ਸ਼ਿਪਮੈਂਟ 'ਤੇ ਲਾਗੂ ਹੁੰਦਾ ਹੈ ਜਾਂ ਉਸ ਤੋਂ ਬਾਅਦ

ਜੇ ਤੁਸੀਂ ਇਹ ਨਿਯਮ ਤੇਜ਼ੀ ਨਾਲ ਪ੍ਰੋਟੋਟਾਈਪ ਵਿੱਚ ਬਦਲਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ Koder.ai (koder.ai) ਤੁਹਾਡੀ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ ਕਿ ਗੱਲ-ਬਾਤ ਤੋਂ ਫਲੋ ਬਣਾਉਣ ਅਤੇ ਐਪ ਜਨਰੇਟ ਕਰਨ ਵਿੱਚ, ਜਿਸ ਵਿੱਚ ਪੁਸ਼ਟੀਆਂ ਅਤੇ ਰੋਲਬੈਕ-ਫ੍ਰੈਂਡਲੀ ਸਨੈਪਸ਼ਾਟ ਸ਼ਾਮਲ ਹਨ।

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