15 ਅਗ 2025·8 ਮਿੰਟ
Jack Dorsey ਅਤੇ Block: ਭੁਗਤਾਨ ਨੂੰ ਛੋਟੇ ਕਾਰੋਬਾਰ ਦਾ OS ਬਣਾਉਣਾ
Square ਦੇ ਪਹਿਲੇ ਕਾਰਡ ਰੀਡਰ ਤੋਂ ਲੈਕੇ Block ਦੇ ਇਕੋਸਿਸਟਮ ਤੱਕ — ਜਾਣੋ ਕਿ ਕਿਵੇਂ ਭੁਗਤਾਨ, POS, ਬੈਂਕਿੰਗ-ਅੰਦਾਜ਼ ਦੇ ਟੂਲ ਅਤੇ ਐਪਸ ਇਕੱਠੇ ਹੋ ਕੇ ਛੋਟੇ ਕਾਰੋਬਾਰ ਚਲਾਉਂਦੇ ਹਨ।
Square ਦੇ ਪਹਿਲੇ ਕਾਰਡ ਰੀਡਰ ਤੋਂ ਲੈਕੇ Block ਦੇ ਇਕੋਸਿਸਟਮ ਤੱਕ — ਜਾਣੋ ਕਿ ਕਿਵੇਂ ਭੁਗਤਾਨ, POS, ਬੈਂਕਿੰਗ-ਅੰਦਾਜ਼ ਦੇ ਟੂਲ ਅਤੇ ਐਪਸ ਇਕੱਠੇ ਹੋ ਕੇ ਛੋਟੇ ਕਾਰੋਬਾਰ ਚਲਾਉਂਦੇ ਹਨ।
ਭੁਗਤਾਨ ਪਹਿਲਾਂ "ਉਹ ਕੰਮ ਜੋ ਅਖੀਰ ਵਿੱਚ ਹੁੰਦਾ ਹੈ" ਹੁੰਦੇ ਸਨ—ਅਸਲ ਕੰਮ ਮੋ ਦੀ ਬਾਅਦ ਇਕ ਕਾਰਡ ਸਵਾਈਪ। ਬਹੁਤ ਸਾਰੇ ਛੋਟੇ ਕਾਰੋਬਾਰਾਂ ਲਈ ਇਹ ਉਲਟ ਗਿਆ। ਚੈਕਆਉਟ ਹੁਣ ਓਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਕਾਰੋਬਾਰ ਨੂੰ ਮਾਪਿਆ, ਸਾਂਭਿਆ ਅਤੇ (ਵਧਦਿਆਂ) ਫਾਇਨੈਂਸ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।
"ਭੁਗਤਾਨ ਢਾਂਚਾ" ਉਹ ਸੰਦ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਗਾਹਕਾਂ ਤੋਂ ਪੈਸੇ ਲੈਣ ਅਤੇ ਆਪਣੇ ਖਾਤੇ ਵਿਚ ਪਹੁੰਚਾਉਣ ਦੀ ਆਸਾਨੀ ਦਿੰਦਾ ਹੈ। ਇਸ ਵਿੱਚ ਕਾਰਡ ਰੀਡਰ ਜਾਂ ਆਨਲਾਈਨ ਚੈਕਆਉਟ, ਲੈਣ-ਦੇਣ ਦੀ ਮਨਜ਼ੂਰੀ ਕਰਨ ਵਾਲਾ ਸਾਫਟਵੇਅਰ, ਵਿਕਰੀ ਬਾਰੇ ਰਿਪੋਰਟਿੰਗ ਅਤੇ ਫੰਡਸ ਨੂੰ ਬੈਂਕ ਤੱਕ ਭੇਜਣ ਦੀ ਪ੍ਰਕਿਰਿਆ ਸ਼ਾਮਲ ਹੈ।
ਇਹ ਸਿਮਿੱਟ ਲੱਗਦਾ ਹੈ, ਪਰ ਇਹ ਲਗਭਗ ਹਰ ਉਸ ਚੀਜ਼ ਨਾਲ ਜੁੜਿਆ ਹੈ ਜੋ ਛੋਟੇ ਕਾਰੋਬਾਰ ਨੂੰ ਚਲਾਉਂਦੀ ਹੈ।
ਹਰ ਵਿਕਰੀ ਇਕ ਆਪਰੇਸ਼ਨਲ ਡੇਟਾ ਟਰੇਲ ਬਣਾਉਂਦੀ ਹੈ। ਜਦੋਂ ਫਿਰ ਭੁਗਤਾਨ ਸਿਸਟਮ ਇਸਨੂੰ ਕੈਪਚਰ ਕਰ ਲੈਂਦਾ ਹੈ, ਤਾਂ ਉਹ ਆਟੋਮੈਟਿਕ ਤੌਰ 'ਤੇ ਬਾਕੀ ਕਾਰੋਬਾਰ ਨੂੰ ਅਪਡੇਟ ਕਰ ਸਕਦਾ ਹੈ:
ਭੁਗਤਾਨ ਮਹੀਨੇ ਵਿੱਚ ਸੈਂਕੜੇ ਜਾਂ ਹਜ਼ਾਰਾਂ ਵਾਰ ਹੁੰਦੇ ਹਨ, ਇਸਲਈ ਇਹ ਕਾਰੋਬਾਰ ਬਾਰੇ ਤਾਜ਼ਾ ਅਤੇ ਭਰੋਸੇਯੋਗ ਸਿਗਨਲ ਪੈਦਾ ਕਰਦੇ ਹਨ।
ਜਦੋਂ ਕੋਈ ਪ੍ਰਦਾਤਾ ਲੈਣ-ਦੇਣ ਪ੍ਰੋਸੈਸ ਕਰਦਾ ਹੈ ਅਤੇ ਇਕੱਠੇ ਆਈਟਮ, ਕਰਮਚਾਰੀ ਅਤੇ ਪੇਆਉਟ ਦਿਖਾਉਂਦਾ ਹੈ, ਤਾਂ ਉਹ "ਸਰੋਤ-ਅਸਲ" ਵਰਗਾ ਦਿਸਦਾ ਹੈ। ਵਪਾਰੀ ਲੌਗਿਨ ਕਰਦੇ ਹਨ ਤਾਂ ਕਿ ਵਿਕਰੀ ਪੂਰਨ ਕਰ ਸਕਣ, ਦਿਨ ਬੰਦ ਕਰ ਸਕਣ, ਰਿਫੰਡ ਹੈਂਡਲ ਕਰ ਸਕਣ ਅਤੇ ਪੁੱਛ ਸਕਣ "ਕੀ ਅਸੀਂ ਇਸ ਹਫ਼ਤੇ ਨਫ਼ਾ ਕੀਤਾ?"
ਇਸ ਲੇਖ ਦਾ ਮੁੱਖ ਵਿਚਾਰ ਇਹ ਹੈ: Square (ਹੁਣ Block ਦੇ ਅਧੀਨ) ਵਰਗੀਆਂ ਕੰਪਨੀਆਂ ਸਿਰਫ਼ ਕਾਰਡ ਲੈਣਾ ਆਸਾਨ ਨਹੀਂ ਬਣਾਇਆ। ਉਨ੍ਹਾਂ ਨੇ ਭੁਗਤਾਨ ਨੂੰ ਓਪਰੇਸ਼ਨ ਦੇ ਕੇਂਦਰ ਵਜੋਂ ਪੋਜ਼ੀਸ਼ਨ ਕੀਤਾ—ਇੱਕ ਐਸਾ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਜਿਸ 'ਤੇ ਛੋਟੇ ਕਾਰੋਬਾਰ ਚਲਦੇ ਹਨ, ਸਿਰਫ਼ ਚੈਕਆਉਟ ਟੂਲ ਨਹੀਂ।
Square ਇਕ ਸਧਾਰਣ, ਜ਼ਰੂਰੀ ਸਮੱਸਿਆ ਨਾਲ ਸ਼ੁਰੂ ਹੋਇਆ: ਬਹੁਤ ਸਾਰੇ ਛੋਟੇ ਕਾਰੋਬਾਰ ਕਾਰਡ ਭੁਗਤਾਨ ਨਹੀਂ ਲੈ ਸਕਦੇ ਸੀ ਬਿਨਾਂ ਕਾਗਜ਼ੀ ਕਾਰਵਾਈ, ਵਿਸ਼ੇਸ਼ਤ ਹਾਰਡਵੇਅਰ ਅਤੇ ਲੰਬੇ ਇੰਤਜ਼ਾਰ ਦੇ। ਮੁਢਲੀ ਵਾਅਦਾ ਸਿੱਧਾ ਸੀ—ਇਕ ਛੋਟਾ ਰੀਡਰ ਪਲੱਗ ਕਰੋ, ਕਾਰਡ ਸਵੀਕਾਰ ਕਰੋ, ਅਤੇ ਪੈਸਾ ਮਿੱਟੋ। ਇਹ "ਆਸਾਨ ਬਣਾਓ" ਸੋਚ ਨੇ ਵਿਕਰੇਤਿਆਂ ਦਾ ਭਰੋਸਾ ਜਿੱਤਿਆ, ਜੋ ਸਿਰਫ਼ ਇਕ ਭਰੋਸੇਯੋਗ ਚੈਕਆਉਟ ਚਾਹੁੰਦੇ ਸਨ।
ਜਿਵੇਂ ਜਿਵੇਂ Square ਵਧਿਆ, ਉਹ ਵਿਕਰੇਤਿਆਂ ਦੇ ਭੁਗਤਾਨ ਮੋਹਰੇ ਦੇ ਬਾਹਰ ਵੀ ਗਿਆ। ਜਦੋਂ ਤੁਸੀਂ ਲੈਣ-ਦੇਣ ਪ੍ਰੋਸੈਸ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਦੇਖਦੇ ਹੋ ਕਿ ਕੀ ਵਿਕ ਰਿਹਾ, ਕਦੋਂ ਸਟਾਫ਼ ਸਭ ਤੋਂ ਬਿਹੱਤਰੀਨ ਹੈ, ਦੁਹਰਾਉ ਗਾਹਕ ਕਿਵੇਂ ਵਰਤਦੇ ਹਨ, ਅਤੇ ਕਿੱਥੇ ਨਕਦੀ ਕੰਝੜ ਹੋ ਰਹੀ ਹੈ। ਇਹ ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਕੰਪਨੀ ਨੂੰ ਨੇੜਲੇ ਟੂਲਾਂ ਵੱਲ ਖਿੱਚ ਲਿਆਉਂਦਾ—POS ਸਾਫਟਵੇਅਰ, ਇਨਵੌਇਸ, ਆਨਲਾਈਨ ਭੁਗਤਾਨ ਅਤੇ ਕਾਰੋਬਾਰੀ ਪੈਸਾ ਪ੍ਰਬੰਧਨ।
ਜਾਂ-ਜਾਂ ਸਮਾਂ ਬੀਤਿਆ, ਕੰਪਨੀ ਦੀ ਪਛਾਣ "ਕਾਰਡ ਰੀਡਰ ਕੰਪਨੀ" ਤੋਂ ਵੱਧ ਹੋ ਗਈ। Jack Dorsey ਦੀ ਅਗਵਾਈ ਹੇਠ, ਵੱਡੀ ਰੂਹਵਾਨੀ ਬਣੀ: ਬਹੁਤ ਸਾਰੇ ਉਤਪਾਦ ਜੋ ਦੋਹਾਂ ਪਾਸਿਆਂ ਦੀ ਸੇਵਾ ਕਰਦੇ—ਮਰਚੈਂਟ ਜੋ ਕਾਰੋਬਾਰ ਚਲਾਉਂਦੇ ਅਤੇ ਉਪਭੋਗਤਾ ਜੋ ਪੈਸਾ ਖਰਚ ਜਾਂ ਭੇਜਦੇ ਹਨ। Block ਵੱਲ ਨਾਂ ਬਦਲਣਾ ਇਸ ਬਦਲਾਅ ਦਾ ਸੰਕੇਤ ਸੀ: Square ਨੂੰ ਛੱਡਣਾ ਨਹੀਂ, ਪਰ ਕੰਪਨੀ ਨੂੰ ਇੱਕ ਵੱਡੇ ਢਾਂਚੇ ਦੇ ਅਧੀਨ ਸੁਚੱਜਾ ਕਰਨਾ।
ਇਕੋਸਿਸਟਮ ਸਿਰਫ਼ "ਵੱਧ ਫੀਚਰ" ਨਹੀਂ ਹੈ। ਇਹ ਉਹ ਉਤਪਾਦ ਹਨ ਜੋ ਸਾਂਝੇ:
ਨਤੀਜਾ ਇਕ ਪਲੇਟਫਾਰਮ ਹੈ ਜੋ ਇਕ ਇਕੱਲੇ ਟੂਲ ਨਾਲੋਂ ਵੱਧ "ਓਪਰੇਟਿੰਗ ਲੇਅਰ" ਜਿਹਾ ਮਹਿਸੂਸ ਹੋ ਸਕਦਾ ਹੈ—ਜਿੱਥੇ ਭੁਗਤਾਨ ਸ਼ੁਰੂਆਤ ਹੁੰਦੇ ਹਨ ਅਤੇ ਹੋਰ ਸਭ ਕੁਝ ਉਸ ਕੋਰ ਨਾਲ ਵਾਪਸ ਜੁੜਦਾ ਹੈ।
ਭੁਗਤਾਨ ਪਹਿਲਾ ਕੰਮ ਹੈ ਜੋ ਸਹੀ ਹੋਣਾ ਚਾਹੀਦਾ—ਕਿਉਂਕਿ ਹੋਰ ਸਭ ਇਸ ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ। ਛੋਟੇ ਕਾਰੋਬਾਰ ਲਈ, "ਭੁਗਤਾਨ ਸਵੀਕਾਰ ਕਰਨਾ"ਦਾ ਮਤਲਬ ਹੈ ਗਾਹਕਾਂ ਨੂੰ ਹਰ ਥਾਂ ਤੋਂ ਪੈਸਾ ਲੈ ਸਕਣਾ: ਕਾਊਂਟਰ 'ਤੇ, ਪੌਪ-ਅੱਪ ਤੇ, ਫੋਨ 'ਤੇ ਜਾਂ ਵੈਬਸਾਈਟ 'ਤੇ।
ਕਾਰਡ-ਮੁਖੀ ਭੁਗਤਾਨ ਸਾਮ੍ਹਣੇ-ਸਾਮ੍ਹਣੇ ਹੁੰਦੇ ਹਨ: ਟੈਪ, ਡਿਪ, ਸਵਾਈਪ। ਇਹ ਤੇਜ਼, ਬਾਰੰਬਾਰ ਅਤੇ ਰੋਜ਼ਾਨਾ ਭੀੜ ਨਾਲ ਜੁੜੇ ਹੁੰਦੇ ਹਨ। ਆਨਲਾਈਨ ਭੁਗਤਾਨ ਇਨਵੌਇਸ, ਪਿਕਅਪ ਆਰਡਰ, ਡਿਲਿਵਰੀ, ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਅਤੇ ਸੋਸ਼ਲ 'ਤੇ ਸਾਂਝੇ ਕੀਤੇ ਲਿੰਕਾਂ ਨੂੰ ਕਵਰ ਕਰਦੇ ਹਨ। ਇੱਕ ਫਰੰਟਸਟਰੋਅਟ ਜੋ "ਆਫਲਾਈਨ" ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ ਵੀ ਆਮ ਤੌਰ 'ਤੇ ਜਮ੍ਹਾਂ, ਗਿਫਟ ਕਾਰਡ ਜਾਂ ਆਖ਼ਰੀ-ਮਿੰਟ ਆਰਡਰ ਲਈ ਆਨਲਾਈਨ ਟੂਲ ਚਾਹੀਦੇ ਹੋ ਸਕਦੇ ਹਨ।
ਜਦੋਂ ਇਕ ਪਰਦਾਤਾ ਦੋਹਾਂ ਨੂੰ ਸਪੋਰਟ ਕਰਦਾ ਹੈ, ਤਾਂ ਵਪਾਰੀ ਵੱਖਰੇ ਰਿਪੋਰਟ, ਵੱਖਰੀਆਂ ਫੀਸਾਂ ਅਤੇ ਵੱਖਰੇ ਗਾਹਕ ਰਿਕਾਰਡ ਹਟਾ ਦਿੰਦੇ ਹਨ। ਮਕਸਦ ਸਿਰਫ਼ ਸੁਵਿਧਾ ਨਹੀਂ—ਇਹ ਇਕਸਾਰਤਾ ਹੈ।
ਜ਼ਿਆਦਾਤਰ ਮਾਲਕ "ਭੁਗਤਾਨ ਢਾਂਚਾ" ਖਰੀਦ ਨਹੀਂ ਰਹੇ। ਉਹ ਖਰੀਦ ਰਹੇ ਹਨ:
ਜੇ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਫੇਲ ਹੋ ਜਾਵੇ, ਤਾਂ ਦਰਦ ਤੁਰੰਤ ਹੈ: ਗੁੰਮ ਹੋਈ ਵਿਕਰੀ, ਲੰਬੀਆਂ ਲਾਈਨਾਂ, ਗੁੰਝਲ ਰਹੇ ਪੇਆਉਟ ਅਤੇ ਰਾਤ ਨੂੰ ਸਪ੍ਰੈਡਸ਼ੀਟ ਸਾਫ ਕਰਨ ਦੀ ਥਕਾਵਟ।
ਹਰ ਭੁਗਤਾਨ ਇੱਕ ਸਾਫ਼, ਟਾਈਮਸਟੈਂਪ ਵਾਲਾ ਰਿਕਾਰਡ ਬਣਾਉਂਦਾ ਹੈ: ਕੀ ਵਿਕਿਆ, ਕਿਵੇਂ ਭੁਗਤਾਨ ਹੋਇਆ, ਕੌਣ ਨੇ ਪ੍ਰੋਸੈਸ ਕੀਤਾ, ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ ਕੌਣ ਖਰੀਦਿਆ। ਉਹ ਲੈਣ-ਦੇਣ ਡੇਟਾ ਉਹਨਾਂ ਫੀਚਰਾਂ ਲਈ ਆਧਾਰ ਬਣ ਜਾਂਦਾ ਹੈ ਜੋ "ਭੁਗਤਾਨ ਤੋਂ ਅੱਗੇ" ਮਹਿਸੂਸ ਹੁੰਦੇ ਹਨ—ਜਿਵੇਂ ਇਨਵੈਂਟਰੀ ਗਿਣਤੀ, ਸਟਾਫ਼ ਅਧਿਕਾਰ, ਟੈਕਸ ਟ੍ਰੈਕਿੰਗ, ਗਾਹਕ ਪ੍ਰੋਫਾਈਲ ਅਤੇ ਆਟੋਮੈਟਿਕ ਰਸੀਦਾਂ।
ਜਿਵੇਂ ਹੀ ਭੁਗਤਾਨ ਕੇਂਦਰੀਕ੍ਰਿਤ ਹੋ ਜਾਂਦੇ ਹਨ, ਇਕ ਇਕੱਠਾ ਡੈਸ਼ਬੋਰਡ ਉਸ ਜਗ੍ਹਾ ਬਣ ਸਕਦਾ ਹੈ ਜਿੱਥੇ ਵਪਾਰੀ ਦਿਨ ਚਲਾਉਂਦੇ ਹਨ: ਵਿਕਰੀ ਪ੍ਰਦਰਸ਼ਨ, ਰਿਫੰਡ, ਚਾਰਜਬੈਕ, ਆਨਲਾਈਨ ਆਰਡਰ, ਅਤੇ ਪੇਆਉਟ ਸਥਿਤੀ—ਬਿਨਾਂ ਕਈ ਟੂਲ ਜੋੜਨ ਦੇ। ਭੁਗਤਾਨ ਸਿਰਫ਼ ਵਿਕਰੀ ਦੀ ਅਖੀਰਲੀ ਕੜੀ ਨਹੀਂ ਰਹਿੰਦੇ; ਉਹ ਕਾਰੋਬਾਰ ਲਈ ਸਿਸਟਮ ਆਫ ਰਿਕਾਰਡ ਬਣ ਜਾਂਦੇ ਹਨ।
ਭੁਗਤਾਨ ਸਾਫਟਵੇਅਰ ਬਹੁਤ ਵਧੀਆ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਕਈ ਛੋਟੇ ਕਾਰੋਬਾਰ ਉਹੀ ਆਪਣਾਉਂਦੇ ਹਨ ਜੋ ਦਿਨ-ਇੱਕਤੇ ਸੈਟਅਪ ਲਈ ਸਭ ਤੋਂ ਆਸਾਨ ਹੈ। ਇਸੀ ਲਈ Square ਦਾ ਹਾਰਡਵੇਅਰ ਮਹੱਤਵਪੂਰਨ ਸੀ: ਇਸ ਨੇ ਇੱਕ ਔਖਾ "ਮਰਚੈਂਟ ਸਰਵਿਸਿਜ" ਫੈਸਲਾ ਇੱਕ ਭੌਤਿਕ ਚੀਜ਼ ਵਿੱਚ ਬਦਲ ਦਿੱਤਾ ਜੋ ਤੁਸੀਂ ਪਲੱਗ ਕਰਕੇ ਚਾਲੂ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਤੁਰੰਤ ਭੁਗਤਾਨ ਵਸੂਲ ਸਕਦੇ ਹੋ।
ਇਕ ਮਾਲਕ-ਓਪਰੇਟਰ ਲਈ, ਘੱਟ ਚਲਣ ਵਾਲੀਆਂ ਚੀਜ਼ਾਂ ਦਾ ਮਤਲਬ ਘੱਟ ਫਸ ਜਾਣ ਦੇ ਮੌਕੇ ਹਨ। ਆਊਟ-ਆਫ-ਦ-ਬਾਕਸ ਕੰਮ ਕਰਨ ਵਾਲਾ ਇੱਕ ਕਾਰਡ ਰੀਡਰ ਜਾਂ ਟਰਮੀਨਲ ਪ੍ਰੋਸੈਸਰ, ਗੇਟਵੇਜ਼ ਜਾਂ ਡਿਵਾਈਸਾਂ ਦੇ ਸੰਕਲਨ ਬਾਰੇ ਗੋਚਰ ਕਰਨ ਦੀ ਲੋੜ ਘਟਾਉਂਦਾ ਹੈ। ਖਰੀਦ ਫੈਸਲੇ ਨੂੰ ਵੀ ਇਕ ਵਾਜਬੀ ਚੀਜ ਬਣਾਉਂਦਾ ਹੈ: ਤੁਸੀਂ ਇੱਕ ਚੈਕਆਉਟ ਸੈਟਅਪ ਖਰੀਦ ਰਹੇ ਹੋ, ਇਕ ਅਬਸਟਰੈਕਟ ਕਾਨਟ੍ਰੈਕਟ ਨਹੀਂ।
ਜ਼ਿਆਦਾਤਰ ਛੋਟੇ ਕਾਰੋਬਾਰ ਕੁਝ ਹਾਰਡਵੇਅਰ ਕਿਸਮਾਂ ਦਾ ਮਿਕਸ ਵਰਤਦੇ ਹਨ, ਇਹ ਇਸ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਕਿ ਉਹ ਕਿੱਥੇ ਵੇਚਦੇ ਹਨ:
ਨਿਰਣਾ ਜ਼ਿਆਦਾ ਮਾਡਲ ਤੋਂ ਘੱਟ ਹੈ—ਮੁੱਦਾ ਨਤੀਜਾ ਹੈ: ਗਾਹਕ ਤੇਜ਼ੀ ਨਾਲ ਭੁਗਤਾਨ ਕਰਦੇ ਹਨ ਅਤੇ ਸਟਾਫ਼ ਬਿਨਾਂ ਝੰਜਟ ਦੇ ਵਿਕਰੀ ਪੂਰੀ ਕਰ ਲੈਂਦੇ ਹਨ।
ਜਦੋਂ ਹਾਰਡਵੇਅਰ ਅਤੇ ਸਕ੍ਰੀਨ 'ਤੇ ਫਲੋ ਹਰ ਸਥਾਨ ਤੇ ਇਕਸਾਰ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਟ੍ਰੇਨਿੰਗ ਦੁਹਰਾਉਯੋਗ ਬਣ ਜਾਂਦੀ ਹੈ। ਨਵੇਂ ਕਰਮਚਾਰੀ ਇਕ ਹੀ ਕਦਮ ਸਿੱਖਦੇ ਹਨ—ਸਕੈਨ, ਛੂਟ, ਰਿਫੰਡ ਅਤੇ ਟਿੱਪਸ—ਫਿਰ ਉਹ ਨੂੰ ਹਰ ਥਾਂ ਲਾਗੂ ਕਰਦੇ ਹਨ। ਇਸ ਨਾਲ ਗਲਤੀਆਂ ਘਟਦੀਆਂ ਹਨ ਅਤੇ "ਸਿਰਫ਼ ਇਕ ਵਿਅਕਤੀ ਚੈਕਆਉਟ ਚਲਾਉਣਾ ਜਾਣਦਾ ਹੈ" ਦੀ ਸਮੱਸਿਆ ਘਟਦੀ ਹੈ।
ਕੋਈ ਵੀ ਸਿਸਟਮ 100% ਉਥੇ ਨਹੀਂ ਰਹਿੰਦਾ। ਕਮੇਟਮੈਂਟ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਵਪਾਰੀ ਬਚਨ ਕਰਕੇ ਪੁੱਛਣ:
ਵਧੀਆ ਚੈਕਆਉਟ ਹਾਰਡਵੇਅਰ ਸਿਰਫ਼ ਸਲਮੇਟ ਨਹੀਂ—ਇਕ ਵੰਡ ਚੈਨਲ ਹੈ ਜੋ ਪੂਰੇ ਭੁਗਤਾਨ ਸਟੈਕ ਨੂੰ ਸਧਾਰਣ ਅਤੇ ਭਰੋਸੇਯੋਗ ਮਹਿਸੂਸ ਕਰਾਉਂਦਾ ਹੈ।
ਜੇ ਭੁਗਤਾਨ "ਸੱਚਾਈ ਦਾ ਪਲ" ਹੈ, ਤਾਂ POS ਸਾਫਟਵੇਅਰ ਉਸ ਪਲ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਦੀ ਸਾਰੀ ਵਸਤੂ ਹੈ। ਬਹੁਤ ਸਾਰੇ ਛੋਟੇ ਕਾਰੋਬਾਰਾਂ ਲਈ, ਇਹ ਰੋਜ਼ਾਨਾ ਕਾਰਜ-ਥਾਂ ਬਣ ਜਾਂਦਾ ਹੈ: ਜਿੱਥੇ ਉਤਪਾਦ ਪਰਿਭਾਸ਼ਤ ਹੁੰਦੇ ਹਨ, ਆਰਡਰ ਬਣਦੇ ਹਨ, ਕਰਮਚਾਰੀ ਮੈਨੇਜ ਕੀਤੇ ਜਾਂਦੇ ਹਨ ਅਤੇ ਗਾਹਕ ਰਿਸ਼ਤੇ ਸਮੇਂ ਨਾਲ ਇਕਠੇ ਹੁੰਦੇ ਹਨ।
POS ਇੱਕ ਉਤਪਾਦ ਕੈਟਾਲੌਗ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ—ਆਈਟਮ, ਮੋਡੀਫਾਇਰ ਅਤੇ ਉਹ ਨਿਯਮ ਜੋ ਲੈਣ-ਦੇਣ ਨੂੰ ਰੂਪ ਦਿੰਦੇ ਹਨ। ਇਸ ਵਿੱਚ ਕੀਮਤਾਂ, ਟੈਕਸ, ਛੂਟ ਅਤੇ ਇਹ ਚੋਣਾਂ ਰਸੀਦ 'ਤੇ ਕਿਵੇਂ ਦਰਸਾਈਆਂ ਜਾ ਰਹੀਆਂ ਹਨ, ਸ਼ਾਮਿਲ ਹੁੰਦਾ ਹੈ।
ਠੀਕ ਢੰਗ ਨਾਲ ਸੈਟਅਪ ਹੋਣ 'ਤੇ, ਚੈਕਆਉਟ ਚੈਨਲਾਂ ਵਿੱਚ ਇਕਸਾਰ ਰਹਿੰਦਾ ਹੈ: ਉਹੀ ਲੈਟੇ ਆਡ-ਆਨ, ਉਹੀ ਹੈਪੀ-ਆਵਰ ਛੂਟ, ਉਹੀ ਰਿਫੰਡ ਨੀਤੀ—ਕਾਊਂਟਰ ਤੇ, ਕਰਬਸਾਈਡ ਤੇ ਜਾਂ ਇਨਵੌਇਸ ਰਾਹੀਂ ਵਿਕਰੀ ਹੋਵੇ। ਰਸੀਦਾਂ ਸਿਰਫ਼ ਖਰੀਦ ਦਾ ਪ੍ਰਮਾਣ ਨਹੀਂ; ਉਹ ਇਕ ਨਰਮ ਸੰਚਾਰ ਸੰਦ ਵੀ ਹੋ ਸਕਦੀਆਂ ਹਨ (ਸਟੋਰ ਜਾਣਕਾਰੀ, ਵਾਪਸੀ ਨਿਰਦੇਸ਼ ਅਤੇ ਕਈ ਵਾਰ ਵਾਪਸ ਆਉਣ ਦੀ ਦਾਅਤ)।
POS ਵਿੱਚ ਇਨਵੈਂਟਰੀ ਫੀਚਰ ਅਕਸਰ "ਮੁੱਤਲੀ ਉਦੇਸ਼" ਲਈ ਸਧਾਰਨ ਹੁੰਦੇ ਹਨ, ਪਰ ਉਹ ਆਮ ਸਿਰਦਰਦੀ ਮੁੱਦਿਆਂ ਨੂੰ ਹੱਲ ਕਰਦੇ ਹਨ:
ਇਨ ਬੁਨਿਆਦੀ ਦਿੱਖ ਵੀ ਮਾਲਕਾਂ ਨੂੰ ਘਟਨੇ ਅਨੁਮਾਨ ਨਾਲ ਦੁਬਾਰਾ ਆਰਡਰ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦੀ ਹੈ ਅਤੇ ਪਛਾਣ ਦਿੰਦੀ ਹੈ ਕਿ ਕਿਹੜੇ ਆਈਟਮ ਆਮਦਨ ਚਲਾਉਂਦੇ ਹਨ।
POS ਸਾਫਟਵੇਅਰ ਅੱਗੇ ਲਾਈਨ ਐਡਮਿਨ ਪੈਨਲ ਵਾਂਗ ਕੰਮ ਕਰਦਾ ਹੈ। ਸੰਕਲਪਕ ਤੌਰ 'ਤੇ, ਇਹ ਭੂਮਿਕਾਵਾਂ ਅਤੇ ਪਰਮੀਸ਼ਨਾਂ ਦੀ ਪਰਿਭਾਸ਼ਾ (ਕੌਣ ਆਈਟਮ ਗਿਫਟ ਕਰ ਸਕਦਾ, ਰਿਫੰਡ ਜਾਰੀ ਕਰ ਸਕਦਾ, ਜਾਂ ਕੀਮਤ ਸੋਧ ਸਕਦਾ), ਟਿੱਪਸ ਟ੍ਰੈਕਿੰਗ ਅਤੇ ਕੰਮ ਸਮਾਂ ਕੈਪਚਰ ਕਰਨ ਬਾਰੇ ਹੁੰਦਾ ਹੈ। ਇਹ ਵਿਵਰਣ ਮਾਰਜਿਨ ਦੀ ਰੱਖਿਆ ਕਰਦੇ ਹਨ ਅਤੇ ਰਾਤ ਦੇ ਅੰਤ ਦੇ ਵਿਵਾਦ ਘਟਾਉਂਦੇ ਹਨ ਬਿਨਾਂ ਪ੍ਰਬੰਧਨ ਨੂੰ ਕਾਗਜ਼ੀ ਕੰਮ ਵਿੱਚ ਬਦਲਣ ਦੇ।
POS ਸਿਸਟਮ ਖਰੀਦਾਂ ਨੂੰ ਲੋਕਾਂ ਨਾਲ ਜੋੜਦੇ ਹਨ—ਡੀਜੀਟਲ ਰਸੀਦਾਂ, ਲੋਯਲਟੀ ਪ੍ਰੋਗਰਾਮ ਅਤੇ ਖਰੀਦ ਇਤਿਹਾਸ ਰਾਹੀਂ। ਸਮੇਂ ਨਾਲ, ਇਹ ਦੁਹਰਾਉ-ਖਰੀਦ ਸਿਗਨਲ ਬਣਾਉਂਦਾ ਹੈ: ਕੌਣ ਮੁੜ ਆ ਰਿਹਾ ਹੈ, ਉਹ ਕੀ ਖਰੀਦਦਾ ਹੈ, ਅਤੇ ਕਦੋਂ ਉਹ ਆਨਾ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ। ਇਹ ਜਾਣਕਾਰੀ ਆਮ "ਮਾਰਕੇਟਿੰਗ" ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਕਾਰਗਰ ਹੁੰਦੀ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਚੈੱਕਆਉਟ 'ਤੇ ਵਾਸਤਵਿਕ ਕਰਮ 'ਤੇ ਅਧਾਰਤ ਹੁੰਦੀ ਹੈ।
ਕਈ ਛੋਟੇ ਕਾਰੋਬਾਰਾਂ ਲਈ, "ਪੈਸਾ ਮਿਲਣਾ" ਆਮ ਤੌਰ 'ਤੇ ਕਾਰਡ ਮਨਜ਼ੂਰ ਹੋਣ ਤੇ ਖਤਮ ਨਹੀਂ ਹੁੰਦਾ। ਅਹਿਮ ਗੱਲ ਇਹ ਹੈ ਕਿ ਪੈਸਾ ਕਦੋਂ ਬੈਂਕ ਵਿੱਚ ਆਉਂਦਾ ਹੈ—ਅਤੇ ਉਹ ਸਮਾਂ ਕਿੰਨਾ ਪੇਸ਼ਗੀਯੋਗ ਹੈ।
ਅਗਲੇ-ਦਿਨ ਡਿਪਾਜ਼ਿਟ ਦਿਨ-ਬਦਿਨ ਫੈਸਲੇ बदਲ ਸਕਦਾ ਹੈ: ਪੇਰੋਲ ਨੂੰ ਕਵਰ ਕਰਨਾ, ਇਨਵੈਂਟਰੀ ਦੁਬਾਰਾ ਆਰਡਰ ਕਰਨਾ, ਜਾਂ ਇਕ ਠੇਕੇਦਾਰ ਨੂੰ ਭੁਗਤਾਨ ਕਰਨਾ ਬਿਨਾਂ ਨਿੱਜੀ ਬਚਤਾਂ ਨੂੰ ਝਟਕਣ ਦੇ। ਤੇਜ਼ੀ ਦੇ ਨਾਲ-ਨਾਲ ਲਗਾਤਾਰਤਾ ਵੀ ਬਹੁਤ ਜ਼ਰੂਰੀ ਹੈ। ਜੇ ਡਿਪਾਜ਼ਿਟ ਉਸ ਸਮੇਂ ਨਹੀਂ ਪੁੱਜਦੇ ਜਦੋਂ ਤੁਸੀਂ ਉਮੀਦ ਕਰਦੇ ਹੋ, ਤਾਂ ਕਿਰਾਏ, ਟੈਕਸ ਅਤੇ ਸਪਲਾਇਰ ਟਰਮਾਂ ਦੀ ਯੋਜਨਾ ਬਦਲ ਜਾਂਦੀ ਹੈ।
ਕੁਝ ਪ੍ਰਦਾਤਾ ਡਿਪਾਜ਼ਿਟ ਤੇਜ਼ ਕਰਨ ਦੇ ਵਿਕਲਪ ਪੇਸ਼ ਕਰਦੇ ਹਨ (ਅਕਸਰ ਫੀਸ ਲਈ) ਜਾਂ ਪੇਆਉਟ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਸ਼ਡਿਊਲ ਕਰਨ ਦੀ ਆਸਾਨੀ ਦਿੰਦੇ ਹਨ ਜੋ ਤੁਹਾਡੇ ਕਾਰੋਬਾਰ ਨਾਲ ਮੇਲ ਖਾਂਦੀ ਹੋਵੇ। ਮੁੱਖ ਸਵਾਲ ਇਹ ਨਹੀਂ ਕਿ "ਸਭ ਤੋਂ ਤੇਜ਼ ਪੇਆਉਟ ਕਿਹੜਾ ਹੈ?"—ਬਲਕਿ "ਮੇਰਾ ਆਮ ਪੇਆਉਟ ਸਮਾਂ ਕੀ ਹੋਵੇਗਾ ਅਤੇ ਇਸ ਦੀ ਲਾਗਤ ਕੀ ਹੈ?"
Block ਦੇ ਛੋਟੇ-ਕਾਰੋਬਾਰ ਪ੍ਰਸਤਾਵਾਂ ਵਿੱਚ ਵਧਦੇ ਹੋਏ ਬੈਂਕਿੰਗ-ਸਟਾਈਲ ਫੀਚਰ ਸ਼ਾਮਿਲ ਹੋਏ ਹਨ ਜਿਵੇਂ ਕਾਰੋਬਾਰੀ ਖਾਤੇ, ਡੈਬਿਟ ਕਾਰਡ ਅਤੇ ਵਿਕਰੀ, ਖ਼ਰਚੇ ਅਤੇ ਬਚਤ ਬਕਿਟਾਂ ਵਿਚ ਪੈਸਾ ਹਿਲਾਉਣ ਦੇ ਟੂਲ। ਉਪਲਬਧਤਾ ਖੇਤਰ ਅਤੇ ਯੋਗਤਾ 'ਤੇ ਨਿਰਭਰ ਕਰ ਸਕਦੀ ਹੈ, ਇਸ ਲਈ ਵਪਾਰੀ ਇਨ੍ਹਾਂ ਨੂੰ ਵਿਕਲਪਕ ਪਹਿਰੇ ਵਜੋਂ ਦੇਖਣ।
ਜਦੋਂ ਇਹ ਉਪਲਬਧ ਹੁੰਦੇ ਹਨ, ਤਾਂ ਉਹ ਸਿਸਟਮਾਂ ਦਰਮਿਆਨ ਕਦਮਾਂ ਦੀ ਗਿਣਤੀ ਘਟਾ ਸਕਦੇ ਹਨ। ਭੁਗਤਾਨ → ਬੈਂਕ → ਬੁੱਕਕੀਪਿੰਗ ਦੀ ਬਜਾਏ, ਤੁਸੀਂ ਕਈ ਵਾਰ workflow ਨੂੰ ਇੱਕ ਥਾਂ ਰੱਖ ਸਕਦੇ ਹੋ ਅਤੇ ਤੇਜ਼ੀ ਨਾਲ ਮੇਲ-ਮਿਲਾਪ ਕਰ ਸਕਦੇ ਹੋ।
ਲੈਣ-ਦੇਣ ਜਾਂ ਫਾਈਨੈਂਸਿੰਗ ਉਤਪਾਦ (ਜਿਵੇਂ ਕੈਸ਼ ਐਡਵਾਂਸ ਜਾਂ ਲੋਨਾਂ) ਮੌਸਮੀ ਝਟਕੇ ਸਥਿਰ ਕਰਨ ਜਾਂ ਉਸ ਖਰੀਦ ਲਈ ਮਦਦ ਕਰ ਸਕਦੇ ਹਨ ਜਿਸ ਨੂੰ ਸਮੇਂ ਦੇ ਨਾਲ ਵਾਪਸ ਕੀਤਾ ਜਾ ਸਕੇ। ਪੇਸ਼ਕਸ਼ਾਂ ਆਮ ਤੌਰ 'ਤੇ ਯੋਗਤਾ, ਕਾਰੋਬਾਰ ਪ੍ਰਦਰਸ਼ਨ ਅਤੇ ਭੂਗੋਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀਆਂ ਹਨ। ਸ਼ਰਤਾਂ, ਫੀਸ ਅਤੇ ਰਿਪੇਮੈਂਟ ਮਕੈਨਿਕਸ ਵੱਖ-ਵੱਖ ਹੋ ਸਕਦੇ ਹਨ, ਇਸ ਲਈ ਨੁਕਤੇ-ਸ਼ਰਤਾਂ ਪੜ੍ਹਨ ਅਤੇ ਵਿਕਲਪਾਂ ਦੀ ਤੁਲਨਾ ਕਰਨ ਲਾਇਕ ਹੈ।
ਇਕ ਇਕਛੇਤ ਭੁਗਤਾਨ ਪ੍ਰਦਾਤਾ ਨੂੰ ਤੁਹਾਡੇ ਵਿਕਰੀ ਦੇ ਰੁਝਾਨ—ਵਾਲਿਊਮ, ਲਗਾਤਾਰਤਾ, ਰਿਫੰਡ, ਚਾਰਜਬੈਕ ਅਤੇ ਮੌਸਮੀ ਪ੍ਰਭਾਵ—ਦੀ ਵਿਸਤ੍ਰਿਤ ਨਜ਼ਰ ਹੋ ਸਕਦੀ ਹੈ। ਉਹ ਇਹ ਇਤਿਹਾਸ ਅੰਡਰਰਾਈਟਿੰਗ ਫੈਸਲਿਆਂ ਨੂੰ ਸੂਚਿਤ ਕਰਨ ਲਈ ਵਰਤ ਸਕਦਾ ਹੈ ਅਤੇ ਪੇਸ਼ਕਸ਼ਾਂ ਨੂੰ ਟੇਲਰ ਕਰ ਸਕਦਾ ਹੈ। ਪਰ ਇਹ ਮਨਜ਼ੂਰੀ, ਕੀਮਤ ਜਾਂ ਉਪਲਬਧਤਾ ਦੀ ਗਾਰੰਟੀ ਨਹੀਂ ਦਿੰਦਾ; ਇਸ ਦਾ ਵੱਖਰਾ ਲਾਭ ਇਹ ਹੈ ਕਿ ਕਾਘਜ਼ੀ ਕਾਰਵਾਈ ਘੱਟ ਹੋ ਸਕਦੀ ਹੈ ਅਤੇ ਫੈਸਲੇ ਤੇਜ਼ ਹੋ ਸਕਦੇ ਹਨ ਜਦੋਂ ਫਾਈਨੈਂਸਿੰਗ ਪੇਸ਼ ਕੀਤੀ ਜਾ ਰਹੀ ਹੋਵੇ।
Square ਨੇ ਵਿਕਰੇਤਿਆਂ ਦੇ ਨਾਲ ਸ਼ੁਰੂ ਕੀਤਾ, ਪਰ Block ਦੀ ਵੱਡੀ ਦਾਊ ਆ ਇੱਕ ਦੋ-ਪੱਖੀ ਨੈੱਟਵਰਕ ਹੈ: ਉਪਭੋਗਤਾ ਇੱਕ ਪਾਸੇ, ਬਿਜ਼ਨੇਸ ਦੂਜੇ ਪਾਸੇ। ਨਜ਼ਰ ਵਿੱਚ, ਇਹ ਨੈੱਟਵਰਕ ਹਰ ਕਿਸੇ ਲਈ ਘਟਾਓ ਘਟਾਉਣ ਵਾਲੀ friction ਘਟਾ ਸਕਦਾ ਹੈ—ਵਧੇਰੇ ਗਾਹਕ ਅਸਾਨੀ ਨਾਲ ਭੁਗਤਾਨ ਕਰ ਸਕਦੇ ਹਨ ਅਤੇ ਵਧੇਰੇ ਵਪਾਰੀ ਉਸ ਤਰੀਕੇ ਨੂੰ ਸਵੀਕਾਰ ਕਰ ਸਕਦੇ ਹਨ ਜਿਸ ਤਰ੍ਹਾਂ ਗਾਹਕ ਪਹਿਲਾਂ ਹੀ ਭੁਗਤਾਨ ਕਰਦੇ ਹਨ।
ਇਕ ਦੋ-ਪੱਖੀ ਨੈੱਟਵਰਕ ਉਸ ਵੇਲੇ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦੋਂ ਇੱਕ ਪਾਸੇ ਦੀ ਅਪਨਾਉਣ ਦੂਜੇ ਪਾਸੇ ਨੂੰ ਮਢੇ ਮੁੱਲ ਦਿੰਦੀ ਹੈ।
ਉਦਾਹਰਨ ਵਜੋਂ: ਜੇ ਹੋਰ ਉਪਭੋਗਤਾ Cash App ਵਿੱਚ ਪੈਸਾ ਰੱਖਦੇ ਹਨ ਅਤੇ ਇਸਨੂੰ ਵਾਰੰ-ਵਾਰ ਵਰਤਦੇ ਹਨ, ਤਾਂ ਵਪਾਰੀ ਇਸਨੂੰ ਸਵੀਕਾਰ ਕਰਨ ਨਾਲ ਲਾਭ ਉਠਾ ਸਕਦੇ ਹਨ। ਜੇ ਹੋਰ ਵਪਾਰੀ ਇਹ ਸਵੀਕਾਰ ਕਰਦੇ ਹਨ, ਤਾਂ ਉਪਭੋਗਤਾਵਾਂ ਦੇ ਕੋਲ ਖਰਚਣ ਲਈ ਹੋਰ ਜਗ੍ਹਾਂ ਹੋਣਗੀਆਂ, ਜੋ ਐਪ ਨੂੰ ਹੋਰ ਲਾਭਕਾਰੀ ਬਣਾਉਂਦਾ ਹੈ।
Cash App ਮੁੱਖ ਤੌਰ 'ਤੇ ਇਕ ਉਪਭੋਗਤਾ ਬ੍ਰਾਂਡ ਹੈ: ਪੀਅਰ-ਟੂ-ਪੀਅਰ ਟ੍ਰਾਂਸਫਰ, ਡੈਬਿਟ ਕਾਰਡ, ਡਾਇਰੈਕਟ ਡਿਪਾਜ਼ਿਟ ਅਤੇ ਹੋਰ ਵਿੱਤੀ ਖਾਸੀਅਤਾਂ। ਵਪਾਰ intersection ਸਭ ਤੋਂ ਸਿੱਧਾ ਉਸ ਵੇਲੇ ਹੈ ਜਦੋਂ ਇਹ ਆਮ ਭੁਗਤਾਨ ਅਨੁਭਵ ਵਰਗਾ ਦਿਸਦਾ ਹੈ:
ਮੁੱਖ ਗੱਲ: ਜ਼ਿਆਦਾਤਰ ਗਾਹਕਾਂ ਲਈ ਇਹ ਮਹਿਸੂਸ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ "ਮੈਂ ਆਪਣੀ ਮੌਜੂਦਾ ਵਿਆਵਸਥਾ ਨਾਲ ਤੇਜ਼ੀ ਨਾਲ ਭੁਗਤਾਨ ਕਰ ਸਕਦਾ ਹਾਂ", ਨਾ ਕਿ ਇਕ ਨਵਾਂ ਚੈਕਆਉਟ ਤਰੀਕਾ ਸਿੱਖਣਾ।
ਅਸਲ ਸਿਨਰਜੀ ਭੁਗਤਾਨ ਕਰਨ ਦੀ ਆਸਾਨੀ ਅਤੇ ਹੋਰ ਸੁਚੱਜੇ ਚੈਕਆਉਟ ਵਿੱਚ ਹੈ: ਘੱਟ ਛੱਡੇ ਹੋਏ ਕਾਰਟ, ਤੇਜ਼ ਲਾਈਨਾਂ, ਅਤੇ ਰਜਿਸਟਰ 'ਤੇ ਘੱਟ ਭੁੱਲ-ਚੁਕ।
ਜੋ ਸੀਮਤ ਹੈ ਉਹ ਆਟੋਮੈਟਿਕ "ਨੈੱਟਵਰਕ ਪ੍ਰਭਾਵ" ਨਹੀਂ ਜੋ ਨਵੀਆਂ ਗਾਹਕਾਂ ਦੀ ਗਰੰਟੀ ਕਰੇ। ਇੱਕ Square ਵਰਤਣ ਵਾਲਾ ਵਪਾਰੀ ਆਟੋਮੈਟਿਕ ਤੌਰ 'ਤੇ Cash App ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਇੱਕ ਵਿਗਿਆਪਨ ਪਲੇਟਫਾਰਮ ਵਾਂਗ ਐਕਸਪੋਜ਼ ਨਹੀਂ ਮਿਲਦਾ। ਕੋਈ ਵੀ ਖੋਜ ਜਾਂ ਮਾਰਕੇਟਿੰਗ ਪਰਤ ਪਰੋਡਕਟ ਨੀਤੀਆਂ, ਪ੍ਰੋਤਸਾਹਨ ਅਤੇ ਉਪਭੋਗਤਾ ਵਿਵਹਾਰ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ—ਸਿਰਫ਼ Block ਦੇ ਸਾਂਝੇ ਮਾਲਕੀ ਉੱਤੇ ਨਹੀਂ।
ਉਪਭੋਗਤਾ ਚਾਹੁੰਦੇ ਹਨ ਕਿ Cash App ਨਿੱਜੀ ਅਤੇ ਨਿੱਜੀ ਮਹਿਸੂਸ ਹੋਵੇ। ਵਪਾਰੀਆਂ ਨੂੰ ਸਾਫ ਰਸੀਦਾਂ, ਵਿਵਾਦ ਹਨਡਲਿੰਗ ਅਤੇ ਅਨੁਕੂਲਤਾ ਦੀ ਲੋੜ ਹੈ। ਇਹ ਦੁਨੀਆਂ ਜੋੜਣ ਲਈ ਸਾਵਧਾਨ ਹੱਦਾਂ ਦੀ ਲੋੜ ਹੈ: ਕੀ ਡੇਟਾ ਸਾਂਝਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਸਹਿਮਤੀ ਕਿਵੇਂ ਲئی ਜਾਂਦੀ ਹੈ, ਅਤੇ ਸੰਚਾਰ (ਰਿਫੰਡ, ਸਹਾਇਤਾ, ਪ੍ਰੋਮੋਸ਼ਨ) ਕਿਵੇਂ ਬਿਨਾਂ ਕਿਸੇ ਪੱਖ ਨੂੰ ਹੈਰਾਨ ਕੀਤੇ ਸੰਭਾਲਿਆ ਜਾਂਦਾ ਹੈ।
ਇਕ ਕਾਰਨ ਕਿ ਭੁਗਤਾਨ ਪਲੇਟਫਾਰਮ "ਛੋਟੇ ਕਾਰੋਬਾਰ ਓਐਸ" ਬਣ ਜਾਂਦੇ ਹਨ, ਸਧਾਰਨ ਹੈ: ਇੱਕ ਵੀ ਵੇਂਡਰ ਹਰ ਇੱਕ ਵਿਕਰੇਤਾ ਲਈ ਹਰ ਫੀਚਰ ਨਹੀਂ ਬਣਾ ਸਕਦਾ। ਰੈਸਟੋਰੈਂਟ ਡਿਲਿਵਰੀ ਚਾਹੁੰਦੇ ਹਨ, ਸਲੂਨ ਬੁੱਕਿੰਗ ਦੀ ਲੋੜ ਹੈ, ਰੀਟੇਲਰ ਬਾਰਕੋਡ ਇਨਵੈਂਟਰੀ ਚਾਹੁੰਦੇ ਹਨ, ਅਤੇ ਹਰ ਕੋਈ ਸਾਫ ਇਕਾਂਟਿੰਗ ਚਾਹੁੰਦਾ ਹੈ। Square ਵਰਗੇ ਪਲੇਟਫਾਰਮ ਵਧਦੇ ਹਨ ਕਿਉਂਕਿ ਹੋਰ ਐਪਸ ਨੂੰ ਉਨ੍ਹਾਂ ਦੇ ਭੁਗਤਾਨ ਅਤੇ ਵਿਕਰੀ ਡੇਟਾ ਨਾਲ ਜੁੜਨ ਦੀ ਆਗਿਆ ਦਿੰਦੇ ਹਨ।
ਇੰਟੈਗ੍ਰੇਸ਼ਨ ਦੂਟੀ ਦਾਖਲਾ ਅਤੇ ਗਲਤੀਆਂ ਘਟਾਉਂਦੀਆਂ ਹਨ। ਜਦੋਂ ਤੁਹਾਡਾ POS, ਆਨਲਾਈਨ ਸਟੋਰ ਅਤੇ ਇਕਾਂਟਿੰਗ ਸਿਸਟਮ ਗੱਲਬਾਤ ਨਹੀਂ ਕਰਦੇ, ਤਾਂ ਕਰਮਚਾਰੀ ਰਾਤ ਨੂੰ ਗੁੰਝਲ ਵਾਲੇ ਸਪ੍ਰੈਡਸ਼ੀਟ ਰੀਕਨਸਾਈਲ ਕਰਦੇ ਹਨ।
ਆਮ ਇੰਟੈਗ੍ਰੇਸ਼ਨ ਸ਼੍ਰੇਣੀਆਂ ਵਿੱਚ ਇਕਾਂਟਿੰਗ (QuickBooks/Xero-ਸਟਾਈਲ ਸਿੰਕ), ਈ-ਕੌਮਰਸ (ਆਨਲਾਈਨ ਕੈਟਾਲੌਗ ਅਤੇ ਸ਼ਿਪਿੰਗ), ਬੁਕਿੰਗ (ਅਪੌਇੰਟਮੈਂਟ ਅਤੇ ਰੀਮਾਈੰਡਰ) ਅਤੇ ਡਿਲਿਵਰੀ (ਮੇਨਿਊ, ਡਿਸਪੈਚ ਅਤੇ ਟਿੱਪਸ) ਆਦਿ ਹਨ। ਚੰਗੀਆਂ ਇੰਟੈਗ੍ਰੇਸ਼ਨਾਂ ਸਿਰਫ਼ ਰਿਪੋਰਟ ਨਿਕਾਸ ਨਹੀਂ ਕਰਦੀਆਂ—ਉਹ ਪ੍ਰੋਡਕਟ, ਟੈਕਸ, ਛੂਟ ਅਤੇ ਰਿਫੰਡਸ ਨੂੰ ਚੈਨਲਾਂ ਵਿੱਚ ਇਕਸਾਰ ਰੱਖਦੀਆਂ ਹਨ।
API ਉਹ ਨਿਯਮ ਹਨ ਜੋ ਹੋਰ ਸਾਫਟਵੇਅਰ ਨੂੰ ਤੁਹਾਡੇ ਭੁਗਤਾਨ ਪਲੇਟਫਾਰਮ ਨਾਲ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਜੁੜਨ ਦਿੰਦੇ ਹਨ। ਇਸਨੂੰ ਇਕ ਪਾਵਰ ਆਊਟਲੈਟ ਵਾਂਗ ਸੋਚੋ: ਇਹ ਨਿਰਧਾਰਤ ਨਹੀਂ ਕਰਦਾ ਕਿ ਤੁਸੀਂ ਕਿਹੜਾ ਡਿਵਾਈਸ ਪਲੱਗ ਕਰੋਗੇ, ਪਰ ਇਹ ਭਰੋਸੇਯੋਗ ਐਕਸੈੱਸ ਦਿੰਦਾ ਹੈ।
APIs ਨਾਲ, ਡਿਵੈਲਪਰ ਕਸਟਮ ਵਰਕਫਲੋ ਬਣਾ ਸਕਦੇ ਹਨ—ਜਿਵੇਂ ਕਿ ਖਰੀਦ ਤੋਂ ਬਾਅਦ CRM ਨੂੰ ਰਸੀਦ ਭੇਜਣਾ, ਖਰੀਦ 'ਤੇ ਲੋਯਲਟੀ ਪੌਇੰਟ ਟਰਿਗਰ ਕਰਨਾ, ਜਾਂ ਆਨਲਾਈਨ ਆਰਡਰ ਦੇ ਭੁਗਤਾਨ 'ਤੇ ਇਨਵੈਂਟਰੀ ਨੂੰ ਸਿੰਕ ਕਰਨਾ।
ਹੋਰ ਸੰਦ ਜ਼ਿਆਦਾ ਸ਼ਕਤੀ ਦੇ ਸਕਦੇ ਹਨ, ਪਰ ਨਾਲ ਹੀ ਹੋਰ ਹਿਸੇ ਵੀ ਆ ਜਾਂਦੇ ਹਨ। ਹਰ ਵਾਧੂ ਐਪ ਇਕ ਹੋਰ ਲਾਗਿਨ, ਇਕ ਹੋਰ ਬਿੱਲ ਅਤੇ ਜਦੋਂ ਕੁਝ ਟੁੱਟਦਾ ਹੈ ਤਾਂ ਇਕ ਹੋਰ ਸਹਾਇਤਾ ਟਿਕਟ ਦਾ ਮਤਲਬ ਹੈ। ਅਪਡੇਟਸ ਵੀ "ਇੰਟੈਗ੍ਰੇਸ਼ਨ ਡ੍ਰਿਫਟ" ਪੈਦਾ ਕਰ ਸਕਦੇ ਹਨ, ਜਿੱਥੇ ਇੱਕ ਪਾਸੇ ਇੱਕ ਫੀਚਰ ਬਦਲਦਾ ਹੈ ਅਤੇ ਦੂਜੇ ਪਾਸੇ ਇਹ ਚੁਪਚਾਪ ਕੰਮ ਕਰਨਾ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ।
ਫੀਚਰ ਲਿਸਟ ਤੋਂ ਬਾਹਰ ਵੇਖੋ। ਸਮੀਖਿਆ ਦੀ ਗੁਣਵੱਤਾ (ਕੇਵਲ ਸਟਾਰ ਨਹੀਂ), ਐਪ ਦੇ ਆਖ਼ਰੀ ਅਪਡੇਟ, ਕੀ ਸਹਾਇਤਾ ਸਾਂਝੀ ਹੈ ਜਾਂ ਸਾਫ਼ ਤੌਰ 'ਤੇ ਮਲਕੀਅਤ ਤਹਿਤ ਹੈ, ਅਤੇ ਜੇ ਤੁਸੀਂ ਅਣਇੰਸਟਾਲ ਕਰੋ ਤਾਂ ਕੀ ਹੁੰਦਾ—ਕੀ ਤੁਸੀਂ ਡੇਟਾ, ਆਟੋਮੇਸ਼ਨ ਜਾਂ ਇਤਿਹਾਸਕ ਰਿਪੋਰਟ ਗੁਆਉਗੇ?
ਇਕ sehatmand ਮਾਰਕੀਟਪਲੇਸ ਗਿਣਤੀ ਬਾਰੇ نہیں, ਪਰ ਨਿਰਭਰਯੋਗ ਅਤੇ ਚੰਗੀ ਤਰ੍ਹਾਂ ਬਣਾਈਆਂ ਜੁੜਾਈਆਂ ਬਾਰੇ ਹੁੰਦਾ ਹੈ।
ਇੱਕ "ਬਿਜ਼ਨਸ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ" ਇਕ ਇਕੱਲਾ ਐਪ ਨਹੀਂ ਹੁੰਦਾ—ਇਹ ਉਹ defaults ਹਨ ਜਿਨ੍ਹਾਂ 'ਤੇ ਤੁਸੀਂ ਆਪਣਾ ਦਿਨ ਚਲਾਉਂਦੇ ਹੋ। ਜੇ ਤੁਸੀਂ ਕੈਫੇ ਮਾਲਿਕ ਹੋ, ਤਾਂ ਇਹ ਉਹ ਟੂਲ ਹੈ ਜੋ ਦੱਸਦਾ ਹੈ ਕਿ ਕੀ ਵਿਕਿਆ, ਕਿਸ ਨੇ ਕੰਮ ਕੀਤਾ, ਤੁਹਾਨੂੰ ਕਿੰਨਾ ਟੈਕਸ ਦੇਣਾ ਹੈ, ਕੀ ਸਟਾਕ ਵਿੱਚ ਹੈ, ਅਤੇ ਪੈਸਾ ਕਦੋਂ ਤੁਹਾਡੇ ਖਾਤੇ ਵਿੱਚ ਆ ਰਿਹਾ ਹੈ। ਭੁਗਤਾਨ ਓਐਸ ਬਣ ਜਾਂਦੇ ਹਨ ਜਦੋਂ ਉਹ ਆਖ਼ਰੀ ਕਦਮ ਹੋਣ ਦੇ ਬਦਲੇ ਪਹਿਲੀ ਪਰਤ ਬਣ ਜਾਂਦੇ ਹਨ ਜਿਸ ਵਿੱਚ ਹੋਰ ਸਭ ਕੁਝ ਜੁੜਦਾ ਹੈ।
ਇਹ ਦਾindikator ਇਹ ਹੈ ਕਿ ਅਸਲ ਸੱਚਾਈ ਕਿੱਥੇ ਰਹਿੰਦੀ ਹੈ। ਜੇ ਤੁਹਾਡੀ ਭੁਗਤਾਨ ਸਿਸਟਮ ਉਹ ਜਗ੍ਹਾ ਹੈ ਜਿੱਥੇ ਵਿਕਰੀ, ਰਿਫੰਡ, ਟਿੱਪ, ਛੂਟ ਅਤੇ ਗਾਹਕ ਰਸੀਦਾਂ ਉਤਪੰਨ ਹੁੰਦੀਆਂ ਹਨ, ਤਾਂ ਹਰ ਹੋਰ ਕਾਰਜ ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਉਸ ਨਾਲ ਜੁੜਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ: ਇਨਵੈਂਟਰੀ, ਸਟਾਫ਼ ਅਧਿਕਾਰ, ਲੋਯਲਟੀ ਅਤੇ ਰਿਪੋਰਟਿੰਗ। ਜਿੰਨਾ ਜ਼ਿਆਦਾ ਤੁਹਾਡੇ ਦਿਨ ਦੇ ਸਵਾਲ ਇਕ ਹੀ ਜਗ੍ਹਾ 'ਚ ਜਵਾਬ ਮਿਲਦੇ ਹਨ, ਉਤਨਾ ਇਹ ਓਐਸ ਵਰਗਾ ਵਰਤਦਾ ਹੈ।
ਬੰਡਲਿੰਗ ਮਾਰਕੀਟਿੰਗ ਵਰਗੀ ਲੱਗ ਸਕਦੀ ਹੈ, ਪਰ ਆਮ ਫਾਇਦੇ ਸਿੱਧੇ ਹਨ:
ਇਸੇ ਲਈ Square ਵਰਗੇ ਪਲੇਟਫਾਰਮ ਫਿਕਸ ਹੋ ਜਾਣਗੇ: ਨਾ ਕਿ ਕਿਸੇ ਇਕ ਫੀਚਰ ਕਾਰਨ, ਪਰ ਕਿਉਂਕਿ ਪੂਰਾ ਸਿਸਟਮ ਲਾਜ਼ਮੀ ਤੌਰ 'ਤੇ ਮਿਲ ਕੇ ਕੰਮ ਕਰਦਾ ਹੈ।
"ਸਵਿੱਚਿੰਗ ਲਾਗਤ" ਸਿਰਫ਼ ਕੈਂਸਲੇਸ਼ਨ ਫੀਸਾਂ ਨਹੀਂ ਹੁੰਦੀ। ਇਹ ਬਦਲਣ ਦਾ ਛੁਪਿਆ ਹੋਇਆ ਕੰਮ ਹੈ:
ਚਾਹੇ ਨਵਾਂ ਪ੍ਰਦਾਤਾ ਸਸਤਾ ਹੋਵੇ, ਤਬਦੀਲੀ ਵਿੱਚ ਇੱਕ ਅਸਲ ਓਪਰੇਸ਼ਨਲ ਲਾਗਤ ਹੁੰਦੀ ਹੈ।
ਜਾਣਣ ਲਈ ਦੋ ਬਕਟ ਬਨਾਓ:
ਇੱਕ ਚੰਗਾ ਨਿਯਮ: ਆਪਣਾ ਮਹੀਨਾਵਾਰ ਕਾਰਡ ਵਾਲਿਊਮ ਅੰਦਾਜ਼ਾ ਲਗਾਓ, ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨ ਫੀਸਾਂ ਲਗਾਓ, ਫਿਰ ਸਿਰਫ਼ ਉਹੀ ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਜੋ ਤੁਸੀਂ ਸਚਮੁੱਚ ਵਰਤੋਂਗੇ ਜੋੜੋ। ਜੇ ਤੁਸੀਂ ਪੂਰਾ "ਸਭ-ਇੱਕ" ਅੰਦਾਜ਼ਾ ਨਹੀਂ ਲੈ ਸਕਦੇ, ਤਾਂ ਇਹ ਰੋਕਣ ਦਾ ਸੰਕੇਤ ਹੈ—ਹੌਲੀ ਹੋ ਕੇ ਅਤੇ ਵਧੇਰੇ ਸਵਾਲ ਪੁੱਛੋ।
ਭੁਗਤਾਨਾਂ ਨੂੰ ਤੁਹਾਡੇ ਕਾਰੋਬਾਰ ਦਾ ਕੇਂਦਰ ਬਣਾਉਣਾ ਸਮੇਂ ਬਚਾ ਸਕਦਾ ਹੈ ਅਤੇ ਟੂਲ-ਭੰਡਾਰ ਨੂੰ ਘਟਾ ਸਕਦਾ ਹੈ—ਪਰ ਇਹ ਜੋਖਮ ਨੂੰ ਵੀ ਇਕੱਠਾ ਕਰਦਾ ਹੈ। ਜਦੋਂ ਤੁਹਾਡਾ ਚੈਕਆਉਟ, ਡਿਪਾਜ਼ਿਟ, ਗਾਹਕ ਡੇਟਾ ਅਤੇ ਕਈ ਵਾਰ ਫਾਈਨੈਂਸਿੰਗ ਇੱਕ ਪ੍ਰਦਾਤਾ ਰਾਹੀਂ ਲੰਘਦੇ ਹਨ, ਇੱਕ ਛੋਟੀ ਸਮੱਸਿਆ ਸਾਰੇ ਓਪਰੇਸ਼ਨ 'ਤੇ ਫੈਲ ਸਕਦੀ ਹੈ।
ਭੁਗਤਾਨ ਆਊਟੇਜ ਸਿਰਫ਼ ਇੱਕ ਅਸੁਵਿਧਾ ਨਹੀਂ—ਇਹ ਵਿਕਰੀ ਨੂੰ ਰੋਕ ਸਕਦਾ ਹੈ, ਆਨਲਾਈਨ ਆਰਡਰ ਤੋੜ ਸਕਦਾ ਹੈ ਅਤੇ ਦਿਨ-ਅੰਤ ਰਿਕਨਸਾਈਲੈਸ਼ਨ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰ ਸਕਦਾ ਹੈ। ਪ੍ਰੋਸੈਸਿੰਗ ਚੱਲਦੀ ਹੋਣ ਦੇ ਬਾਵਜੂਦ, ਵਪਾਰੀ ਚਾਰਜਬੈਕਸ ਅਤੇ ਵਿਵਾਦਾਂ ਨਾਲ ਭੜਕਦੇ ਹਨ ਜੋ ਰੇਵਿਨਿਊ ਅਤੇ ਕਰਮਚਾਰੀ ਸਮਾਂ ਬੰਦ ਕਰ ਦੇਂਦੇ ਹਨ।
ਇਸ ਮਾਮਲੇ ਵਿੱਚ ਸਹਾਇਤਾ ਦੀ ਗੁਣਵੱਤਾ ਬਹੁਤ ਵੱਧ ਮਹੱਤਵ ਰੱਖਦੀ ਹੈ। ਜਦੋਂ ਕੁਝ 5pm ਸ਼ਨੀਵਾਰ ਨੂੰ ਫੇਲ ਹੋ ਜਾਂਦਾ ਹੈ, ਤੇਜ਼ ਅਤੇ ਸਖ਼ਤ ਅਧਿਕਾਰਾਂ ਵਾਲੀ ਸਹਾਇਤਾ ਤੇ ਇਕ ਟਿਕਟ ਕਤਾਰ ਵਿੱਚ ਫਰਕ ਤੁਰੰਤ ਨੁਕਸਾਨ ਅਤੇ ਗਾਹਕ ਨਾਰਾਜ਼ਗੀ ਵਿੱਚ ਨਜ਼ਰ ਆਉਂਦਾ ਹੈ।
ਜ਼ਿਆਦਾਤਰ ਵਪਾਰੀ ਸਿਰਫ਼ "ਕਾਰਡ ਲੈਣਾ ਸ਼ੁਰੂ" ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਨ, ਪਰ ਪ੍ਰਦਾਤਾਵਾਂ ਨੂੰ ਕਾਠੋਰ ਅਨੁਕੂਲਤਾ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।
ਜੇ ਤੁਹਾਡੀ ਜਾਣਕਾਰੀ ਬਦਲਦੀ ਹੈ (ਨਵਾਂ ਮਾਲਕ, ਨਵਾਂ ਬੈਂਕ ਖਾਤਾ, ਨਵਾਂ ਕਾਰੋਬਾਰੀ ਮਾਡਲ), ਤਾਂ ਜਲਦੀ ਅਪਡੇਟ ਕਰੋ ਤਾਂ ਜੋ ਡਿਪਾਜ਼ਿਟ ਦੇ ਦੇਰੀ ਜਾਂ ਅਕਾਉਂਟ ਰਿਵਿयੂ ਤੋਂ ਬਚ ਸਕੋ।
ਇਕੋਸਿਸਟਮ ਤਬਦੀਲ ਹੁੰਦਾ ਹੈ। ਕੀਮਤਾਂ ਬਦਲ ਸਕਦੀਆਂ ਹਨ, ਫੀਚਰ ਹਟਾਏ ਜਾ ਸਕਦੇ ਹਨ, ਅਤੇ ਫਰੌਡ ਦੀਆਂ ਲਹਿਰਾਂ ਦੌਰਾਨ ਨੀਤੀਆਂ ਸਕੁੰਨੀ ਹੋ ਸਕਦੀਆਂ ਹਨ। ਜੇ ਤੁਹਾਡਾ POS, ਭੁਗਤਾਨ ਅਤੇ ਰਿਪੋਰਟਿੰਗ ਨੇੜਾ-ਨੇੜਾ ਜੁੜੇ ਹਨ, ਤਾਂ ਬਦਲਣਾ ਆਸਾਨ ਨਹੀਂ—ਖ਼ਾਸ ਕਰਕੇ ਜੇ ਹਾਰਡਵੇਅਰ, ਵਰਕਫਲੋ ਅਤੇ ਟ੍ਰੇਨਿੰਗ ਇੱਕ ਪ੍ਰਣਾਲੀ 'ਤੇ ਨਿਰਭਰ ਹਨ।
ਅਮਲ ਵਿੱਚ ਸਧਾਰਣ ਬੈਕਅੱਪ ਰੱਖੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਵਿਕਣਾ ਜਾਰੀ ਰੱਖ ਸਕੋ ਅਤੇ ਆਪਣਾ ਰਿਕਾਰਡ ਰੱਖ ਸਕੋ:
ਭੁਗਤਾਨ + POS ਸਟੈਕ ਚੁਣਨਾ "ਸਰਵੋਤਮ ਬ੍ਰੈਂਡ" ਬਾਰੇ ਨਹੀਂ, ਬਲਕਿ ਮੈਚ ਬਾਰੇ ਹੈ: ਤੁਸੀਂ ਕਿਵੇਂ ਆਰਡਰ ਲੈਂਦੇ ਹੋ, ਕਿੰਨੀ ਵਾਰ ਰਿਫੰਡ ਕਰਦੇ ਹੋ, ਸਟਾਫ਼ ਕਿਵੇਂ ਮੈਨੇਜ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਤੁਸੀਂ ਕਿੰਨੀ ਇੰਟੈਗ੍ਰੇਸ਼ਨ 'ਤੇ ਨਿਰਭਰ ਹੋ। ਇਹ ਚੈਕਲਿਸਟ ਵਿਕਲਪਾਂ ਦੀ ਤੁਲਨਾ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰੇਗੀ।
Retail (ਇਨਵੈਂਟਰੀ-ਭਾਰ)
Food & beverage (ਗਤੀ + ਮੋਡੀਫਾਇਰ)
Services (ਅਪੌਇੰਟਮੈਂਟ + ਦੁਹਰਾਉ ਗਾਹਕ)
ਵਿਕਰੇਤਾ ਨੂੰ ਦਿਖਾਉਣ ਲਈ ਕਹੋ—ਬਤਾਉਣ ਲਈ ਨਹੀਂ—ਕੀ ਇਹ ਹਕੀਕਤ ਵਿੱਚ ਵਰਕਫਲੋ ਵਿੱਚ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ:
ਸਵਿੱਚ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਉਹ ਡੇਟਾ ਨਕਸ਼ਾ ਜੋ ਤੁਹਾਨੂੰ ਚਾਹੀਦੀ ਹੈ ਅਤੇ ਹਰ ਕਦਮ ਦਾ ਮਾਲਿਕ ਕੌਣ ਹੈ:
ਜੇ ਤੁਸੀਂ ਵਿਕਲਪਾਂ ਦੀ ਮੁਕਾਬਲਾ ਕਰ ਰਹੇ ਹੋ ਅਤੇ ਇਕ ਢਾਂਚੇਵਾਰ ਤੁਲਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ contact ਰਾਹੀਂ ਸੰਪਰਕ ਕਰੋ ਜਾਂ pricing ਨੂੰ ਵੇਖੋ।
Block ਦੀ ਕਹਾਣੀ ਉਪਯੋਗੀ ਹੈ ਭਲੇ ਹੀ ਤੁਸੀਂ ਭੁਗਤਾਨ ਨਹੀਂ ਬਣਾ ਰਹੇ। ਇਹ ਦਿਖਾਉਂਦੀ ਹੈ ਕਿ ਕਿਸ ਤਰ੍ਹਾਂ "ਇੱਕ ਵਿਸ਼ੇਸ਼ ਫੀਚਰ" ਹਰ ਰੋਜ਼ ਦੇ ਕਾਰਜਕਾਰੀ ਓਐਸ ਵਿੱਚ ਵਧ ਸਕਦਾ ਹੈ—ਜੇ ਤੁਸੀਂ ਠੀਕ ਦਿਸ਼ਾ ਵਿੱਚ ਵਿਸਥਾਰ ਕਰੋ ਅਤੇ ਭਰੋਸਾ ਜਿੱਤੋ।
Square ਨੇ "ਕਾਰੋਬਾਰ ਚਲਾਉਣਾ" ਚਲਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਾਲ ਸ਼ੁਰੂ ਨਹੀਂ ਕੀਤਾ। ਇਹ ਇਕ ਜ਼ਰੂਰੀ ਕੰਮ ਨਾਲ ਸ਼ੁਰੂ ਹੋਇਆ: ਸਧਾਰਨ ਅਤੇ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਭੁਗਤਾਨ ਪ੍ਰਾਪਤ ਕਰਨਾ।
ਫਾਉਂਡਰਾਂ ਲਈ ਉਤਪਾਦ ਸਬਕ ਇਹ ਹੈ ਕਿ ਇੱਕ ਅਕਸਰ-ਹੋਣ ਵਾਲੇ, ਉੱਚ-ਸੱਟ ਵਾਲੇ ਵਰਕਫਲੋ 'ਤੇ ਧਿਆਨ ਦਿਓ—ਜਿੱਥੇ ਫੇਲ੍ਹ ਸਪੱਸ਼ਟ ਹੈ ਅਤੇ ਮੁੱਲ ਤੁਰੰਤ ਪਛਾਣਯੋਗ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ ਉਸ ਪਲ 'ਤੇ ਕਬਜ਼ਾ ਕਰ ਲੈਂਦੇ ਹੋ, ਤਾਂ ਨੇੜਲੇ ਟਾਸਕਾਂ ਵੱਲ ਵਧੋ ਜੋ ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਉਸਦਾ ਅਨੁਕਰਨ ਕਰਦੇ ਹਨ: ਰਸੀਦ, ਰਿਫੰਡ, ਟਿੱਪ, ਸਟਾਫ਼ ਪਰਮੀਸ਼ਨ, ਇਨਵੈਂਟਰੀ ਕਾਉਂਟ, ਗਾਹਕ ਸੁਨੇਹੇ। ਨੇੜਲਾ ਹੀ "ਬੜਾ" ਨੂੰ ਪਰਾਜਿਤ ਕਰਦਾ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਤੁਹਾਡੇ ਉਤਪਾਦ ਨੂੰ ਸਮਰਥਿਤ ਅਤੇ ਉਪਭੋਗਤਾ ਲਈ ਲਾਜ਼ਮੀ ਬਣਾਉਂਦਾ ਹੈ।
ਹਾਰਡਵੇਅਰ, ਆਨਬੋਰਡਿੰਗ ਅਤੇ ਭਰੋਸਾ ਅਕਸਰ ਛੋਟੇ-ਕਾਰੋਬਾਰ ਸਾਫਟਵੇਅਰ ਵਿੱਚ ਅਸਲ moat ਹਨ:
ਵੰਡ ਨੂੰ ਉਪਭੋਗਤਾ ਅਨੁਭਵ ਦਾ ਹਿੱਸਾ ਮੰਨੋ: ਪੈਕੇਜਿੰਗ, ਟਿਊਟੋਰਿਯਲ, ਇੰਸਟਾਲੇਸ਼ਨ, ਪਹਿਲਾ ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨ ਅਤੇ ਪਹਿਲਾ ਪੇਆਉਟ—ਸਭ "ਉਤਪਾਦ" ਹਨ।
ਭੁਗਤਾਨ ਇੱਕ ਸੰਚਿਤ ਆਪਰੇਸ਼ਨਲ ਸਿਗਨਲ ਪੈਦਾ ਕਰਦਾ ਹੈ: ਚਰਮ ਘੰਟੇ, ਉਤਪਾਦ ਤੇਜ਼ੀ, ਦੁਹਰਾਉ ਗਾਹਕ, ਚਾਰਜਬੈਕ ਪੈਟਰਨ। ਇਹ ਡੇਟਾ ਵਾਸਤੇ ਸਹਾਇਕ ਫੀਚਰ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ (ਸ्मਾਰਟ ਰੀਓਰਡ, ਸਟਾਫ਼ ਸੁਝਾਅ, ਨਕਦੀ-ਪ੍ਰਵਾਹ ਅਨੁਮਾਨ), ਪਰ ਇਹ ਤਕਨੀਕੀ ਉਪਭੋਗਤਾ ਉਮੀਦਾਂ ਨਾਲ ਸੰਗਤ ਰੱਖ ਕੇ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।
ਸਪੱਸ਼ਟ ਰਿਹਾ ਕਿ ਤੁਸੀਂ ਕੀ ਇਕੱਤਰ ਕਰਦੇ ਹੋ ਅਤੇ ਕਿਉਂ; ਸਾਰਥਕ ਨਿਯੰਤਰਣ ਪੇਸ਼ ਕਰੋ; ਅਤੇ ਉਹ ਡੇਟਾ-ਉਪਯੋਗ ਨਾ ਕਰੋ ਜੋ ਨਿਗਰਾਨੀ ਵਰਗਾ ਮਹਿਸੂਸ ਹੋਵੇ। ਭਰੋਸਾ ਜਮਾਉਂਦਾ ਹੈ; ਝਟਕਾ ਵੀ।
ਜੇ ਤੁਸੀਂ ਅੰਦਰੂਨੀ ਟੂਲ ਜਾਂ ਨਵਾਂ ਵਰਟੀਕਲ POS ਬਣਾਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਇਸ ਲੇਖ ਦਾ ਪੈਟਰਨ ਮਹੱਤਵਪੂਰਨ ਹੈ: ਜੇ ਭੁਗਤਾਨ ਸਿਸਟਮ ਆਫ ਰਿਕਾਰਡ ਬਣ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਟੀਮਾਂ ਨੂੰ ਛੇਤੀ ਡੈਸ਼ਬੋਰਡ, ਭੂਮਿਕਾ-ਅਧਾਰਿਤ ਪਹੁੰਚ, ਰਿਕਨਸਾਈਲੈਸ਼ਨ ਵਿਊਜ਼ ਅਤੇ ਇੰਟੈਗ੍ਰੇਸ਼ਨ ਗਲੂ ਦੀ ਲੋੜ ਹੋਵੇਗੀ।
ਪਲੇਟਫਾਰਮਾਂ ਜਿਵੇਂ Koder.ai ਪ੍ਰੋਡਕਟ ਟੀਮਾਂ ਨੂੰ ਉਹ ਓਪਰੇਸ਼ਨਲ ਲੇਅਰ ਤੇਜ਼ੀ ਨਾਲ ਪ੍ਰੋਟੋਟਾਈਪ ਅਤੇ ਸ਼ਿਪ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦੇ ਹਨ: ਤੁਸੀਂ ਚੈਟ ਵਿੱਚ ਵਰਕਫਲੋ ਵਰਣਨ ਕਰਦੇ ਹੋ, ਅਤੇ ਇਕ ਕਾਮਯਾਬ ਵੈੱਬ ਐਪ (ਆਮ ਤੌਰ 'ਤੇ React ਫਰੰਟ-ਐਂਡ, Go + PostgreSQL ਬੈਕ-ਐਂਡ) ਜਨਰੇਟ ਹੁੰਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਯੋਜਨਾ ਮੋਡ, ਡਿਪਲੌਇਮੈਂਟ/ਹੋਸਟਿੰਗ, ਸਨੈਪਸ਼ਾਟਸ ਅਤੇ ਰੋਲਬੈਕ ਵਰਗੀਆਂ ਖਾਸੀਅਤਾਂ ਸ਼ਾਮਿਲ ਹਨ। ਇਹ ਵਿਸ਼ੇਸ਼ਤੌਰ 'ਤੇ ਉਪਯੋਗੀ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਮਰਚੈਂਟ ਐਡਮਿਨ ਪੋਰਟਲ ਜਾਂ ਰਿਪੋਰਟਿੰਗ ਕੰਸੋਲ ਨੂੰ ਜਲਦੀ ਤੋਂ ਖੜਾ ਕਰਕੇ ਅਸਲ ਮਰਚੈਂਟ ਫੀਡਬੈਕ ਅਧਾਰ 'ਤੇ ਵਰਕ ਕਰੋ—ਬਿਨਾਂ ਆਪਣੇ ਸਟੈਕ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਨਵਾਂ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ।
ਸਭ ਤੋਂ ਛੋਟਾ ਉਤਪਾਦ ਬਣਾਓ ਜੋ ਇਕ ਦਰਦਨਾਕ ਕੰਮ ਦਾ ਹੱਲ ਕਰਦਾ ਹੋਵੇ, ਇੱਕ ਬਿਹਤਰ ਐਂਡ-ਟੂ-ਐਂਡ ਅਨੁਭਵ ਰਾਹੀਂ ਵੰਡ ਜਿੱਤੋ, ਅਤੇ ਸਿਰਫ਼ ਉਹੀ ਜਗ੍ਹਾ ਫੈਲਾਓ ਜਿੱਥੇ ਤੁਸੀਂ ਭਰੋਸੇਯੋਗ ਰਹਿ ਸਕੋ। ਜੇ ਤੁਸੀਂ ਮੁੱਖ ਨਿਰਮਾਣ ਬਲਾਕਾਂ ਦੀ ਤੁਲਨਾ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਵੇਖੋ: blog/pos-vs-payment-gateway।
ਇਸਦਾ ਮਤਲਬ ਇਹ ਹੈ ਕਿ ਭੁਗਤਾਨ ਪ੍ਰਣਾਲੀ ਦਿਨ-ਚੜ੍ਹਦੇ ਕਾਰੋਬਾਰ ਲਈ ਮੂਲ “ਸਰੋਤ-ਅਸਲ” ਬਣ ਜਾਂਦੀ ਹੈ—ਸਿਰਫ਼ ਕਾਰਡ ਲੈਣ ਦੀ ਜਗ੍ਹਾ ਨਹੀਂ। ਚੈਕਆਉਟ ਤੋਂ ਆ ਰਹੇ ਵਿਕਰੀ ਡੇਟਾ ਨਾਲ ਇਨਵੈਂਟਰੀ, ਸਟਾਫ਼ ਰਿਪੋਰਟਿੰਗ, ਗਾਹਕ ਰਸੀਦਾਂ/ਲੋਯਲਟੀ, ਇਕਾਂਟਿੰਗ ਐਕਸਪੋਰਟ ਅਤੇ ਨਕਦੀ ਪ੍ਰਵਾਹ ਦੀ ਨਜ਼ਰ ਇੱਕਠੇ ਮਿਲਦੀ ਹੈ।
ਕਿਉਂਕਿ ਚੈਕਆਉਟ ਲਗਾਤਾਰ ਹੁੰਦਾ ਹੈ ਅਤੇ ਸਾਫ਼, ਟਾਈਮਸਟੈਂਪ ਵਾਲੇ ਰਿਕਾਰਡ ਪੈਦਾ ਕਰਦਾ ਹੈ (ਆਈਟਮ, ਰਕਮ, ਕਰਮਚਾਰੀ, ਚੈਨਲ, ਰਿਫੰਡ)। ਇਹ ਲੱਕੜੀ ਵਾਲੇ ਹਿਸਾਬਾਂ ਨਾਲੋਂ ਬਹੁਤ ਵਧੀਆ ਅਤੇ ਹਾਲੀਆ ਸਿਗਨਲ ਦਿੰਦਾ ਹੈ, ਇਸ ਲਈ ਹੋਰ ਟੂਲ ਆਸਾਨੀ ਨਾਲ ਇਸ ਨੂੰ ਜੁੜਦੇ ਹਨ।
ਭੁਗਤਾਨ ਢਾਂਚਾ ਵਿੱਚ ਉਹ ਸਭ ਸ਼ਾਮਲ ਹੈ ਜੋ ਗ੍ਰਾਹਕ ਤੋਂ ਪੈਸੇ ਲੈਣ ਅਤੇ ਤੁਹਾਡੇ ਖਾਤੇ ਤੱਕ ਪਹੁੰਚਣ ਲਈ ਲੋੜੀਂਦਾ ਹੈ: ਹਾਰਡਵੇਅਰ ਜਾਂ ਆਨਲਾਈਨ ਚੈਕਆਉਟ, ਲੈਣ-ਦੇਣ ਪ੍ਰੋਸੈਸਿੰਗ, ਰਿਪੋਰਟਿੰਗ ਅਤੇ ਨਿਪਟਾਣਾ (funds ਦਾ ਬੈਂਕ ਨੂੰ ਜਾਣਾ)। ਅਮਲ ਵਿੱਚ ਇਸ ਦੇ ਨਾਲ ਰਸੀਦਾਂ, ਰਿਫੰਡ, ਟਿੱਪਸ ਅਤੇ ਰਿਕੋੰਸੀਲੀਏਸ਼ਨ ਵੀ ਜੁੜੇ ਹੁੰਦੇ ਹਨ।
ਇੱਕ ਹੀ ਪਰਦਾਤਾ ਨਾਲ ਇਨ-ਪర్సਨ ਤੇ ਆਨਲਾਈਨ ਭੁਗਤਾਨ ਹੋਣ ਨਾਲ ਟੂਲਾਂ ਦੀ ਗਿਣਤੀ ਘਟਦੀ ਹੈ।
ਇੱਕ ਹੀ ਰਿਪੋਰਟਿੰਗ ਅਤੇ ਪੇਆਉਟ ਸ਼ਡਿਊਲ
ਗਾਹਕ ਰਿਕਾਰਡ ਤੇ ਰਸੀਦਾਂ ਵਿੱਚ ਇਕਸਾਰਤਾ
ਘੱਟ ਮਿਲਾ-ਜੁਲਾ ਫੀਸਾਂ ਅਤੇ ਸੈਟਿੰਗਜ਼
ਇਹ ਸਿਰਫ਼ ਸਹੂਲਤ ਨਹੀਂ—ਇਹ ਸਥਿਰਤਾ ਦਿੰਦਾ ਹੈ।
ਹਾਰਡਵੇਅਰ ‘‘ਦਿਨ-ਇੱਕਤੇ’’ ਰੁਕਾਵਟ ਘਟਾਉਂਦਾ ਹੈ: ਪਲੱਗ ਕਰੋ, ਆਨਬੋਰਡਿੰਗ ਫੋਲੋ ਕਰੋ ਅਤੇ ਤੁਰੰਤ ਪੈਸੇ ਲੈਣਾ ਸ਼ੁਰੂ ਕਰੋ। ਬਹੁਤ ਸਾਰੇ ਮਾਲਕਾਂ ਲਈ ਸਭ ਤੋਂ ਆਸਾਨ ਸੈਟਅਪ ਜਿੱਤਦਾ ਹੈ—ਭਾਵੇਂ ਹੋਰ ਸਾਫਟਵੇਅਰ ਵਿਸ਼ਾਲ ਖੁਬੀਆਂ ਰੱਖਦੇ ਹੋਣ।
ਇਹ ਸਵਾਲ ਸਹੀ ਤੌਰ ਤੇ ਪੂਛੋ ਜਦੋਂ ਤੁਸੀਂ ਕਿਸੇ ਸਿਸਟਮ 'ਤੇ ਨਿਰਭਰ ਹੋਣ ਦੀ ਸੋਚ ਰਹੇ ਹੋ।
POS ਭੁਗਤਾਨ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਦਾ ਵਰਕਫਲੋ ਹੈ: ਪ੍ਰੋਡਕਟ ਕੈਟਾਲੌਗ, ਮੋਡੀਫਾਇਰ, ਟੈਕਸ, ਛੂਟ, ਸਟਾਫ਼ ਅਧਿਕਾਰ, ਟਿੱਪਸ ਅਤੇ ਗਾਹਕ ਰਸੀਦਾਂ। ਠੀਕ ਤਰ੍ਹਾਂ ਕਨਫਿਗਰ ਹੋਣ ਤੇ, ਇਹ ਆਰਡਰਿੰਗ, ਰਿਫੰਡ ਅਤੇ ਰਿਪੋਰਟਿੰਗ ਨੂੰ ਸਥਿਰ ਰੱਖਦਾ ਹੈ।
ਆਪਣਾ “ਆਮ ਪੇਆਉਟ” ਸਮਝੋ ਨਾ ਕਿ ਸਿਰਫ਼ ਸਭ ਤੋਂ ਤੇਜ਼ ਵਿਕਲਪ। ਸਾਫ਼ਕਰੋ:
ਇਹਾਂੋਂ ਤੁਸੀਂ ਆਪਣੀ ਨਕਦੀ-ਪ੍ਰਵਾਹ ਦੀ ਯੋਜਨਾ ਬਣਾ ਸਕਦੇ ਹੋ।
ਭੁਗਤਾਨ ਇਤਿਹਾਸ (ਵਾਲਿਊਮ, ਲਗਾਤਾਰਤਾ, ਮੌਸਮੀ ਬਦਲਾਅ, ਰਿਫੰਡ/ਚਾਰਜਬੈਕ) ਇੱਕ ਇਕੱਤਰ ਪਰਦਾਤਾ ਨੂੰ ਤੇਜ਼ ਅਤੇ ਘੱਟ ਕਾਗਜ਼ੀ ਕਾਰਵਾਈ ਨਾਲ ਅਡਰਰਾਈਟਿੰਗ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ। ਪਰ ਮਨ ਨੂੰ ਰੱਖੋ: ਮਨਜ਼ੂਰੀ, ਕੀਮਤ ਅਤੇ ਉਪਲਬਧਤਾ ਹਮੇਸ਼ਾਂ ਯਕੀਨੀ ਨਹੀਂ ਹੁੰਦੇ।
ਇਕਸਾਈ ਡਿਟੇਲ:
ਚੰਗੀ ਇਨਟੈਗ੍ਰੇਸ਼ਨ ਉਹ ਹੈ ਜੋ ਡਾਟਾ ਸਹੀ ਤਰ੍ਹਾਂ ਸਿੰਕ ਕਰੇ ਤੇ ਬਿਗੜੇ ਬਿਨਾਂ।