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

ਗਿਫਟ ਕਾਰਡ ਬੈਲੈਂਸ ਚੈੱਕਰ ਪੇਜ਼ ਦਾ ਇੱਕ ਹੀ ਕੰਮ ਹੈ: ਕਿਸੇ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਅਤੇ ਬੇਫ਼ਿਕਰ ਤਰੀਕੇ ਨਾਲ ਦੱਸਣਾ ਕਿ ਕਾਰਡ 'ਤੇ ਕਿੰਨੀ ਰਕਮ ਬਾਕੀ ਹੈ। ਲੋਕ ਇਸਨੂੰ ਖਰੀਦ ਤੋਂ ਥੋੜ੍ਹਾ ਪਹਿਲਾਂ, ਕਾਰਡ ਮਿਲਣ ਮਗਰੋਂ, ਜਾਂ ਹਾਲੀਆ ਖਰੀਦ ਤੋਂ ਬਾਅਦ ਵਰਤਦੇ ਹਨ।
ਇਹ ਪੇਜ਼ ਆਮ ਤੌਰ 'ਤੇ ਦੋ ਦਰਸ਼ਕਾਂ ਲਈ ਸੇਵਾ ਕਰਦਾ ਹੈ:
ਸਪੱਸ਼ਟ ਕਰੋ ਕਿ ਤੁਸੀਂ ਆਪਣੇ ਸਟੋਰ 'ਚ “ਕੋਡ” ਨਾਲ ਕੀ ਮੁਰਾਦ ਰੱਖਦੇ ਹੋ। ਇਹ physical ਕਾਰਡ ਦੇ ਪਿੱਛੇ ਛਪਿਆ ਨੰਬਰ, ਈਮੇਲ ਵਿੱਚ ਆਇਆ ਕੋਡ, ਜਾਂ ਐਪ ਵਿੱਚ ਦਿਖਾਇਆ ਜਾਣ ਵਾਲਾ ਕੋਈ ਟੋਕਨ ਹੋ ਸਕਦਾ ਹੈ। ਕੁਝ ਪ੍ਰੋਗਰਾਮਾਂ PIN ਜਾਂ ਸਕ੍ਰੈਚ-ਆਫ਼ ਸੈਕਸ਼ਨ ਵੀ ਮੰਗਦੇ ਹਨ। ਜੇ ਤੁਹਾਨੂੰ ਕਾਰਡ ਨੰਬਰ ਅਤੇ PIN ਦੋਵਾਂ ਦੀ ਜ਼ਰੂਰਤ ਹੈ, ਤਾਂ ਇਹ ਤੁਰੰਤ ਦੱਸੋ ਤਾਂ ਜੋ ਲੋਕ ਸਮਾਂ ਖਰਾਬ ਨਾ ਕਰਨ।
ਇੱਕ ਚੰਗਾ ਅਨੁਭਵ ਪੇਸ਼ਬੱਧ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ: ਕੋਡ ਦਰਜ ਕਰਨ ਦੀ ਸਪੱਸ਼ਟ ਥਾਂ, ਇੱਕ ਵਖਰੀ “Check balance” ਕਾਰਵਾਈ, ਅਤੇ ਨਤੀਜਾ ਜੋ ਪੜ੍ਹਨ ਲਈ ਆਸਾਨ ਹੋਵੇ (ਮੁਦਰਾ ਅਤੇ “last updated” ਸਮਾਂ). ਜਦ ਕੁਝ ਗੜਬੜ ਹੋਵੇ, ਪੇਜ਼ ਨੂੰ ਬਰਾਮਦ ਕਰਨ ਦੇ ਤਰੀਕੇ ਦੱਸਣੇ ਚਾਹੀਦੇ ਹਨ ਤਾਂ ਕਿ ਵਿਅਕਤੀ ਫ਼ਸਿਆ ਮਹਿਸੂਸ ਨਾ ਕਰੇ।
ਸਹੀ ਜਾਣਕਾਰੀ ਮੁੱਖ ਮਕਸਦ ਹੈ। ਜੇ ਪੇਜ਼ ਗਲਤ ਰਕਮ ਦਿਖਾਉਂਦਾ ਹੈ, ਤਾਂ ਚੈੱਕਆਊਟ 'ਤੇ ਮੁੱਕਾਬਲਾ, ਵੱਧ ਸਪੋਰਟ ਕਾਲਾਂ ਅਤੇ ਭਰੋਸੇ ਦੀ ਘਾਟ ਹੁੰਦੀ ਹੈ।
ਗਿਫਟ ਕਾਰਡ ਬੈਲੈਂਸ ਚੈੱਕਰ ਪੇਜ਼ ਦੇ ਦੋ ਕੰਮ ਹੁੰਦੇ ਹਨ: ਗਾਹਕਾਂ ਨੂੰ ਇਹ ਪੁਸ਼ਟੀ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਨਾ ਕਿ ਕੀ ਬਚਿਆ ਹੈ, ਅਤੇ ਸਟਾਫ਼ ਨੂੰ ਕਾਊਂਟਰ 'ਤੇ ਬਦਲਾਅ ਕਰਨ ਲਈ ਸੁਰੱਖਿਅਤ ਤਰੀਕਾ ਦੇਣਾ। ਸਭ ਤੋਂ ਵਧੀਆ ਤਰੀਕੇ ਗਾਹਕ ਦੇ ਵੇਖਣ ਨੂੰ ਸਧਾਰਨ ਰੱਖਦੇ ਹਨ ਅਤੇ ਸ਼ਕਤੀਸ਼ਾਲੀ ਕਾਰਵਾਈਆਂ ਨੂੰ ਸਟਾਫ਼-ਕੇਵਲ ਸਕ੍ਰੀਨ ਦੇ ਪਿੱਛੇ ਰੱਖਦੇ ਹਨ।
ਗਾਹਕ ਪਾਸੇ, ਫਲੋ ਇੱਕ ਰਸੀਦ ਲੁਕਅਪ ਵਾਂਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਕੋਡ ਦਰਜ ਕਰੋ, ਚੈੱਕ 'ਤੇ ਟੈਪ ਕਰੋ, ਇੱਕ ਸਪਸ਼ਟ ਉੱਤਰ ਮਿਲੇ। ਬਾਕੀ ਰਹਿ ਗਿਆ ਬੈਲੈਂਸ ਸਟੋਰ ਦੀ ਮੁਦਰਾ ਵਿੱਚ ਦਿਖਾਓ ਅਤੇ “last updated” ਟਾਈਮਸਟੈਂਪ ਸ਼ਾਮਲ ਕਰੋ ਤਾਂ ਕਿ ਲੋਕ ਜਾਣ ਸਕਣ ਨਤੀਜਾ ਮੌਜੂਦਾ ਹੈ।
ਸਟਾਫ਼ ਪਾਸੇ, ਫਲੋ ਹੈ: ਲੁਕਅਪ, ਵੇਰੀਫਾਈ, ਫਿਰ ਸੋਧ। ਸਟਾਫ਼ ਨੂੰ ਕੋਡ ਰਾਹੀਂ ਕਾਰਡ ਲੱਭਣ ਦੀ ਸਮਰੱਥਾ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ (ਅੱਗੇ ਸਕੈਨਿੰਗ ਵੀ ਚੁਣ ਸਕਦੇ ਹੋ), ਮੌਜੂਦਾ ਬੈਲੈਂਸ ਅਤੇ ਹਾਲੀਆ ਗਤੀਵਿਧੀ ਵੇਖਣ, ਫਿਰ ਵੈਲਯੂ जोड़ਨਾ (ਟਾਪ-ਅੱਪ) ਜਾਂ ਘਟਾਉਣਾ (ਮੈਨੂਅਲ ਰੀਡੀਮਪਸ਼ਨ ਜਾਂ ਸੁਧਾਰ)। ਹਰ ਸੋਧ ਲਈ ਇੱਕ ਛੋਟਾ ਕਾਰਨ ਲਾਜ਼ਮੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਸੰਭਵ ਹੋਵੇ ਤਾਂ ਇੱਕ ਰੈਫਰੈਂਸ (ਜਿਵੇਂ ਰਸੀਦ ਨੰਬਰ) ਵੀ।
ਅਕਸਰ ਟੀਮਾਂ ਪਹਿਲਾ ਵਰਜਨ ਆਉਟ ਮੁਕਾਬਲਾ ਕਰਦੀਆਂ ਹਨ ਜਿਸ ਵਿੱਚ:
ਉਦਾਹਰਣ: ਇੱਕ ਕੈਫੇ $25 ਗਿਫਟ ਕਾਰਡ ਵੇਚਦੀ ਹੈ। ਇੱਕ ਗਾਹਕ ਕੋਡ ਦਰਜ ਕਰਦਾ ਹੈ ਅਤੇ ਵੇਖਦਾ ਹੈ “$13.40 remaining, updated 2 minutes ago.” ਬਾਅਦ ਵਿੱਚ, ਇੱਕ ਸਟਾਫ਼ ਮੈਂਬਰ ਨੂੰ ਪਤਾ ਲੱਗਦਾ ਹੈ ਕਿ ਰਜਿਸਟਰ ਨੇ ਇੱਕ ਰੀਡੀਮਪਸ਼ਨ ਛੱਡ ਦਿੱਤੀ ਸੀ, ਉਹ ਉਹੀ ਕੋਡ ਲੱਭਦਾ ਹੈ, $4.60 ਘਟਾਉਂਦਾ ਹੈ, ਅਤੇ ਨੋਟ “latte, receipt 887” ਨਾਲ ਸੇਵ ਕਰਦਾ ਹੈ।
ਐਜ ਕੇਸ ਸਪੋਰਟ ਟਿਕਟਾਂ ਦਾ ਕਾਰਣ ਬਣਦੇ ਹਨ, ਇਸ ਲਈ ਉਨ੍ਹਾਂ ਨੂੰ ਠੰਢੇ ਦਿਮਾਗ ਨਾਲ ਸੰਭਾਲੋ:
ਗਾਹਕ ਬਹੁਤ ਵਾਰ ਫ਼ੋਨ 'ਤੇ ਹੁੰਦਾ ਹੈ, ਕਾਊਂਟਰ 'ਤੇ ਖੜਾ ਅਤੇ ਲਾਈਨ ਰੋਕਣਾ ਨਹੀਂ ਚਾਹੁੰਦਾ। ਇਸ ਲਈ ਪੇਜ਼ ਤੇਜ਼, ਸ਼ਾਂਤ ਅਤੇ ਗਲਤ ਕਰਨ ਲਈ ਔਖਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
ਇਨਪੁੱਟ ਸਧਾਰਨ ਰੱਖੋ। ਕੋਡ ਲਈ ਇੱਕ ਫੀਲਡ ਰੱਖੋ, ਸਪੱਸ਼ਟ ਲੇਬਲ ਨਾਲ (ਸਿਰਫ਼ placeholder ਨੂ ਨਹੀਂ). ਇੱਕ ਛੋਟੀ ਉਦਾਹਰਨ ਫਾਰਮੈਟ ਜਿਵੇਂ “Example: ABCD-EFGH-IJKL” ਦਿਖਾਓ, ਅਤੇ ਪੇਸਟ-ਫ੍ਰੈਂਡਲੀ ਬਣਾਓ। ਉਹ ਤਰ੍ਹਾਂ ਦਾ ਫਾਰਮੈਟਿੰਗ ਜੋ ਉਪਭੋਗਤਾ ਦੇ ਟਾਈਪ ਕੀਤੇ ਨੂੰ ਬਦਲ ਦੇਵੇ,避 ਕਰੋ।
ਕਾਰਵਾਈ ਨੂੰ ਵਖਰਾ ਬਣਾਓ। “Check balance” “Submit” ਨਾਲੋਂ ਵੱਧ ਸਪਸ਼ਟ ਹੈ। ਟੈਪ ਕਰਨ 'ਤੇ ਲੋਡਿੰਗ ਸਥਿਤੀ ਦਿਖਾਓ (“Checking…”) ਅਤੇ ਬਟਨ ਨੂੰ ਨਿਸ਼ਕ੍ਰਿਯ ਕਰੋ ਤਾਂ ਕਿ ਬੇੜਿ ਕਾਲ ਭੇਜ਼ੀ ਨਾ ਜਾਏ।
ਏਰਰ ਸੁਨੇਹੇ ਸਚੇ ਗਾਹਕਾਂ ਨੂੰ ਬਹਾਲ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ, ਪਰ ਗੈਸਿੰਗ ਕਰਨ ਵਾਲਿਆਂ ਨੂੰ ਘੱਟ ਜਾਣਕਾਰੀ ਦਿੰਦੇ ਹੋਏ। ਪਬਲਿਕ ਗਾਹਕ ਪੇਜ਼ 'ਤੇ ਫੇਲਯਰ ਜਨਰਿਕ ਰਖੋ। ਵਿਸਥਾਰ (expired, blocked, not found) ਸਿਰਫ ਸਟਾਫ਼ ਸਕ੍ਰੀਨ 'ਤੇ ਦਿਖਾਓ ਜਦੋਂ ਕਿਸੇ ਨੇ ਖੁਦ ਸਾਹਮਣੇ ਵੈਰੀਫਾਈ ਕੀਤਾ ਹੋਵੇ।
ਇਕ ਛੋਟਾ UX ਚੈਕਲਿਸਟ ਜੋ ਜ਼ਿਆਦਾਤਰ ਗੁੰਝਲਦਾਰੀਆਂ ਰੋਕਦਾ ਹੈ:
ਪਹੁੰਚਯੋਗਤਾ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਲੇਬਲ ਇਨਪੁੱਟ ਨਾਲ ਜੁੜਿਆ ਹੈ, ਕੀਬੋਰਡ ਉਪਭੋਗਤਾਈਆਂ ਬਟਨ ਤੱਕ ਪਹੁੰਚ ਸਕਦੇ ਹਨ, ਫੋਕਸ ਆਊਟਲਾਈਨ ਦਿੱਖਦੇ ਹਨ, ਅਤੇ ਰੋਸ਼ਨੀ ਵਿੱਚ ਪੜ੍ਹਨ ਯੋਗ ਕਾਨਟਰਾਸਟ ਹੈ।
ਚੰਗਾ ਸਟਾਫ਼ ਐਡਮਿਨ ਸਕ੍ਰੀਨ ਸਭ ਤੋਂ ਵਧੀਆ ਤਰ੍ਹਾਂ ਸੁਸਤ ਹੁੰਦਾ ਹੈ। ਇਹ ਕਰਮਚਾਰੀਆਂ ਨੂੰ ਸਕਿੰਟਾਂ ਵਿੱਚ ਗਿਫਟ ਕਾਰਡ ਮੁਕਾਮਲ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ, ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਇੱਕ ਸਾਫ਼ ਟ੍ਰੇਲ ਛੱਡਦਾ ਹੈ।
ਸਟਾਫ਼ ਲੋਗਇਨ ਅਤੇ ਸਧਾਰਨ ਰੋਲਜ਼ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਜ਼ਿਆਦਾਤਰ ਸਟਾਫ਼ ਕਾਰਡ ਲੁਕਅਪ ਅਤੇ ਇਤਿਹਾਸ ਵੇਖ ਸਕਦੇ ਹਨ, ਜਦ ਕਿ ਕੇਵਲ ਮੈਨੇਜਰ ਜਾਂ ਛੋਟੀ ਭਰੋਸੇਮੰਦ ਟੀਮ ਬੈਲੈਂਸ ਬਦਲ ਸਕਦੀ ਹੈ। ਜੇ ਤੁਸੀਂ ਕਈ ਲੋਕੇਸ਼ਨਾਂ 'ਚ ਚਲਾਉਂਦੇ ਹੋ, ਤਾਂ ਬਦਲਾਅ ਨੂੰ ਇੱਕ ਸਟੋਰ/ਲੋਕੇਸ਼ਨ ਨਾਲ ਟੈਗ ਕਰੋ।
ਲੁਕਅਪ ਨੂੰ ਤੇਜ਼ ਅਤੇ ਮਾਨਯੋਗ ਬਣਾਓ। ਸਪੇਸ ਅਤੇ ਡੈਸ਼ ਲੈਖ ਖੋਜ ਨੂੰ ਟੁਟਣ ਨਾ ਦੇਣ। ਅਸਲੀ ਦੁਨੀਆ ਦੇ ਕੇਸਾਂ ਵਿੱਚ ਜਿੱਥੇ ਕੋਡ ਖਰਾਬ ਜਾਂ ਪੜ੍ਹਨ ਯੋਗ ਨਹੀਂ ਹੈ, ਤੁਸੀਂ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ (ਅਤੇ ਸਿਰਫ਼ ਸਟਾਫ਼ ਲਈ) ਵਿਕਲਪਿਕ ਦੂਜੇ ਖੋਜ ਵਿਕਲਪ ਦੈ ਸਕਦੇ ਹੋ, ਜਿਵੇਂ ਰਸੀਦ/ਆਰਡਰ ID, ਜਾਂ ਗਾਹਕ ਈਮੇਲ/ਫ਼ੋਨ ਜੇ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਇਹ ਇਕੱਠੇ ਕਰਦੇ ਹੋ।
ਕਾਰਡ ਮਿਲਣ 'ਤੇ, ਸੋਧ ਨਿਰਦੇਸ਼ਾਂ ਤੋਂ ਪਹਿਲਾਂ ਮੌਜੂਦਾ ਬੈਲੈਂਸ ਅਤੇ ਹਾਲੀਆ ਗਤੀਵਿਧੀ ਦਿਖਾਓ। ਇਹ clássico ਗਲਤੀ ਘਟਾਉਂਦਾ ਹੈ: ਗਲਤ ਕਾਰਡ ਨੂੰ ਸੋਧਣਾ ਕਿਉਂਕਿ ਕਈ ਟੈਬ ਖੁਲੇ ਹਨ।
ਸੋਧ ਫਾਰਮ ਨੂੰ free-form ਦੀ ਥਾਂ ਸੰਰਚਿਤ ਰੱਖੋ:
ਰਕਮ ਦਰਜ ਕਰਨ ਤੋਂ ਬਾਅਦ ਨਤੀਜਾ ਸਪਸ਼ਟ ਤਰੀਕੇ ਨਾਲ ਪ੍ਰੀਵਿਊ ਕਰੋ: “Current balance: $40.00. New balance: $15.00.” ਵੱਡੇ ਬਦਲਾਵਾਂ ਲਈ ਪੱਕੀ ਪੁਸ਼ਟੀ ਦਾ ਕਦਮ ਸ਼ਾਮਲ ਕਰੋ (ਉਦਾਹਰਣ ਲਈ, $100 ਤੋਂ ਵੱਧ ਜਾਂ ਮੌਜੂਦਾ ਬੈਲੈਂਸ ਦਾ 25% ਤੋਂ ਵੱਧ)। ਉੱਚ-ਖਤਰੇ ਵਾਲੇ ਬਦਲਾਅ ਲਈ ਮੈਨੇਜਰ PIN ਜਾਂ ਰਕਮ ਨੂੰ ਮੁੜ ਦਰਜ ਕਰਨ ਦੀ ਲੋੜ ਰੱਖੋ।
ਗਿਫਟ ਕਾਰਡ ਬੈਲੈਂਸ ਚੈੱਕਰ ਪੇਜ਼ ਸੁਨਦਰਤਾ ਵਿੱਚ ਸਾਦਾ ਲੱਗਦਾ ਹੈ, ਪਰ ਇਹ ਅਨੁਮਾਨ, ਦੁਪਹਿਰ ਅਤੇ ਇਮਾਨਦਾਰ ਗਲਤੀਆਂ ਨੂੰ ਆਕਰਸ਼ਿਤ ਕਰਦਾ ਹੈ। ਲਕੜੀ ਦਾ ਮਕਸਦ ਪਰਫੈਕਟ ਸੁਰੱਖਿਆ ਨਹੀਂ — ਇਹ ਆਸਾਨ ਹਮਲਿਆਂ ਨੂੰ ਰੋਕਣਾ ਅਤੇ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਆਸਾਨੀ ਨਾਲ ਪਹਚਾਣਣਯੋਗ ਬਨਾਉਣਾ ਹੈ।
ਗਿਫਟ ਕਾਰਡ ਕੋਡ ਨੂੰ ਪਾਸਵਰਡ ਵਾਂਗ ਸਮਝੋ। ਜੇ ਕਿਸੇ ਕੋਲ ਕੋਡਾਂ ਦੀ ਸੂਚੀ ਆ ਜਾਏ, ਉਹ ਤੇਜ਼ੀ ਨਾਲ ਮੁੱਲ ਖਤਮ ਕਰ ਸਕਦੇ ਹਨ।
ਦੋ ਮੁੱਢਲੇ ਨਿਯਮ ਬਹੁਤ ਕੰਮ ਆਉਂਦੇ ਹਨ: ਕੋਡਾਂ ਨੂੰ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਸੰਭਾਲੋ, ਅਤੇ ਤੇਜ਼ੀ ਨਾਲ ਕਈ ਕੋਡਾਂ ਨੂੰ ਟੈਸਟ ਕਰਨਾ ਔਖਾ ਬਣਾਓ। ਬਹੁਤ ਸਿਸਟਮ ਸ.raw ਕੋਡ ਸਪਸ਼ਟ ਪਾਠ ਵਿੱਚ ਸਟੋਰ ਕਰਨ ਤੋਂ ਬਚਦੇ ਹਨ। ਬਜਾਏ, ਉਹ ਇੱਕ ਸੁਰੱਖਿਅਤ ਰੂਪ (ਜਿਵੇਂ ਇੱਕ-ਦਿਸ਼ਾ ਵਾਲਾ ਹੈਸ਼) ਵਿੱਚ ਰੱਖਦੇ ਹਨ, ਤਾਂ ਕਿ ਡੇਟਾਬੇਸ ਲੀਕ ਹੋਣ 'ਤੇ ਹਮਲਾਕਾਰਾਂ ਦੇ ਹੱਥ ਕੰਮਯਾਬ ਕੋਡ ਨਾ ਲੱਗਣ।
ਗਾਹਕ ਸਕ੍ਰੀਨ 'ਤੇ, ਲੁਕਅਪ ਮਗਰੋਂ ਪੂਰਾ ਕੋਡ ਵਾਪਸ ਨਾ ਦਿਖਾਓ। ਕੋਡ ਦਾ ਮਾਸਕਡ ਵਰਜਨ ਦਿਖਾਓ (ਉਦਾਹਰਨ ਲਈ, ਸਿਰਫ਼ ਆਖਰੀ 4 ਅੱਖਰ) ਤਾਂ ਕਿ ਸਕ੍ਰੀਨਸ਼ੌਟ ਅਤੇ ਸ਼ੋਲਡਰ-ਸਰਫਿੰਗ ਘੱਟ ਨੁਕਸਾਨ ਪਹੁੰਚਾ ਸਕਣ।
ਰੇਟ ਲਿਮਿਟਸ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹਨ। ਬਿਨਾਂ ਇਨ੍ਹਾਂ ਦੇ, ਇੱਕ ਬੋਟ ਹਜ਼ਾਰਾਂ ਜੋੜ੍ਹ-ਘਟਾ ਕੋਸ਼ਿਸ਼ ਕਰ ਸਕਦੀ ਹੈ। ਸਧਾਰਨ ਨੀਤੀਆਂ:
ਅਸਲੀ ਨੁਕਸਾਨ ਅਕਸਰ ਸਟਾਫ਼ ਸੋਧਾਂ ਤੋਂ ਹੁੰਦੇ ਹਨ ਜਿਨ੍ਹਾਂ 'ਤੇ ਕਾਫ਼ੀ ਨਿਯੰਤਰਣ ਨਹੀਂ ਹੁੰਦੇ, ਨਾ ਕਿ ਫਿਲਮ-ਸਟਾਈਲ ਹੈਕਿੰਗ ਤੋਂ। ਹਰ ਬੈਲੈਂਸ ਚੇਨਜ ਲਈ ਇੱਕ ਆਡੀਟ ਟਰੇਲ ਬਣਨਾ ਚਾਹੀਦਾ ਹੈ: ਕਿਸ ਨੇ ਕੀਤਾ, ਕਦੋਂ ਕੀਤਾ, ਕਿੰਨੀ ਰਕਮ ਅਤੇ ਕਿਉਂ।
ਸਟਾਫ਼ ਦੀ ਐਕਸੈਸ ਤੰਗ ਰੱਖੋ। ਹਰ ਕਿਸੇ ਨੂੰ ਸੋਧ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ। ਸ਼ੇਅਰਡ ਲੋਗਇਨ ਤੋਂ ਬਚੋ, ਕਿਉਂਕਿ ਉਹ ਆਡੀਟ ਟਰੇਲ ਨੂੰ ਬੇਕਾਰ ਬਣਾਉਂਦੇ ਹਨ।
ਰਿਫੰਡ ਅਤੇ ਚਾਰਜਬੈਕ ਦਾ ਅਸਰ ਗਿਫਟ ਕਾਰਡਾਂ 'ਤੇ ਕਿਵੇਂ ਪੈਊਂਦਾ ਹੈ, ਇਹ ਇੱਕ ਸਧਾਰਨ ਅੰਦਰੂਨੀ ਨਿਯਮ ਵਿੱਚ ਲਿਖੋ। ਉਦਾਹਰਨ ਲਈ: ਜੇ ਸੰਭਵ ਹੋਵੇ ਤਾਂ ਰਿਫੰਡ ਮੁੱਲ ਮੁਲ ਨੂੰ ਅਸਲ ਗਿਫਟ ਕਾਰਡ 'ਤੇ ਵਾਪਸ ਕਰ ਦਿਓ; ਜੇ ਕਾਰਡ ਪਹਿਲਾਂ ਹੀ ਖਰਚ ਹੋ ਚੁੱਕਾ ਹੋਵੇ, ਤਾਂ ਕੇਸ ਰਿਵਿਊ ਲਈ ਝੰਡਾ ਕੀਤਾ ਜਾਵੇ।
ਪੇਜ਼ ਸਧਾਰਨ ਲੱਗਦਾ ਹੈ, ਪਰ ਪਿੱਛੇ ਦਾ ਡਾਟਾ ਪਰੂਖ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਇੱਕ ਸੁਰੱਖਿਅਤ ਤਰੀਕਾ ਇਹ ਹੈ: ਇੱਕ ਹੀ ਸਵੈ-ਸੰਪਾਦਨਯੋਗ “balance” ਨੰਬਰ 'ਤੇ ਨਿਰਭਰ ਨਾ ਰੱਖੋ ਬਿਨਾਂ ਇੱਕ ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨ ਟ੍ਰੇਲ ਦੇ ਜੋ ਇਸਦੀ ਵਿਆਖਿਆ ਕਰੇ।
ਆਮ ਸਰੰਚਨਾ ਤਿੰਨ ਟੇਬਲ ਵਰਤਦੀ ਹੈ:
ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨ ਟੇਬਲ ਨੂੰ ਸੱਚਾਈ ਦਾ ਸਰੋਤ ਮੰਨੋ। ਆਮ ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨ ਕਿਸਮਾਂ ਵਿੱਚ issuance (ਸ਼ੁਰੂਆਤੀ ਲੋਡ), redemption (ਖਰੀਦ), adjustment (ਸਟਾਫ਼ ਸੁਧਾਰ), ਅਤੇ refund (ਰੀਡੀਮਪਸ਼ਨ ਦੀ ਵਾਪਸੀ) ਸ਼ਾਮਲ ਹੁੰਦੀਆਂ ਹਨ। ਤੁਸੀਂ ਮੌਜੂਦਾ ਬੈਲੈਂਸ ਨੂੰ ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨਾਂ ਦੇ ਜੋੜ ਵਜੋਂ ਗਣਨਾ ਕਰ ਸਕਦੇ ਹੋ, ਜਾਂ ਕਾਰਡ ਰਿਕਾਰਡ 'ਤੇ ਇੱਕ cached balance ਰੱਖ ਸਕਦੇ ਹੋ ਜਿਸਨੂੰ ਧਿਆਨ ਨਾਲ ਅਪਡੇਟ ਕੀਤਾ ਜਾਏ।
ਕਿਸੇ ਵਿਅਕਤੀ ਦੇ ਇੱਕ ਹੀ ਲੇਨ-ਦੇਨ ਨੂੰ ਦੁਹਰਾਉਣ ਤੋਂ ਰੋਕਣ ਲਈ idempotency key ਵਰਤੋ। ਇਸ ਨਾਲ ਹਰ ਚੈੱਕਆਊਟ ਜਾਂ ਐਡਜਸਟਮੈਂਟ ਨੂੰ ਇੱਕ ਵਿਲੱਖਣ ਓਪਰੇਸ਼ਨ ID ਮਿਲਦਾ ਹੈ, ਅਤੇ ਦੁਹਰਾਈ ਗਈ ਸਬਮਿਟਾਂ ਨਜ਼ਰਅੰਦਾਜ਼ ਕੀਤੀਆਂ ਜਾਣ।
ਆਡਿਟ ਅਤੇ ਸਹਾਇਤਾ ਲਈ ਕੁਝ ਫੀਲਡ ਬਹੁਤ ਕੀਮਤੀ ਹੁੰਦੇ ਹਨ:
ਕਿਸੇ ਵੀ ਚੀਜ਼ ਨੂੰ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਨਿਰਣਾ ਕਰੋ ਕਿ ਗਾਹਕ ਨੂੰ ਕੀ ਦਿਖਾਈ ਦੇਣਾ ਹੈ। ਪੇਜ਼ ਵਿੱਚ ਦਿਖਾਓ ਕਿ ਕੋਡ ਕਿੱਥੇ ਮਿਲੇਗਾ, ਸਾਡੀ ਦੁਕਾਨ ਵਿੱਚ “balance” ਦਾ ਕੀ ਅਰਥ ਹੈ, ਅਤੇ ਜੇ ਲੁਕਅਪ ਫੇਲ ਹੋਵੇ ਤਾਂ ਕੀ ਕਰਨਾ ਹੈ। ਨਤੀਜੇ ਸਕ੍ਰੀਨ 'ਤੇ ਬੈਲੈਂਸ, ਮੁਦਰਾ, ਅਤੇ ਇੱਕ ਸਪਸ਼ਟ “last updated” ਸਮਾਂ ਦਿਖਾਓ।
ਕੋਡ ਨਿਯਮ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ ਅਤੇ ਜਲਦੀ ਵੈਲਿਡੇਟ ਕਰੋ। ਇੱਕ ਨਿਸ਼ਚਿਤ ਲੰਬਾਈ ਚੁਣੋ ਅਤੇ ਸਿਰਫ਼ ਉਹ ਹੀ ਅੱਖਰ ਆਗਿਆ ਦਿਓ ਜੋ ਤੁਸੀਂ ਆਪਣੀ ਛਪਾਈ ਵਿੱਚ ਵਰਤਦੇ ਹੋ। ਟਾਈਪਿੰਗ ਦੌਰਾਨ ਅਤੇ ਫਿਰ ਸਬਮਿਟ 'ਤੇ ਵੈਲਿਡੇਸ਼ਨ ਕਰੋ, ਤਾਂ ਜੋ ਤੁਸੀਂ ਟਾਇਪੋਜ਼ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਫੜ ਸਕੋ ਬਿਨਾਂ ਵਧੇਰੇ ਵੇਰਵੇ ਦੇ।
ਗਾਹਕ ਲੁਕਅਪ ਫਲੋ ਨੂੰ ਛੋਟੇ ਕਦਮਾਂ ਵਿੱਚ ਬਣਾਓ: ਇਨਪੁੱਟ ਸਕ੍ਰੀਨ ਬਣਾਓ, ਸਬਮਿਟ 'ਤੇ ਬੈਕਏਂਡ ਨੂੰ ਕਾਲ ਕਰੋ, ਫਿਰ ਤਿੰਨ ਨਤੀਜੇ ਸੰਭਾਲੋ - ਮਿਲਿਆ (found), ਨਹੀਂ ਮਿਲਿਆ/ਅਵੈਧ (not found/invalid), ਅਤੇ ਅਸਥਾਈ ਰੂਪ ਵਿੱਚ ਅਣ ਉਪਲੱਬਧ (temporarily unavailable)।
ਫਿਰ ਸਟਾਫ਼ ਪਾਸਾ ਸ਼ਾਮਲ ਕਰੋ। ਸਟਾਫ਼ ਨੂੰ ਕੁਝ ਵੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਸਾਈਨ ਇਨ ਕਰਵਾਓ, ਅਤੇ ਹਰ ਬਦਲਾਅ ਲਈ ਇੱਕ ਸਪਸ਼ਟ ਕਾਰਨ ਲਾਜ਼ਮੀ ਕਰੋ। ਪੁਸ਼ਟੀਕਰਨ ਕਦਮ ਵਿੱਚ ਕੋਡ ਅਤੇ ਰਕਮ ਨੂੰ ਦੁਹਰਾਓ।
ਜਦੋਂ ਸੋਧ ਕੰਮ ਕਰਨ ਲੱਗੇ, ਇਤਿਹਾਸ ਸ਼ਾਮਲ ਕਰੋ। ਹਰ ਗਿਫਟ ਕਾਰਡ ਨੂੰ ਇੱਕ ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨ ਸੂਚੀ ਅਤੇ ਆਡੀਟ ਲੌਗ ਦਿਖਾਉ ਜਿਸ ਵਿੱਚ ਲਿਖਿਆ ਹੋਵੇ ਕਿ ਕਿਸਨੇ ਕੌਣ-ਕਿਆ ਤੇ ਕਦੋਂ ਕੀਤਾ।
ਅਖ਼ੀਰ ਵਿੱਚ, ਲਾਂਚ ਤੋਂ ਪਹਿਲਾਂ ਅਸਲੀ ਸਥਿਤੀਆਂ ਦੀ ਜਾਂਚ ਕਰੋ: ਇੱਕ ਟਾਈਪੋ, ਜ਼ੀਰੋ ਬੈਲੈਂਸ, ਇੱਕ ਹਿੱਸਾ ਰੀਡੀਮਪਸ਼ਨ, ਰਿਫੰਡ ਜੋ ਮੁੱਲ ਵਾਪਸ ਕਰਦਾ ਹੈ, ਅਤੇ ਦੋ ਸਟਾਫ਼ ਮੈਂਬਰਾਂ ਵੱਲੋਂ ਇੱਕੇ ਕਾਰਡ 'ਤੇ ਮਿਲੀ-ਜੁਲੀ ਸੋਧਾਂ।
ਜ਼ਿਆਦਾਤਰ ਸਪੋਰਟ ਟਿਕਟਾਂ ਦੋ ਚੀਜ਼ਾਂ ਕਾਰਨ ਹੁੰਦੀਆਂ ਹਨ: ਇਮਾਨਦਾਰ ਗਾਹਕਾਂ ਲਈ ਅਸਪੱਸ਼ਟ ਫੀਡਬੈਕ, ਅਤੇ ਸਟਾਫ਼ ਕਾਰਵਾਈਆਂ ਲਈ ਰਿਕਾਰਡ ਦੀ ਘਾਟ।
ਇੱਕ ਆਮ ਫੜ ਇਹ ਹੈ ਕਿ ਪਬਲਿਕ ਏਰਰ ਸੁਨੇਹੇ ਬਹੁਤ ਵਿਸਥਾਰਵਾਰ ਹੋ ਜਾਣ। “ਕੋਡ ਮੌਜੂਦ ਹੈ ਪਰ ਅਣਸਰਗਰ” ਵਰਗੀਆਂ ਜਾਣਕਾਰੀਆਂ ਹਮਲਾਕਾਰਾਂ ਨੂੰ ਮਦਦ ਕਰ ਸਕਦੀਆਂ ਹਨ। ਗਾਹਕ-ਸਾਮ੍ਹਣੇ ਸੁਨੇਹਾ ਨਿਊਟਰਲ ਰੱਖੋ, ਅਤੇ ਵਿਸਥਾਰ ਸਿਰਫ਼ ਸਟਾਫ਼ ਟੂਲ 'ਤੇ ਵੇਰਵਾ-ਪੂਰਨ ਤਰੀਕੇ ਨਾਲ ਦਿਖਾਓ।
ਹੋਰ ਟਿਕਟ ਬਣਨ ਵਾਲੀ ਗਲਤੀ ਹੈ ਕਿ ਸਟਾਫ਼ ਬਿਨਾਂ ਦਿਕਤ ਦੇ ਬੈਲੈਂਸ ਬਦਲ ਸਕਦਾ ਹੈ। ਜਦੋਂ ਕੋਈ ਕਹਿੰਦਾ ਹੈ, “ਮੇਰੇ ਕਾਰਡ 'ਤੇ ਕੱਲ $50 ਸੀ,” ਤੁਹਾਨੂੰ ਤੁਰੰਤ ਇੱਕ ਜਵਾਬ ਚਾਹੀਦਾ ਹੈ। ਚੁੱਪਾਚੁਪ ਸੋਧਾਂ ਇੱਕ he-said-she-said ਹਾਲਤ ਪੈਦਾ ਕਰ ਦਿੰਦੀਆਂ ਹਨ।
ਜਿਆਦਾ ਨੁਕਸਾਨ ਪੈਨ ਵਾਲੀਆਂ ਗਲਤੀਆਂ:
ਉਦਾਹਰਨ: ਇੱਕ ਕੈਸ਼ੀਅਰ $25 ਰੀਡੀਮਪਟ ਕਰਦਾ ਹੈ, ਟੈਬਲੈਟ ਦੇਰੀ ਕਰਦਾ ਹੈ, ਅਤੇ ਉਹ ਫਿਰ “Confirm” ਨੂੰ ਦੁਹਰਾਉਂਦਾ ਹੈ। ਬਿਨਾਂ ਸੁਰੱਖਿਆ ਦੇ, ਸਿਸਟਮ ਦੋ ਰੀਡੀਮਪਸ਼ਨ ਰਿਕਾਰਡ ਕਰ ਸਕਦਾ ਹੈ। ਇਸਨੂੰ ਠੀਕ ਕਰਨ ਲਈ ਹਰ ਬਦਲਾਅ ਨੂੰ ਇੱਕ ਇਕਾਈ ਰਿਕਾਰਡ ਸਮਝੋ, ਅਤੇ “Confirm” ਨੂੰ ਦੁਹਰਾਉਣ-ਮੁਕਤ ਬਣਾਓ।
ਪ੍ਰਕਾਸ਼ਨ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਤੇਜ਼ “ਤੁਸੀਂ ਗਾਹਕ ਹੋ ਕੇ ਜਾਂਚ ਕਰੋ” ਦੌੜ ਲਗਾਓ, ਫਿਰ “ਤੁਸੀਂ ਸਟਾਫ਼ ਹੋ ਕੇ ਜਾਂਚ ਕਰੋ”।
ਗਾਹਕ ਚੈਕ ਕਰਨ ਲਈ:
ਸਟਾਫ਼ ਚੈਕ ਕਰਨ ਲਈ:
ਆਪਣੀ ਭਾਸ਼ਾ ਦੀ ਜਾਂਚ ਵੀ ਕਰੋ। “gift card balance” ਨੂੰ “store credit” ਨਾਲ ਨਾ ਮਿਲਾਓ ਜੇ ਉਹ ਅਸਲ ਵਿੱਚ ਇੱਕੋ ਹੀ ਨਹੀਂ ਹਨ। ਜੇ ਕੋਈ ਸੀਮਾਵਾਂ ਹਨ (expiry dates, in-store only), ਇਕ ਛੋਟੀ ਵਾਕ ਵਿੱਚ ਦੱਸ ਦਿਓ।
ਕਲਪਨਾ ਕਰੋ ਇੱਕ ਛੋਟੀ ਦੁੱਖਾਨ ਦੀ ਜੋ ਰਜਿਸਟਰ 'ਤੇ physical gift cards ਵੇਚਦੀ ਹੈ। ਗਾਹਕ ਘਰ ਤੋਂ ਆਪਣਾ ਬੈਲੈਂਸ ਚੈੱਕ ਕਰ ਸਕਦੇ ਹਨ, ਅਤੇ ਸਟਾਫ਼ ਦੁਕਾਨ 'ਚ ਕਾਰਡ ਰੀਡੀਮਪਟ ਕਰ ਸਕਦੇ ਹਨ।
ਐਤਵਾਰ ਰਾਤ ਨੂੰ, Maya ਨੂੰ ਇੱਕ ਡਰਾਅਰ ਵਿੱਚ ਇੱਕ ਗਿਫਟ ਕਾਰਡ ਮਿਲਦਾ ਹੈ। ਉਹ ਦੁਕਾਨ ਦੇ ਬੈਲੈਂਸ ਚੈੱਕਰ ਪੇਜ਼ ਨੂੰ ਖੋਲ੍ਹਦੀ ਹੈ, ਕਾਰਡ ਦੇ ਪਿੱਛੇ ਲਿਖਿਆ ਕੋਡ ਟਾਈਪ ਕਰਦੀ ਹੈ, ਅਤੇ ਇੱਕ ਸਧਾਰਨ ਨਤੀਜਾ ਵੇਖਦੀ ਹੈ: ਮੌਜੂਦਾ ਬੈਲੈਂਸ, last update ਸਮਾਂ, ਅਤੇ ਕੋਡ ਨੂੰ ਨਿੱਜੀ ਰੱਖਣ ਦੀ ਇੱਕ ਛੋਟੀ ਯਾਦ। ਕੋਈ اکਾਉਂਟ ਲੋੜੀਦਾ ਨਹੀਂ।
ਸੋਮਵਾਰ ਨੂੰ, Maya $38.50 ਦੀਆਂ ਚੀਜ਼ਾਂ ਖਰੀਦਦੀ ਹੈ ਅਤੇ ਗਿਫਟ ਕਾਰਡ ਨਾਲ ਭੁਗਤਾਨ ਕਰਦੀ ਹੈ। ਚੈੱਕਆਊਟ 'ਤੇ, ਸਟਾਫ਼ ਐਡਮਿਨ ਸਕ੍ਰੀਨ ਖੋਲ੍ਹਦੇ ਹਨ, ਓਹੇ ਕੋਡ ਲੱਭਦੇ ਹਨ, ਅਤੇ ਇੱਕ ਹਿੱਸਾ ਰੀਡੀਮਪਸ਼ਨ ਦਰਜ ਕਰਦੇ ਹਨ। ਸਟਾਫ਼ Maya ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਵਿਸਥਾਰ ਵੇਖ ਸਕਦੇ ਹਨ, ਜਿਸ ਵਿੱਚ ਇਤਿਹਾਸ ਅਤੇ ਨੋਟਸ ਜੋੜਨ ਦੀ ਥਾਂ ਸ਼ਾਮਲ ਹੈ।
ਉਸੇ ਦਿਨ ਬਾਅਦ Maya ਇੱਕ ਆਈਟਮ ਵਾਪਸ ਕਰ ਦਿੰਦੀ ਹੈ ਜਿਸਦੀ ਕੀਮਤ $12.00 ਹੈ। ਸਟਾਫ਼ ਮੈਂਬਰ ਇੱਕ ਸਪਸ਼ਟ ਰੈਫਰੈਂਸ ਦੇ ਨਾਲ ਰਿਫੰਡ ਰਿਕਾਰਡ ਕਰਦਾ ਹੈ। ਜਦੋਂ ਕੋਈ ਪੁੱਛਦਾ ਹੈ ਕਿ ਬੈਲੈਂਸ ਕਿਉਂ ਬਦਲਿਆ, ਜਵਾਬ ਇਕ ਲਾਈਨ ਇਤਿਹਾਸ ਵਿੱਚ ਮਿਲ ਜਾਂਦਾ ਹੈ ਨਾਂ ਕਿ ਕਿਸੇ ਨੂੰ ਕਹਾਣੀ ਮੁੜ ਬਣਾਉਣੀ ਪਵੇ।
ਇੱਕ ਛੋਟਾ ਪਹਿਲਾ ਰਿਲੀਜ਼ ਚੁਣੋ ਜਿਸ 'ਤੇ ਤੁਸੀਂ ਭਰੋਸਾ ਕਰ ਸਕੋ। ਜ਼ਿਆਦਾਤਰ ਸਟੋਰਾਂ ਲਈ ਘੱਟੋ-ਘੱਟ ਇਹ ਚੀਜ਼ਾਂ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ: ਗਾਹਕ ਬੈਲੈਂਸ ਚੈੱਕਰ ਅਤੇ ਇੱਕ ਸਟਾਫ਼ ਟੂਲ ਜੋ ਕਾਰਨ ਅਤੇ ਇਤਿਹਾਸ ਲੈ ਕੇ ਬੈਲੈਂਸ ਸੋਧ ਸਕੇ।
ਇੱਕ ਪ੍ਰੈਕਟਿਕਲ v1 ਵਿੱਚ ਸ਼ਾਮਲ ਹੈ: ਕੋਡ ਰਾਹੀਂ ਗਾਹਕ ਲੁਕਅਪ, ਸਟਾਫ਼ ਸਾਈਨ-ਇਨ, ਲਾਜ਼ਮੀ ਕਾਰਨ ਨਾਲ ਸੋਧਾਂ, ਹਰ ਬਦਲਾਅ ਲਈ ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨ ਲੌਗ, ਅਤੇ ਬੁਨਿਆਦੀ ਸੀਮਾਵਾਂ (ਅਤੇ ਵੱਡੇ ਬਦਲਾਵ ਲਈ ਦੂਜੀ ਪੁਸ਼ਟੀ ਕਦਮ)।
ਵਿਸ਼ਾਲਤਾਂ ਜੋੜਨ ਤੋਂ ਪਹਿਲਾਂ, ਅਜਿਹੀਆਂ ਗੰਝਲਦਾਰ ਸਥਿਤੀਆਂ ਲਈ ਇੱਕ ਛੋਟੀ ਅੰਦਰੂਨੀ ਨੀਤੀ ਲਿਖੋ (ਜਿਵੇਂ ਰਿਫੰਡ ਅਤੇ ਵਿਵਾਦ) ਅਤੇ ਫਿਰ ਦੋ-ਤਿੰਨ ਅਸਲੀ ਉਦਾਹਰਨਾਂ ਨਾਲ ਸਟਾਫ਼ ਨੂੰ ਟ੍ਰੇਨ ਕਰੋ। ਲਾਂਚ ਤੋਂ ਬਾਅਦ, ਹਫ਼ਤੇਵਾਰ ਸਪੋਰਟ ਸੁਨੇਹਿਆਂ ਦੀ ਸਮੀਖਿਆ ਕਰੋ ਅਤੇ ਪਹਿਲਾਂ ਸਭ ਤੋਂ ਵੱਡੇ ਦਰਦ ਦੇ ਬਿੰਦੂ ਠੀਕ ਕਰੋ।
ਜੇ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ Koder.ai (koder.ai) ਵਰਤ ਰਹੇ ਹੋ ਆਪਣੇ ਅੰਦਰੂਨੀ ਟੂਲ ਬਣਾਉਣ ਲਈ, ਤਾਂ ਮੂਲ ਦਿਨ ਤੋਂ ਗਾਹਕ ਲੁਕਅਪ ਅਤੇ ਸਟਾਫ਼ ਸੋਧਾਂ ਨੂੰ ਵੱਖ-ਵੱਖ ਸਕ੍ਰੀਨ ਅਤੇ ਅਲੱਗ-ਅਲੱਗ ਪਰਮੀਸ਼ਨ ਨਾਲ ਰੱਖਣਾ ਪ੍ਰਾਜੈਕਟ ਨੂੰ ਵਧਾਉਣਾ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ।
ਫੋਕਸ ਇੱਕ ਹੀ ਕੰਮ 'ਤੇ ਰੱਖੋ: ਗਿਫਟ ਕਾਰਡ ਕੋਡ ਦਿਓ ਅਤੇ ਬਚੀ ਹੋਈ ਰਕਮ ਵੇਖੋ। ਨਤੀਜੇ ਨੂੰ ਭਰੋਸੇਯੋਗ ਬਣਾਉਣ ਲਈ ਸਟੋਰ ਦੀ ਮੁਦਰਾ ਵਿੱਚ ਬੈਲੈਂਸ ਅਤੇ ਇੱਕ ਸਪਸ਼ਟ “last updated” ਸਮਾਂ ਦਿਖਾਓ।
ਜੋ ਵੀ ਤੁਹਾਡੇ ਪ੍ਰੋਗਰਾਮ ਲਈ ਸੱਚਮੁੱਚ ਲਾਜ਼ਮੀ ਹੈ, ਉਹ ਮੰਗੋ ਅਤੇ ਇਹ ਸਪੱਸ਼ਟ ਕਰ ਦਿਓ। ਜੇ ਤੁਹਾਨੂੰ ਕਾਰਡ ਨੰਬਰ ਅਤੇ PIN ਦੋਹਾਂ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਦੋਨੋ ਫੀਲਡ ਤੁਰੰਤ ਦਿਖਾਓ ਤਾਂ ਜੋ ਲੋਕ ਸਮਾਂ ਵੇਰਬਾਦ ਨਾ ਕਰਨ।
ਸਧਾਰਨ ਅਤੇ ਪੇਸਟ-ਫਰੈਂਡਲੀ ਰੱਖੋ: ਇੱਕ ਲੇਬਲਡ ਇਨਪੁੱਟ, ਇੱਕ ਉਦਾਹਰਨ ਫਾਰਮੈਟ, ਅਤੇ ਇੱਕ “Check balance” ਬਟਨ। ਸਬਮਿਟ ਕਰਨ ਮਗਰੋਂ ਇੱਕ ਛੋਟੀ ਲੋਡਿੰਗ ਸਥਿਤੀ ਦਿਖਾਓ ਅਤੇ ਦੁਹਰਾਈ ਰੋਕਣ ਲਈ ਬਟਨ ਨਿਸ਼ਕ੍ਰਿਯ ਕਰੋ।
ਬੈਲੈਂਸ, ਮੁਦਰਾ, ਅਤੇ “last updated” ਟਾਈਮਸਟੈਂਪ ਦਿਖਾਉ। ਨਤੀਜੇ ਵਿੱਚ ਕੋਡ ਨੂੰ ਮਾਸਕ ਕਰੋ (ਉਦਾਹਰਣ ਲਈ, ਸਿਰਫ਼ ਆਖਰੀ 4 ਅੱਖਰ ਦਿਖਾਉ) ਤਾਂ ਜੋ ਸਕ੍ਰੀਨਸ਼ਾਟਸ ਅਤੇ ਘੁਟਣ-ਨਜ਼ਰ ਤੋਂ ਘੱਟ ਨੁਕਸਾਨ ਹੋਵੇ।
ਪਬਲਿਕ ਪੇਜ਼ 'ਤੇ ਇੱਕ ਜਨਰਿਕ ਸੁਨੇਹਾ ਵਰਤੋ, ਜਿਵੇਂ “We couldn’t verify that code. Please check and try again.” ਤਬੀਆਂ ਵਿਸਥਾਰ (expired, blocked ਆਦਿ) ਸਟਾਫ਼ ਟੂਲ ਲਈ ਰੱਖੋ ਜਦੋਂ ਕੋਈ ਗਾਹਕ ਵੈਰੀਫਾਈ ਹੋ ਜਾਏ।
ਇਸਨੂੰ ਇੱਕ ਏਰਰ ਵਜੋਂ ਨਹੀਂ ਦਿਖਾਓ। “$0.00 remaining” (last updated ਸਮੇਤ) ਦਿਖਾਓ ਤਾਂ ਕਿ ਗਾਹਕ ਸਮਝ ਸਕਣ ਕਿ ਕਾਰਡ ਵੈਧ ਹੈ ਪਰ ਖਤਮ ਹੋ ਚੁੱਕਿਆ ਹੈ।
ਇਸਨੂੰ ਕਸਟਮਰ ਪੇਜ਼ ਤੋਂ ਵੱਖ ਕਰੋ ਅਤੇ ਸਟਾਫ਼ ਸਾਈਨ-ਇਨ ਲਾਜ਼ਮੀ ਕਰੋ। ਜ਼ਿਆਦਾਤਰ ਸਟਾਫ਼ ਸਿਰਫ਼ ਵੇਖ ਸਕਦੇ ਹਨ, ਜਦ ਕਿ ਇੱਕ ਛੋਟੀ ਭਰੋਸੇਮੰਦ ਟੀਮ (ਮੈਨੇਜਰ ਆਦਿ) ਬੈਲੈਂਸ ਸੋਧ ਸਕਦੀ ਹੈ — ਹਰ ਬਦਲਾਵ ਆਡੀਟ ਟ੍ਰੇਲ ਵਿੱਚ ਰਿਕਾਰਡ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
ਜਦੋਂ ਸੰਭਵ ਹੋਵੇ, ਕਾਰਨ ਅਤੇ ਸਕ੍ਰੀਨਸ਼ਾਟ/ਰਸੀਦ ਜਿਵੇਂ ਇੱਕ ਰੀਫਰੈਂਸ ਲੋੜੀਦਾ ਕਰੋ, ਅਤੇ ਯਹ ਰਿਕਾਰਡ ਕਰੋ ਕਿ ਕੌਣ ਅਤੇ ਕਦੋਂ ਬਦਲਾਅ ਕੀਤਾ। ਸੋਧ ਤੋਂ ਪਹਿਲਾਂ “Current balance” ਅਤੇ “New balance” ਦਾ ਪ੍ਰੀਵਿਊ ਦਿਖਾਓ ਤਾਂ ਕਿ ਗਲਤੀ ਘੱਟ ਹੋਵੇ।
ਹਰ ਬਦਲਾਅ ਨੂੰ ਇੱਕ ਨਵਾਂ ਰਿਕਾਰਡ ਬਣਾਉਣਾ ਚਾਹੀਦਾ ਹੈ — ਸਿਰਫ਼ ਕਰੈਕਟ ਕਰਨ ਵਾਲੀ ਸੰਪਾਦਿਤ ਗਿਣਤੀ ਨਹੀਂ। ਜਾਰੀ ਕਰਨ, ਰੀਡੀਮਪਸ਼ਨ, ਰਿਫੰਡ ਅਤੇ ਮੈਨੂਅਲ ਸੋਧ ਹਰੇਕ ਇੱਕ ਨਵੀਂ ਐਂਟਰੀ ਬਣਾਏ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ ਤਾਂ ਜੋ ਬਾਅਦ ਵਿੱਚ ਸਮਝਾਈ ਜਾ ਸਕੇ।
ਰੇਟ ਲਿਮਿਟਸ ਅਤੇ ਕੁਝ ਫੇਲ ਹੋਣ ਦੇ ਬਾਅਦ ਥੋੜ੍ਹੀ ਕੂਲਡਾਊਨ ਰੱਖੋ ਤਾਂ ਕਿ ਬੋਟ ਬਹੁਤ ਸਾਰੀਆਂ ਕੋਸ਼ਿਸ਼ਾਂ ਨਾ ਕਰ ਸਕਣ। ਗਿਫਟ ਕਾਰਡ ਕੋਡ ਸੁਰੱਖਿਅਤ ਰੂਪ ਵਿੱਚ ਸੰਭਾਲੋ (ਉਦਾਹਰਨ ਲਈ, ਇੱਕ ਰੱਖਿਆ ਗਿਆ ਰੂਪ) ਅਤੇ ਵਰਤੋਂਕਾਰ ਨੂੰ ਪੂਰਾ ਕੋਡ ਵਾਪਸ ਨਾ ਦਿਖਾਓ।