ਇੱਕ ਜਮ੍ਹਾਂ-ਰਿਫੰਡ ਟ੍ਰੈਕਰ ਵਰਤੋ ਤਾਂ ਜੋ ਪਤਾ ਰਹੇ ਕਿ ਕਿਸਨੇ ਕਿੰਨਾ ਦਿਤਾ, ਕਿਹੜੀ ਸੇਵਾ ਲਈ ਸੀ, ਅਤੇ ਕੀ ਰਿਫੰਡ ਕੀਤਾ ਗਿਆ—ਇਕ ਸਧਾਰਨ ਵਰਕਫਲੋ ਨਾਲ ਜੋ ਮਿਸ ਨਾ ਹੋਵੇ।
ਜਮ੍ਹਾਂ ਅਤੇ ਰਿਫੰਡ ਇਸ ਲਈ ਭੁੱਲ ਜਾਂਦੇ ਹਨ ਕਿਉਂਕਿ ਜ਼ਿਆਦਾਤਰ ਛੋਟੀ ਸੇਵਾ ਵਾਲੇ ਕਾਰੋਬਾਰ ਹਰ ਚੀਜ਼ ਫੌਰਨ ਫੈਸਲਿਆਂ 'ਤੇ ਚਲਦੇ ਹਨ। ਤੁਸੀਂ ਸਪੌਟ ਰੱਖਣ ਲਈ ਜਮ੍ਹਾਂ ਲੈਂਦੇ ਹੋ, ਗ੍ਰਾਹਕ ਮੁੜ-ਤਾਰੀਖ ਕਰਦਾ ਹੈ, ਕੋਈ ਐਡ-ਆਨ ਜੁੜ ਜਾਂਦਾ ਹੈ, ਫਿਰ ਤੁਸੀਂ ਅਗਲੇ ਨਿਆਂਤਕ afspraak ਵੱਲ ਦੌੜ ਪੈਂਦੇ ਹੋ। ਪੈਸਾ ਤੁਹਾਡੇ ਨੋਟਾਂ ਤੋਂ ਤੇਜ਼ ਹਿਲਦਾ ਹੈ।
ਸਭ ਤੋਂ ਆਮ ਸਮੱਸਿਆਵਾਂ ਆਮ ਹਾਲਤਾਂ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੀਆਂ ਹਨ:
ਨੋ-ਸ਼ੋਜ਼ ਇੱਕ ਵੱਖਰੀ ਗੜਬੜ ਬਣਾਉਂਦੇ ਹਨ। ਕੁਝ ਕਾਰੋਬਾਰ ਜਮ੍ਹਾਂ ਰੱਖਦੇ ਹਨ, ਕੁਝ ਹਿੱਸਾ ਰਿਫੰਡ ਕਰਦੇ ਹਨ, ਅਤੇ ਕੁਝ ਕਰੈਡਿਟ ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰਦੇ ਹਨ। ਜੇ ਤੁਸੀਂ ਕੇਸ-ਬਾਈ-ਕੇਸ ਫੈਸਲਾ ਕਰਦੇ ਹੋ ਤਾਂ ਇਹ ਭੁੱਲ ਜਾਣਾ ਆਸਾਨ ਹੈ, ਖਾਸ ਕਰਕੇ ਜੇ ਇਹ ਗੱਲ ਟੈਕਸਟ ਰਾਹੀਂ ਕੀਤੀ ਗਈ ਹੋਵੇ।
ਜ਼ਿਆਦਾਤਰ ਛੁੱਟੇ ਹੋਏ ਰਿਫੰਡ ਗਣਿਤ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨਹੀਂ ਹੁੰਦੇ। ਉਨ੍ਹਾਂ ਦੀ ਵਜ੍ਹਾ ਇਹ ਹੈ ਕਿ ਰਿਕਾਰਡ ਟੈਕਸਟਾਂ, ਡੀਐਮਜ਼, ਬੁਕਿੰਗ ਐਪਾਂ, ਭੁਗਤਾਨ ਨੋਟੀਫਿਕੇਸ਼ਨਾਂ ਅਤੇ ਯਾਦ ਵਿੱਚ ਵੰਡੇ ਹੋਏ ਹੁੰਦੇ ਹਨ। ਇੱਕ ਥਾਂ 'ਤੇ ਅਪੌਇੰਟਮੈਂਟ ਹੋ ਸਕਦੀ ਹੈ, ਦੂਜੇ ਥਾਂ ਤੇ ਭੁਗਤਾਨ, ਅਤੇ ਕੋਈ ਵੀ ਇਹ ਨਹੀਂ ਦੱਸਦਾ ਕਿ ਭੁਗਤਾਨ ਕਿਸ ਲਈ ਸੀ। ਹਫ਼ਤਿਆਂ ਬਾਅਦ ਤੁਸੀਂ ਇੱਕ ਲੈਣ-ਦੇਣ ਵੇਖਦੇ ਹੋ ਅਤੇ ਪਤਾ ਨਹੀਂ ਲੱਗਦਾ ਕਿ ਇਹ ਜਮ੍ਹਾਂ ਸੀ, ਪੂਰਾ ਭੁਗਤਾਨ ਸੀ ਜਾਂ ਰਿਫੰਡ।
ਇੱਕ ਸਧਾਰਨ ਟ੍ਰੈਕਰ ਨੂੰ "ਬੁਕਕੀਪਿੰਗ" ਜਿਹਾ ਮਹਿਸੂਸ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ। ਇਹ ਸਿਰਫ ਹਰ ਵਾਰੀ ਚਾਰ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਦੇਵੇ:
ਇਹਨਾਂ ਦਾ ਲਗਾਤਾਰ ਜਵਾਬ ਦਿਓ ਅਤੇ ਤੁਸੀਂ ਰਿਫੰਡ ਨਹੀਂ ਗੁਆਉਗੇ, ਅਜੀਬ ਫਾਲੋਅਪ ਨਹੀਂ ਕਰਨ ਪੈਣਗੇ, ਅਤੇ ਆਪਣੇ ਨੰਬਰਾਂ ਨੂੰ ਭਰੋਸੇਯੋਗ ਰੱਖੋਗੇ।
ਇੱਕ ਟ੍ਰੈਕਰ ਤਦ ਹੀ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦੋਂ ਹਰ ਐਂਟਰੀ ਇੱਕ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦੇਵੇ: ਇਸ ਗ੍ਰਾਹਕ ਦੇ ਪੈਸੇ ਨਾਲ ਕੀ ਹੋਇਆ, ਅਤੇ ਕਿਉਂ।
ਸਪੱਸ਼ਟ ਪਛਾਣ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ: ਗ੍ਰਾਹਕ ਦਾ ਨਾਂ ਅਤੇ ਇਕ ਕਾਂਟੈਕਟ ਰੈਫਰੈਂਸ ਜੋ ਤੁਹਾਨੂੰ ਬਾਅਦ ਵਿੱਚ ਪਛਾਣ ਆਵੇ (ਫੋਨ, ਈਮੇਲ, ਜਾਂ ਇਨਵਾਇਸ ਨੰਬਰ)। ਜੇ ਦੋ ਲੋਕ ਇੱਕੋ ਨਾਮ ਸਾਂਝਾ ਕਰਦੇ ਹਨ ਤਾਂ ਉਹ ਵਾਧੂ ਰੈਫਰੈਂਸ ਮਿਕਸ-ਅੱਪ ਰੋਕਦਾ ਹੈ।
ਅਗਲਾ, ਦਰਜ ਕਰੋ ਕਿ ਭੁਗਤਾਨ ਕਿਸ ਲਈ ਸੀ। ਇੱਕ ਛੋਟਾ ਸੇਵਾ ਵੇਰਵਾ ਅਤੇ ਸੇਵਾ ਦੀ ਤਾਰੀਖ (ਜਾਂ ਤਾਰੀਖ-ਰੇਂਜ) ਲਿਖੋ। ਜੇ ਸੇਵਾ ਕਈ ਵਾਰਾਂ ਵਿੱਚ ਹੁੰਦੀ ਹੈ ਤਾਂ ਮੁੱਖ ਤਰੀਕਾਂ ਨੋਟ ਕਰੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਵੇਖ ਸਕੋ ਕਿ ਕਿਸ ਤਰੀਕ ਨੂੰ ਦਿੱਤਾ ਗਿਆ ਜਨੂੰ ਪਹਿਲਾਂ ਡਿਲੀਵਰ ਕੀਤਾ ਗਿਆ ਸੀ।
ਧਨ ਖੇਤਰਾਂ ਲਈ, ਪੜ੍ਹਨਯੋਗ ਅਤੇ ਮਿਲਾਉਣਯੋਗ ਰੱਖੋ। ਇੱਕ ਪ੍ਰਯੋਗਕ ਉੱਪਰਲਿਖਤ ਸੈੱਟ ਹੈ:
ਰਿਫੰਡਾਂ ਨੂੰ ਵਾਧੂ ਸੰਦਰਭ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਕਿਉਂਕਿ ਯਾਦਦਾਸ਼ਤ ਇੱਥੇ ਧੁੰਦਲੀ ਹੋ ਜਾਂਦੀ ਹੈ। ਹਮੇਸ਼ਾਂ ਰਿਫੰਡ ਦੀ ਤਾਰੀਖ ਅਤੇ ਸਾਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ ਕਾਰਣ ਦਰਜ ਕਰੋ (ਗ੍ਰਾਹਕ ਨੇ ਰੱਦ ਕੀਤਾ, ਵਧੇਰੇ ਭੁਗਤਾਨ, ਸੇਵਾ ਦੀ ਸਮੱਸਿਆ, ਭਲਾਈ ਦਿਖਾਣ ਲਈ)।
ਆਖਿਰ ਵਿੱਚ, ਦਰਸਾਓ ਕਿ ਪੈਸਾ ਕਿਵੇਂ ਹਿਲਿਆ: ਭੁਗਤਾਨ ਢੰਗ (ਨਕਦ, ਬੈਂਕ ਟਰਾਂਸਫਰ, ਕਾਰਡ) ਅਤੇ ਇੱਕ ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨ ਰੈਫਰੈਂਸ ਜੋ ਤੁਸੀਂ ਜਲਦੀ ਕੱਢ ਸਕੋ (ਰਸੀਦ ਨੰਬਰ, ਆਖਰੀ 4 ਅੰਕ, ਪ੍ਰੋਸੈਸਰ ID)। ਇਹ ਸਟੇਟਮੈਂਟ ਖੋਜਾਂ ਨੂੰ ਤੇਜ਼ ਕਰਦਾ ਹੈ।
ਇੱਕ ਸਥਿਤੀ ਖੇਤਰ ਜੋ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਸਕੈਨ ਕਰ ਸਕਦੇ ਹੋ ਜੋੜੋ: Booked, Completed, Cancelled, No-show, Refunded.
ਉਦਾਹਰਨ: “Mina L., ਡੀਪ ਕਲੀਨ (ਦੋ ਦੌਰੇ), ਜਮ੍ਹਾਂ $80, ਕੁੱਲ ਭੁਗਤਾਨ $200, $50 2026-01-05 ਨੂੰ ਰਿਫੰਡ ਕੀਤਾ ਗਿਆ, ਕਾਰਨ: ਦੂਜਾ ਦੌਰਾ ਰੱਦ, ਸਥਿਤੀ: refunded.”
ਸਭ ਤੋਂ ਵਧੀਆ ਟ੍ਰੈਕਰ ਉਹ ਹੈ ਜੋ ਤੁਸੀਂ ਵੀਰਾਮ ਸਮੇਂ, ਆਪਣੇ ਫੋਨ 'ਤੇ, ਗ੍ਰਾਹਕ ਖੜਾ ਹੋਣ 'ਤੇ ਖੋਲ੍ਹ ਸਕੋ। ਇੱਕ ਥਾਂ ਚੁਣੋ ਅਤੇ ਉਸਨੂੰ ਸ੍ਰੋਤ-ਸਚਾਈ ਸਮਝੋ। ਜੇ ਤੁਸੀਂ ਵੇਰਵੇ ਸਪ੍ਰੈਡਸ਼ੀਟ, ਟੈਕਸਟ ਥਰੈਡ ਅਤੇ ਇਨਵਾਇਸਾਂ ਵਿੱਚ ਵੰਡ ਦਿਓਗੇ ਤਾਂ ਰਿਫੰਡ ਫਿਸਲ ਜਾਣਗੇ।
ਜ਼ਿਆਦਾਤਰ ਛੋਟੀ ਸੇਵਾ ਵਾਲੀ ਟੀਮਾਂ ਇੱਕ ਸਧਾਰਨ ਸਪ੍ਰੈਡਸ਼ੀਟ ਨਾਲ ਠੀਕ ਕਰ ਲੈਂਦੀਆਂ ਹਨ। ਇਹ ਪਹਚਾਨਯੋਗ, ਤੇਜ਼ ਖੋਜਯੋਗ, ਅਤੇ ਗ੍ਰਾਹਕ ਨਾਮ, ਤਾਰੀਖ ਜਾਂ ਸਥਿਤੀ ਨਾਲ ਸੋਰਟ ਕਰਨ ਵਿੱਚ ਆਸਾਨ ਹੈ। ਨੁਕਸ ਇਹ ਹੈ ਕਿ ਜਦੋਂ ਲੋਕ ਵੱਖ-ਵੱਖ ਸ਼ਬਦਾਵਲੀ ਵਰਤਦੇ ਹਨ, ਕਾਲਮ ਸੋਧਦੇ ਹਨ ਜਾਂ ਇੱਕੋ ਹੀ ਫਾਰਮੈਟ ਭੁੱਲ ਜਾਂਦੇ ਹਨ ਤਾਂ ਸ਼ੀਟ ਗੜਬੜ ਹੋ ਸਕਦੀ ਹੈ।
ਜੇ ਇੱਕ ਤੋਂ ਵੱਧ ਵਿਅਕਤੀ ਭੁਗਤਾਨ ਲੈਂਦੇ ਹਨ ਤਾਂ ਤੁਹਾਨੂੰ ਮਲਟੀ-ਯੂਜ਼ਰ ਐਕਸੈਸ ਅਤੇ ਚੇਂਜ ਹਿਸਟਰੀ ਦੀ ਲੋੜ ਹੋਵੇਗੀ। ਬਿਨਾਂ ਇਸਦੇ, ਤੁਸੀਂ "ਇਸ ਨੰਬਰ ਨੂੰ ਕਿਸ ਨੇ ਬਦਲਿਆ?" ਵਾਲੀ ਸਥਿਤੀ ਵਿੱਚ ਫਸ ਜਾਂਦੇ ਹੋ।
ਜਦ ਸਪ੍ਰੈਡਸ਼ੀਟ ਟੁੱਟਣ ਲੱਗੇ, ਇੱਕ ਛੋਟਾ ਇੰਟਰਨਲ ਐਪ ਸਹੀ ਹੋ ਸਕਦਾ ਹੈ। ਲਕੜੀ ਦਾ ਮਕਸਦ ਫੈਂਸੀ ਰਿਪੋਰਟਿੰਗ ਨਹੀਂ ਹੈ—ਗਲਤੀਆਂ ਘੱਟ ਕਰਨ ਲਈ ਲਾਜ਼ਮੀ ਫੀਲਡ, ਰਿਫੰਡ ਕਾਰਨਾਂ ਲਈ ਡ੍ਰੌਪਡਾਊਨ ਅਤੇ ਆਟੋਮੈਟਿਕ ਟੋਟਲ ਹਨ।
ਜੋ ਭੀ ਤੁਸੀ ਚੁਣੋ, ਇਸਨੂੰ ਛੋਟੀ ਸਕ੍ਰੀਨ ਲਈ ਡਿਜ਼ਾਈਨ ਕਰੋ। ਮੁੱਖ ਫੀਲਡ ਪਹਿਲਾਂ ਰੱਖੋ (Client, Service, Total, Paid, Refunded, Balance due, Status), ਨੋਟ ਛੋਟੇ ਰੱਖੋ, ਅਤੇ ਇੱਕ ਤਾਰੀਖ ਅਤੇ ਮੂਦਰਾ ਫਾਰਮੈਟ ਵਰਤੋ।
ਜੇ ਖੋਲ੍ਹ ਕੇ ਅਪਡੇਟ ਕਰਨ ਵਿੱਚ ਇੱਕ ਮਿੰਟ ਤੋਂ ਵੱਧ ਲੱਗਦਾ ਹੈ ਤਾਂ ਇਹ ਅਪ-ਟੂ-ਡੇਟ ਨਹੀਂ ਰਹੇਗਾ।
ਕੁਝ ਬੋਰਿੰਗ ਪਰ ਲਗਾਤਾਰ ਬਣਾਓ। ਤੁਸੀਂ ਸਪੱਸ਼ਟਤਾ ਲਈ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹੋ, ਨਾ ਕਿ ਜਟਿਲਤਾ ਲਈ।
ਅਸਲ ਜ਼ਿੰਦਗੀ ਲਈ ਸਭ ਤੋਂ ਸਾਫ਼ ਸੈਟਅਪ ਦੋ ਸਧਾਰਨ ਟੈਬ (ਜਾਂ ਦੋ ਭਾਗ) ਹਨ:
ਇਸ ਨਾਲ ਉਹ ਆਮ ਗਢਬੜ ਰੁਕਦੀ ਹੈ ਜਿੱਥੇ ਤੁਸੀਂ "ਹਰ ਬੁਕਿੰਗ ਲਈ ਇੱਕ ਸਤਰ" ਚਾਹੁੰਦੇ ਹੋ ਪਰ ਤਿੰਨ ਵੱਖ-ਵੱਖ ਭੁਗਤਾਨ ਅਤੇ ਇੱਕ ਰਿਫੰਡ ਵੇਖਣਾ ਵੀ ਲਾਜ਼ਮੀ ਹੁੰਦਾ ਹੈ ਬਿਨਾਂ ਕਿਸੇ ਚੀਜ਼ ਨੂੰ ਓਵਰਰਾਈਟ ਕੀਤੇ।
ਬੁਕਿੰਗ ਸੰਖੇਪ ਲਈ, ਇੱਕ ਸਧਾਰਨ ਹੈਡਰ ਐਸਾ ਕੰਮ ਕਰਦਾ ਹੈ:
Booking ID | Date booked | Client name | Service name | Service date(s) | Total price | Status | Notes | Exceptions?
ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨ ਲੌਗ ਲਈ, ਇਸਨੂੰ ਕੇਂਦਰਿਤ ਰੱਖੋ:
Date | Booking ID | Client name | Type (Deposit/Payment/Refund) | Amount | Method | Reference ID | Refund reason | Notes
ਕੁਝ ਨਿਯਮ ਜੋ ਬਾਅਦ ਵਿੱਚ ਗਲਤਫਹਮੀ ਰੋਕਦੇ ਹਨ:
ਡ੍ਰੌਪਡਾਊਨ ਸ਼ਬਦਾਵਲੀ ਨੂੰ ਇਕਸਾਰ ਰੱਖਦੇ ਹਨ ਤਾਂ ਕਿ ਫਿਲਟਰ ਅਤੇ ਟੋਟਲ ਸਹੀ ਕੰਮ ਕਰਨ।
ਛੋਟਾ ਸੈੱਟ ਵਰਤੋ:
ਸੇਵਾਵਾਂ ਲਈ ਇੱਕ ਨਾਂ-ਚਾਲੂ ਨਿਯਮ ਬਣਾਓ ਤਾਂ ਖੋਜ ਠੀਕ ਹੋਵੇ: ਸ਼ੁਰੂ ਕਰੋ ਇੱਕ ਸ਼੍ਰੇਣੀ ਨਾਲ, ਫਿਰ ਵੇਰਵਾ। ਉਦਾਹਰਨਾਂ: “Massage - 60 min”, “Cleaning - 2 bed”, “Consult - follow-up”.
ਨਿਰਧਾਰਤ ਕਰੋ ਕਿ Exceptions? = Yes ਕਦੋਂ ਹੋਵੇਗਾ। ਆਮ ਟ੍ਰਿਗਰ ਹਨ ਦਿਨਾਂ ਵਿਚ ਵੰਡੇ ਭੁਗਤਾਨ, ਅংশਕ ਰਿਫੰਡ, ਭੁਗਤਾਨ ਤੋਂ ਬਾਅਦ ਲਾਗੂ ਹੋਏ ਛੂਟ, ਚਾਰਜਬੈਕ, ਜਾਂ ਕੁਝ ਵੀ ਜਿਸ ਨੇ ਤੁਹਾਨੂੰ ਕੈਲਕੁਲੇਟਰ ਖੋਲ੍ਹਣ 'ਤੇ ਮਜਬੂਰ ਕੀਤਾ।
ਟ੍ਰੈਕਰ ਨੂੰ ਇਕ ਰਸੀਦ ਬਿਨ ਰੀਕ ਦੀ ਤਰ੍ਹਾਂ ਵਰਤੋ। ਪੈਸਾ ਹਿਲਦਾ ਹੀ ਛੋਟੀ ਐਂਟਰੀ ਜੋੜੋ, ਹਫ਼ਤੇ ਦੇ ਆਖ਼ਿਰ 'ਤੇ ਨਹੀਂ।
ਇੱਕ ਘੱਟ-ਕੋਸ਼ਿਸ਼ ਰੋਟੀਨ ਇਸ ਤਰ੍ਹਾਂ ਹੈ:
ਸਬੂਤ ਇਸ ਤਰੀਕੇ ਨਾਲ ਰੱਖੋ ਜਿੰਦਾ ਤੁਹਾਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਮਿਲ ਜਾਵੇ। ਟ੍ਰੈਕਰ ਐਂਟਰੀ 'ਚ “Invoice #1042” ਜਾਂ “Transfer ref 7H3K” ਰੱਖ ਸਕਦੇ ਹੋ, ਅਤੇ ਤੁਸੀਂ ਹਰ ਵਾਰ ਮੇਲ ਜਾਂ ਬੈਂਕ ਸਕਰੀਨਸ਼ਾਟ ਉਸੇ ਫੋਲਡਰ ਵਿੱਚ ਰੱਖੋ।
ਉਦਾਹਰਨ: ਗ੍ਰਾਹਕ ਸੋਮਵਾਰ ਨੂੰ $100 ਜਮ੍ਹਾਂ ਦੇਂਦਾ ਹੈ, ਸ਼ੁੱਕਰਵਾਰ ਨੂੰ ਬਾਕੀ $200 ਦੇਂਦਾ ਹੈ, ਫਿਰ ਇੱਕ ਉਤਪਾਦ ਗੈਰ-ਉਪਲਬਧ ਹੋਣ ਕਰਕੇ $50 ਰਿਫੰਡ ਮਿਲਦਾ ਹੈ। ਤੁਹਾਡੇ ਲੌਗ ਵਿੱਚ ਤਿੰਨ ਵੱਖ-ਵੱਖ ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ, ਹਰ ਇੱਕ ਦੇ ਆਪਣੇ ਰੇਫਰੈਂਸ ID ਨਾਲ।
ਸਮੀਖਿਆ ਦੀ ਰਿਥਮ ਫੈਂਸੀ ਟੂਲਾਂ ਤੋਂ ਜ਼ਿਆਦਾ ਮਹੱਤਵਪੂਰਨ ਹੈ:
ਜਦੋਂ ਅਸਲ ਜਿੰਦਗੀ "ਚੁਕਦੀਆਂ" ਕਹਾਣੀ ਨਾਲ ਮਿਲਦੀ ਨਹੀਂ ਤਾਂ ਰਿਫੰਡ ਗੁੰਝਲਦਾਰ ਹੋ ਜਾਂਦੇ ਹਨ। ਤੁਹਾਡਾ ਟ੍ਰੈਕਰ ਇੱਥੇ ਵੀ ਪੜ੍ਹਨਯੋਗ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ।
ਅੰਸ਼ਕ ਵਿਰੁੱਧ ਪੂਰਨ ਰਿਫਂਡ: ਮੂਲ ਭੁਗਤਾਨ ਨੂੰ ਓਵਰਰਾਈਟ ਨਾ ਕਰੋ। ਭੁਗਤਾਨਾਂ ਨੂੰ ਜਿਵੇਂ ਉਹ ਸਨ ਰੱਖੋ, ਅਤੇ ਰਿਫੰਡਾਂ ਨੂੰ ਵੱਖ-ਵੱਖ ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨ ਵਜੋਂ ਦਰਜ ਕਰੋ ਜਿਨ੍ਹਾਂ ਦੀ ਆਪਣੀ ਤਾਰੀਖ ਅਤੇ ਕਾਰਨ ਹੋਵੇ।
ਮੁੜ-ਤਾਰੀਖਾਂ: ਇੱਕ ਨਿਯਮ ਚੁਣੋ ਅਤੇ ਉਸ ਤੇ ਟਿਕੇ ਰਹੋ। ਜੇ ਇਹ ਇਕੋ ਕੰਮ ਹੈ ਤਾਂ ਬੁਕਿੰਗ ਸੰਖੇਪ ਦੀ ਸੇਵਾ ਦਿਨ ਅਪਡੇਟ ਕਰੋ ਅਤੇ ਨੋਟ ਜੋੜੋ। ਜੇ ਨਵੀਂ ਕੁੰਜੀ ਜਾਂ ਕੀਮਤ ਨਵਾਂ ਕੰਮ ਮਹਿਸੂਸ ਕਰਦੀ ਹੈ ਤਾਂ ਨਵਾਂ Booking ID ਬਣਾਓ ਅਤੇ ਪੁਰਾਣੇ ਦੀ ਨੋਟ ਕਰੋ।
ਗੈਰ-ਰਿਫੰਡੇਬਲ ਜਮ੍ਹਾਂ: ਯਾਦ 'ਤੇ ਨਿਰਭਰ ਨਾ ਕਰੋ। ਇੱਕ ਛੋਟਾ ਨੀਤੀ ਨੋਟ ਅਤੇ ਜਦੋਂ ਇਹ ਵਿਆਖਿਆ ਕੀਤੀ ਗਈ ਸੀ ਉਸ ਦੀ ਮਿਤੀ ਲਿਖੋ (ਉਦਾਹਰਨ: “24 ਘੰਟਿਆਂ ਬਾਅਦ ਨਨ-ਰਿਫੰਡੇਬਲ, 2 ਮਈ ਨੂੰ ਟੈਕਸਟ ਨਾਲ ਪੁਸ਼ਟੀ”)।
ਚਾਰਜਬੈਕ ਅਤੇ ਵਿਵਾਦ: ਇਨ੍ਹਾਂ ਨੂੰ ਆਪਣੀ ਸਥਿਤੀ ਸਮਝੋ, ਸਧਾਰਨ ਰਿਫੰਡ ਤੋਂ ਨਹੀਂ। ਤਾਰੀਖਾਂ ਅਤੇ ਛੋਟੀ ਟਾਈਮਲਾਈਨ ਨੋਟ ਜੋੜੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਕੀ ਹੋਇਆ ਉਸ ਨੂੰ ਫ਼ਾਲੋ ਕਰ ਸਕੋ।
ਟਿੱਪਸ, ਐਡ-ਆਨ, ਅਪਗਰੇਡ: ਉਹਨਾਂ ਨੂੰ ਜਮ੍ਹਾਂ ਤੋਂ ਵੱਖ ਰੱਖੋ। ਟਿੱਪ ਆਮ ਤੌਰ 'ਤੇ ਰਿਫੰਡ ਯੋਗਤਾ ਘਟਾਉਂਦੇ ਨਹੀਂ, ਅਤੇ ਐਡ-ਆਨ ਸਿਰਫ ਉਸ ਵੇਲੇ ਰਿਫੰਡਯੋਗ ਹੋ ਸਕਦੇ ਹਨ ਜੇ ਉਹ ਡਿਲੀਵਰ ਨਹੀਂ ਹੋਏ। ਜੇ ਤੁਸੀਂ ਰੈਗੂਲਰ ਤੌਰ 'ਤੇ ਐਕਸਟਰਾਸ ਵੇਚਦੇ ਹੋ ਤਾਂ ਬੁਕਿੰਗ ਨੋਟ ਵਿੱਚ “Extras” ਲਾਈਨ ਜੋੜੋ ਅਤੇ ਵਾਧੂ ਭੁਗਤਾਨ ਨੂੰ ਵੱਖ ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨ ਵਜੋਂ ਲੌਗ ਕਰੋ।
ਤੁਹਾਡਾ ਟ੍ਰੈਕਰ ਭਰੋਸੇਯੋਗ ਰਹਿੰਦਾ ਹੈ ਜਦੋਂ ਹਰ ਬੁਕਿੰਗ ਦੋ ਤੇਜ਼ ਨੰਬਰ ਸਮਰਥਨ ਕਰਦੀ ਹੈ: ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਕੀ ਰੱਖਿਆ, ਅਤੇ ਗ੍ਰਾਹਕ ਨੂੰ ਹੋਰ ਕਿੰਨਾ ਦੇਣੇ ਹਨ।
ਇਹ ਦੋ ਗਣਨਾਵਾਂ ਵਰਤੋ:
Net paid = Total paid - Total refunded
Balance due = Service total - Net paid
ਉਦਾਹਰਨ: ਗ੍ਰਾਹਕ ਨੇ $200 ਦਿੱਤੇ, ਤੁਸੀਂ $50 ਰਿਫੰਡ ਕੀਤਾ, ਅਤੇ ਸੇਵਾ ਕੁੱਲ $300 ਹੈ। Net paid $150 ਹੈ ਅਤੇ Balance due $150।
ਏਕ ਬੇਸਿਕ ਮਾਸਿਕ ਨਜ਼ਾਰੇ ਲਈ, ਭੁਗਤਾਨ ਅਤੇ ਰਿਫੰਡ ਵੱਖ ਰੱਖੋ:
ਰਿਫੰਡਾਂ ਨੂੰ ਨੈਗੇਟਿਵ ਭੁਗਤਾਨ ਵਜੋਂ ਦਰਜ ਕਰਨ ਤੋਂ ਬਚੋ ਜੇ ਤੱਕ ਤੁਸੀਂ ਬਿਲਕੁਲ ਇਕਸਾਰ ਨਾ ਹੋਵੋ। ਮਿਲੇ-ਜੁਲੇ ਸਾਇਨਾਂ ਨਾਲ ਟੋਟਲਾਂ ਗੜਬੜ ਹੋ ਜਾਂਦੇ ਹਨ।
ਕੁਝ ਛੋਟੀ ਜਾਂਚਾਂ ਜ਼ਿਆਦਾਤਰ ਐਰਰ ਕੈਚ ਕਰ ਲੈਂਦੀਆਂ ਹਨ:
ਇੱਕ ਗ੍ਰਾਹਕ 3-ਦੌਰੇ ਪੈਕੇਜ ($300 ਕੁੱਲ) ਬੁੱਕ ਕਰਦਾ ਹੈ ਅਤੇ $100 ਜਮ੍ਹਾਂ ਦਿੰਦਾ ਹੈ। ਦੋ ਦਿਨ ਬਾਅਦ ਉਹ ਪਹਿਲਾ ਦੌਰਾ ਮੁੜ-ਤਾਰੀਖ ਕਰਦਾ ਹੈ। ਦੂਜੇ ਦੌਰੇ ਤੋਂ ਬਾਅਦ ਉਹ ਤੀਜੇ ਦੌਰੇ ਨੂੰ ਰੱਦ ਕਰ ਦਿੰਦਾ ਅਤੇ ਅੰਸ਼ਕ ਰਿਫੰਡ ਮੰਗਦਾ ਹੈ।
ਇਹ ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨ ਲੌਗ ਵਿੱਚ ਇਸ ਤਰ੍ਹਾਂ ਦਿੱਖ ਸਕਦਾ ਹੈ। ਮੁਕੱਦਮੇ ਦਾ ਮਕਸਦ ਇਹ ਹੈ ਕਿ ਘਟਨਾਵਾਂ ਜਿਵੇਂ ਜਿਵੇਂ ਹੋ ਰਹੀਆਂ ਹਨ ਉਹਨਾਂ ਨੂੰ ਦਰਜ ਕੀਤਾ ਜਾਵੇ, ਬਾਅਦ ਵਿੱਚ ਕਹਾਣੀ ਦੁਬਾਰਾ ਬਣਾਉਣ ਲਈ ਨਹੀਂ।
Client: Jordan P. Service: 3-visit package Invoice/Ref: JP-014
2026-01-05 | Deposit received | +$100 | Method: card | For: hold first visit | Balance due: $200
2026-01-07 | Rescheduled | $0 | From: Jan 10 to Feb 10 | Note: no money moved
2026-02-10 | Visit 1 done | $0 | Notes: completed
2026-02-17 | Payment received | +$200 | Method: bank transfer | For: remaining package | Balance due: $0
2026-02-24 | Visit 2 done | $0 | Notes: completed
2026-03-01 | Partial refund | -$100 | Reason: cancelled visit 3 | Refunded to: card | Status: pending
2026-03-03 | Refund cleared | $0 | Confirmation: REF-8831 | Status: completed
ਹਫਤਾਵਾਰੀ ਸਮੀਖਿਆ "Partial refund - pending" ਦੇਖ ਕੇ ਕਿਸੇ ਛੁੱਟੇ ਰਿਫੰਡ ਨੂੰ ਫੜ ਲਏਗੀ ਜੇ "Refund cleared" ਐਂਟਰੀ ਨਹੀਂ ਹੈ।
ਜ਼ਿਆਦਾਤਰ ਟ੍ਰੈਕਿੰਗ ਸਿਸਟਮ ਇੱਕੋ ਹੀ ਤਰੀਕੇ ਨਾਲ ਫੇਲ ਹੁੰਦੇ ਹਨ: ਉਹ "ਕਾਫ਼ੀ ਨੇੜੇ" ਮਹਿਸੂਸ ਹੁੰਦੇ ਹਨ ਜਦ ਤੱਕ ਕੋਈ ਰਿਫੰਡ ਗਲਤ ਗ੍ਰਾਹਕ ਕੋਲ ਨਹੀਂ ਚਲਾ ਜਾਂਦਾ, ਜਾਂ ਜਮ੍ਹਾਂ ਨੂੰ ਦੋ ਵਾਰੀ ਲਗਾਇਆ ਨਹੀਂ ਜਾਂਦਾ।
ਆਮ ਮੁੱਦੇ ਅਤੇ ਠੀਕ ਕਰਨ ਦੇ ਤਰੀਕੇ:
ਜੇ ਤੁਸੀਂ ਇੱਕ ਲੰਮੇ ਨੋਟ ਸੈੱਲ 'ਚ "Zelle ਰਾਹੀਂ ਭੁਗਤਾਨ, 5 ਜੂਨ ਲਈ ਜਮ੍ਹਾਂ, ਆਧੇ ਰਿਫੰਡ" ਵਰਗੀ ਲਿਖ ਰਹੇ ਹੋ ਤਾਂ ਇਹ ਇੱਕ ਨਿਸ਼ਾਨ ਹੈ ਕਿ ਤੁਹਾਡੇ ਨੂੰ ਵੱਖ-ਵੱਖ ਫੀਲਡਾਂ ਦੀ ਲੋੜ ਹੈ।
ਇਕ ਟ੍ਰੈਕਰ ਸਿਰਫ਼ ਤਦ ਹੀ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਉਸ 'ਤੇ ਭਰੋਸਾ ਕਰਦੇ ਹੋ।
ਕੁਝ ਮੁੱਖ ਚੀਜ਼ਾਂ ਸਕੈਨ ਕਰੋ:
ਜੇ ਟੋਟਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦੇ ਤਾਂ ਅਨੁਮਾਨ ਨਾ ਲਗਾਓ। ਇਕ ਬੁਕਿੰਗ ਚੁਣੋ ਅਤੇ ਉਸ ਨੂੰ ਪੂਰਨ ਤੌਰ 'ਤੇ ਟਰੇਸ ਕਰੋ: ਸੇਵਾ ਤਾਰੀਖ, ਜਮ੍ਹਾਂ, ਬਾਕੀ ਬਕਾਇਆ, ਰਿਫੰਡ।
ਆਪਣੇ ਇਤਿਹਾਸ ਦੀ ਰੱਖਿਆ ਕਰੋ ਅਤੇ ਮਹੀਨੇ-ਅੰਤ ਦੇ ਨੰਬਰ ਸਹੀ ਬਣਾਓ:
ਆਟੋਮੇਸ਼ਨ ਫਾਇਦਾ ਉਨ੍ਹਾਂ ਬਾਅਦ ਹੀ ਦਿੰਦੀ ਹੈ ਜਦੋਂ ਮੁੱਢਲੀ ਚੀਜ਼ਾਂ ਇਕਸਾਰ ਹੋ ਚੁੱਕੀਆਂ ਹੋਣ। ਜੇ ਇਕ ਆਦਮੀ "Deposit" ਲਿਖਦਾ ਹੈ ਅਤੇ ਦੂਜਾ "Retainer" ਤ
ਰਿਕਾਰਡ ਰੱਖੋ ਕਿਉਂਕਿ ਬੁਕਿੰਗ ਖਿਸਕਣ, ਗ੍ਰਾਹਕ ਰੱਦ ਕਰਨ ਜਾਂ ਸੇਵਾ ਬਦਲਣ 'ਤੇ ਰਿਫੰਡ ਅਕਸਰ ਭੁੱਲ ਜਾਂਦੇ ਹਨ। ਇੱਕ ਸਧਾਰਨ ਦਰਜਾ ਤੁਹਾਨੂੰ ਗਲਤ ਵਿਅਕਤੀ ਨੂੰ ਰਿਫੰਡ ਕਰਨ, ਜਮ੍ਹੇ ਨੂੰ ਦੋ ਵਾਰੀ ਲਗਾਉਣ ਜਾਂ ਵਾਅਦੇ ਕੀਤੇ ਰਿਫੰਡ ਨੂੰ ਮਿਸ ਕਰਨ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ।
ਨਿਊਨਤਮ ਜਾਣਕਾਰੀ ਵਿੱਚ ਗ੍ਰਾਹਕ, ਭੁਗਤਾਨ ਦਾ ਮਨਜੂਰ ਕੀਤਾ ਗਿਆ ਸੇਵਾ/ਇਨਫੋ, ਬੁਕਿੰਗ ਨਾਲ ਕੀ ਹੋਇਆ, ਅਤੇ ਕੀ ਅਤੇ ਕਦੋਂ ਰਿਫੰਡ ਦਿੱਤਾ ਗਿਆ—ਇਹ ਸਮਿਲ ਹਨ। ਜੇ ਤੁਸੀਂ ਇਹ ਤੁਰੰਤ ਨਹੀਂ ਦੱਸ ਸਕਦੇ ਤਾਂ ਬਾਅਦ ਵਿੱਚ ਕਹਾਣੀ ਦੁਬਾਰਾ ਬਣਾਉਣ ਵਿੱਚ ਸਮਾਂ ਖਰਚ ਹੋਵੇਗਾ।
ਹਰ ਕੰਮ ਲਈ ਇੱਕ ਹੀ Booking ID ਵਰਤੋ ਅਤੇ ਹਰ ਭੁਗਤਾਨ/ਰਿਫੰਡ ਨੂੰ ਉਸ ID ਨਾਲ ਜੋੜੋ। ਇਹ ਨਿਯਮ ਜ਼ਿਆਦਾਤਰ ਗਲਤੀਆਂ ਰੋਕਦਾ ਹੈ ਜਦੋਂ ਗ੍ਰਾਹਕ ਮੁੜ-ਸ਼ੈਡਿਊਲ ਕਰਦੇ ਹਨ, ਭੁਗਤਾਨ ਵੰਡਦੇ ਹਨ ਜਾਂ ਇਕੱਠੇ ਅਨੇਕ ਸੇਵਾਵਾਂ ਬੁੱਕ ਕਰਦੇ ਹਨ।
ਰਿਫੰਡ ਨੂੰ ਵੱਖਰੀਆਂ ਲੈਣ-ਦੇਣ ਵਜੋਂ ਦਰਜ ਕਰੋ—ਇੱਕ ਤਾਰੀਖ, ਰਕਮ, ਕਾਰਣ ਅਤੇ ਰੇਫਰੰਸ ਦੇ ਨਾਲ। ਮੂਲ ਭੁਗਤਾਨ ਨੂੰ ਓਵਰਰਾਈਟ ਨਾ ਕਰੋ, ਕਿਉਂਕਿ ਇਸ ਨਾਲ ਟਾਈਮਲਾਈਨ ਖੋ ਜਾਵੇਗੀ ਅਤੇ ਆਖਿਰਕਾਰ ਸਮਝਾਉਣਾ ਮੁਸ਼ਕਿਲ ਹੋਵੇਗਾ।
ਇੱਕ ਨਿਯਮ ਚੁਣੋ ਅਤੇ ਹਰ ਵਾਰੀ ਉਸੇ ਤਰੀਕੇ 'ਤੇ ਲਾਗੂ ਕਰੋ। ਜੇ ਇਹ ਇਕੋ ਕੰਮ ਹੈ ਤਾਂ ਬੁਕਿੰਗ ਤੇ ਸੇਵਾ ਦੀ ਤਾਰੀਖ ਅਪਡੇਟ ਕਰੋ ਅਤੇ ਉਸੇ Booking ID ਨੂੰ ਰੱਖੋ; ਜੇ ਖੇਤਰ ਜਾਂ ਕੀਮਤ ਇੰਨੀ ਬਦਲ ਗਈ ਕਿ ਨਵਾਂ ਕੰਮ ਬਣ ਗਿਆ ਹੈ, ਤਾਂ ਨਵਾਂ Booking ID ਬਣਾਓ ਅਤੇ ਨੋਟ ਵਿੱਚ ਪੁਰਾਣੇ ਨਾਲ ਸੰਦਰਭ ਲਿਖੋ।
ਆਪਣੀ ਨੀਤੀ ਟ੍ਰੈਕਰ ਵਿੱਚ ਲਿਖੋ ਅਤੇ ਕਦੋਂ ਗ੍ਰਾਹਕ ਨੂੰ ਦੱਸਿਆ ਗਿਆ ਸੀ ਉਸਦਾ ਨੋਟ ਲਵੋ (ਉਦਾਹਰਨ: “24 ਘੰਟਿਆਂ ਤੋਂ ਬਾਅਦ ਨਨ-ਰਿਫੰਡੇਬਲ, 2 ਮਈ ਨੂੰ ਟੈਕਸਟ ਨਾਲ ਪੁਸ਼ਟੀ”)। ਇਸ ਤਰ੍ਹਾਂ ਵਿਵਾਦ ਹੋਣ 'ਤੇ ਤੁਸੀਂ ਯਾਦ ਤੇ ਆਧਾਰ 'ਤੇ ਨਿਰਣਯ ਨਹੀਂ ਲੈ ਰਹੇ।
ਇੱਕ ਸਪੱਸ਼ਟ ਸਥਿਤੀ ਜਿਵੇਂ “Dispute” ਜੋੜੋ ਅਤੇ ਅਹਮ ਤਾਰੀਖਾਂ ਅਤੇ ਘਟਨਾਵਾਂ ਦਾ ਕਿਰਤਬੰਦਨ ਕਰੋ, ਰੋਜ਼ਾਨਾ ਰਿਫੰਡਾਂ ਤੋਂ ਅਲੱਗ। ਇਸਨੂੰ ਇੱਕ ਟਾਈਮਲਾਈਨ ਵਜੋਂ ਰੱਖੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਆਸਾਨੀ ਨਾਲ ਪਿੱਛੇ ਦੇਖ ਸਕੋ।
ਹਮੇਸ਼ਾਂ ਇੱਕੋ ਵਾਰ ਦੋ ਗਣਨਾਵਾਂ ਵਰਤੋ: Net paid = total paid - total refunded ਅਤੇ Balance due = service total - Net paid। ਜੇ ਇਹ ਦੋ ਨੰਬਰ ਸਮਝਦਾਰ ਰਹਿੰਦੇ ਹਨ ਤਾਂ ਭਾਵੇਂ ਅੰਸ਼ਕ ਰਿਫੰਡ ਹੋਣ ਜਾਂ ਭੁਗਤਾਨ ਵੰਡੇ ਜਾਣ, ਟ੍ਰੈਕਰ ਹਕੀਕਤ ਨਾਲ ਮਿਲੇਗਾ।
ਜਦੋਂ ਵੀ ਪੈਸਾ ਹਿਲਦਾ ਹੈ ਉਸ ਸਮੇਂ ਅਪਡੇਟ ਕਰੋ—ਹਫ਼ਤੇ ਦੇ ਆਖ਼ਿਰ 'ਤੇ ਨਹੀਂ। ਰੋਜ਼ਾਨਾ ਇੱਕ ਛੋਟੀ ਜਾਂਚ (ਰਿਫਰੰਸ ID ਦੇ ਲਈ) ਅਤੇ ਹਫਤਾਵਾਰੀ ਸਕੈਨ “ਰਿਫੰਡ ਵਾਅਦਾ ਕੀਤਾ” ਆਈਟਮਾਂ ਲਈ ਅਕਸਰ ਬਹੁਤ ਸਾਰੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਰੋਕ ਲੈਂਦੇ ਹਨ।
ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਸਪ੍ਰੈਡਸ਼ੀਟ ਵਰਤੋ ਜੇ ਤੁਸੀਂ ਦਰਅਸਤ ਖੋਲ੍ਹੋਗੇ; ਬਾਕੀਏ ਇਕਸਾਰ ਸ਼ਬਦਾਵਲੀ ਦੇ ਨਾਲ ਡ੍ਰੌਪਡਾਊਨ ਵਰਤੋ। ਜੇ ਕਈ ਲੋਕ ਭੁਗਤਾਨ ਲੈਂਦੇ ਹਨ ਜਾਂ ਸ਼ੀਟ ਅਪਰਾਈਗਟ ਹੋ ਜਾਂਦੀ ਹੈ ਤਾਂ ਇੱਕ ਛੋਟੀ ਇੰਟਰਨਲ ਐਪ ਜੋ ਲਾਜ਼ਮੀ ਫੀਲਡਜ਼ ਰੱਖੇ, ਗਲਤੀਆਂ ਘਟਾ ਸਕਦੀ ਹੈ—ਇੱਕ ਛੋਟੀ ਵਰਜਨ ਦੇ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, ਜਿਵੇਂ Koder.ai ਵਰਤ ਕੇ।