ਇੱਕ ਸੇਵਾਦਾਰ ਸੰਯੋਜਨ ਐਪ ਬਣਾਓ: ਸ਼ਿਫਟਾਂ, ਭੂਮਿਕਾਵਾਂ ਅਤੇ ਸੂਚਨਾਵਾਂ

ਐਪ ਨੂੰ ਕਿਹੜੀ ਸਮੱਸਿਆ ਹੱਲ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ

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

ਤੁਹਾਡੇ ਰਿਪਲੇਸ ਕਰਨ ਵਾਲੇ ਅਸਲੀ ਸਮੱਸਿਆਵਾਂ

ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ ਕੁਝ ਆਮ ਮੁੱਦਿਆਂ ਨਾਲ ਜੂਝਦੀਆਂ ਹਨ:

• ਨੋ-ਸ਼ੋ ਅਤੇ ਦੇਰ ਨਾਲ ਰੱਦੀਆਂ ਕਿਉਂਕਿ ਲੋਕ ਭੁੱਲ ਜਾਂਦੇ ਹਨ ਜਾਂ ਬਦਲਾਵ ਸਮੇਂ 'ਤੇ ਨਹੀਂ ਵੇਖ ਪਾਉਂਦੇ।
• ਆਖਰੀ-ਮਿੰਟ ਕਵਰੇਜ ਖਾਲੀ ਹੋ ਜਾਣਾ ਜਦੋਂ ਕੋਈ ਗਿਰ ਜਾਵੇ ਅਤੇ ਤੇਜ਼ੀ ਨਾਲ ਥਾਂ ਭਰਨ ਦਾ ਤਰੀਕਾ ਨਾ ਹੋਵੇ।
• Spreadsheet drift ਜਿੱਥੇ ਕਈ ਵਰਜਨ ਹੁੰਦੇ ਹਨ ਅਤੇ ਕੋਈ ਭੀ ਨਵਾਂ ਵਰਜਨ ਭਰੋਸੇਯੋਗ ਨਹੀਂ ਰਹਿੰਦਾ।
• ਅਨੰਤ ਮੈਨੂਅਲ ਸੰਦੇਸ਼ ("ਕੀ ਤੁਸੀਂ ਕਵਰ ਕਰ ਸਕਦੇ ਹੋ?" "ਕੇੜਾ ਸਮਾਂ?" "ਕਿੱਥੇ ਜਾਣਾ ਹੈ?") ਜੋ ਕੋਆਰਡੀਨੇਟਰਾਂ ਨੂੰ ਥਕਾ ਦਿੰਦਾ ਹੈ।

ਕੌਣ ਫਾਇਦਾ ਉਠਾਉਂਦਾ ਹੈ (ਅਤੇ ਕਿਵੇਂ)

ਇੱਕ ਸੇਵਾਦਾਰ ਸੰਯੋਜਨ ਐਪ ਮਦਦ ਕਰਦਾ ਹੈ:

• ਨਾਨਪ੍ਰਾਫਿਟ ਅਤੇ ਕਮਿਊਨਿਟੀ ਗਰੁੱਪ: ਪ੍ਰਸ਼ਾਸਨ ਦਾ ਸਮਾਂ ਘਟਾਉਂਦੇ ਹੋਏ ਹਾਜ਼ਰੀ ਵਿੱਚ ਸੁਧਾਰ।
• ਈਵੈਂਟ ਟੀਮਾਂ: ਸਥਾਪਨਾ, ਲਾਈਵ ਘੰਟਿਆਂ ਅਤੇ ਟੀਅਰਡਾਊਨ ਦੌਰਾਨ ਰੀਅਲ-ਟਾਈਮ ਜ਼ਰੂਰਤਾਂ ਨਾਲ ਸਟਾਫਿੰਗ ਨੂੰ ਲਾਈਨ ਕਰਨਾ।
• ਸਕੂਲ ਅਤੇ ਮਾਪੇ ਦੇ ਸੰਗਠਨ: ਸਾਈਨਅਪ ਸਧਾਰਨ ਅਤੇ ਉਮੀਦਾਂ ਸਪੱਸ਼ਟ ਕਰਨਾ।

ਸੇਵਾਦਾਰਾਂ ਲਈ ਵੀ ਫਾਇਦਾ: ਉਹ ਤੇਜ਼ੀ ਨਾਲ ਵੇਖ ਸਕਦੇ ਹਨ ਕਿ ਉਹ ਕਿਸ ਲਈ ਸਾਈਨ ਅਪ ਕੀਤੇ ਹਨ, ਕੀ ਉਪਲਬਧ ਹੈ, ਅਤੇ ਕਿੱਥੇ ਹੋਣਾ ਹੈ—ਪੁਰਾਣੇ ਸੁਨੇਹਿਆਂ ਵਿਚੋਂ ਖੋਜ ਕਰਨ ਦੇ ਬਗੈਰ।

“ਸਫ਼ਲਤਾ” ਦਿਖਣੀ ਕਿਵੇਂ ਚਾਹੀਦੀ ਹੈ

ਸਫ਼ਲਤਾ ਮਾਪਯੋਗ ਹੈ:

• ਸ਼ਿਫਟ ਪਹਿਲਾਂ ਭਰ ਜਾਂਦੀਆਂ ਹਨ ਅਤੇ ਭਰਿਆ ਰਹਿੰਦਾ ਹੈ।
• "ਸਟੇਟਸ-ਚੈਕ" ਸੰਦੇਸ਼ਾਂ ਦੀ ਗਿਣਤੀ ਘੱਟ ਹੁੰਦੀ ਕਿਉਂਕਿ ਸ਼ਡਿਊਲ ਇੱਕ ਸਿੰਗਲ ਸੋਜ਼ ਆਫ਼ ਟਰੂਥ ਹੈ।
• ਸਪੱਸ਼ਟ ਜ਼ਿੰਮੇਵਾਰੀ: ਹਰ ਕੋਈ ਜਾਣਦਾ ਹੈ ਕੌਣ ਨਿਯੁਕਤ ਹੈ, ਕਿਸ ਨੇ ਚੇਕ-ਇਨ ਕੀਤਾ, ਅਤੇ ਕਿਸ ਨੂੰ ਸੰਪਰਕ ਕਰਨਾ ਹੈ।

ਸਮਝਦਾਰ ਸ਼ੁਰੂਆਤੀ ਸਕੋਪ ਪਰਿਭਾਸ਼ਤ ਕਰੋ

ਸ਼ੁਰੂ ਕਰੋ ਸਕੇਜੂਲਿੰਗ + ਸੰਚਾਰ ਨਾਲ: ਸ਼ਿਫਟ ਪੋਸਟ ਕਰਨਾ, ਉਹਨਾਂ ਨੂੰ ਕਲੈਮ ਕਰਨਾ, ਰਿਮਾਈਂਡਰ, ਅਤੇ ਜਦੋਂ ਯੋਜਨਾਵਾਂ ਬਦਲਦੀਆਂ ਹਨ ਤਾਂ ਛੇਤੀ ਅਪਡੇਟ। ਵਾਧੂਆਂ (ਦਾਨ ਟਰੈਕਿੰਗ, ਟਰੇਨਿੰਗ ਮੌਡਿਊਲ, ਡੀਪ ਰਿਪੋਰਟਿੰਗ) ਬਾਅਦ ਵਿੱਚ ਛੱਡੋ—ਜਦਕਿ ਕੋਰ ਵਰਕਫਲੋ ਭਰੋਸੇਯੋਗ ਅਤੇ ਲਗਾਤਾਰ ਵਰਤਿਆ ਜਾ ਰਿਹਾ ਹੋਵੇ।

ਯੂਜ਼ਰ, ਰੋਲ ਅਤੇ ਹਕੀਕਤੀ ਸੀਮਾਵਾਂ

ਫੀਚਰ ਅਤੇ ਸਕ੍ਰੀਨਜ਼ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਸਪਸ਼ਟ ਕਰੋ ਕਿ ਕੌਣ ਐਪ ਵਰਤੇਗਾ ਅਤੇ ਹਰ ਵਿਅਕਤੀ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਕੀ ਹਾਸਲ ਕਰਨਾ ਹੈ—ਅਕਸਰ ਇਵੈਂਟ-ਦੇ ਦਿਨ ਦਬਾਅ ਹੇਠਾਂ।

ਯੂਜ਼ਰ ਕਿਸਮਾਂ ਜਿਸਦੀ ਯੋਜਨਾ ਬਣਾਉਣੀ ਚਾਹੀਦੀ ਹੈ

ਜ਼ਿਆਦਾਤਰ ਸੰਸਥਾਵਾਂ ਇੱਕੋ ਮੁੱਖ ਰੋਲਾਂ ਨਾਲ ਖਤਮ ਹੁੰਦੀਆਂ ਹਨ:

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

ਸ਼ੁਰੂ ਵਿੱਚ ਰੋਲ ਸਧੇ ਬਣਾਓ। ਆਮ ਪੈਟਰਨ "ਸੇਵਾਦਾਰ" ਅਤੇ ਇੱਕ ਉੱਪਰ-ਲੈਵਲ ਰੋਲ ("ਕੋਆਰਡੀਨੇਟਰ") ਹੈ, ਫਿਰ ਜੇ ਲੋੜ ਹੋਵੇ ਤਾਂ "ਸ਼ਿਫਟ ਲੀਡਰ" ਜੋੜੋ।

ਰੋਲ ਅਨੁਸਾਰ ਮੁੱਖ ਟਾਸਕ (ਐਪ ਨੂੰ ਕਿਵੇਂ ਆਸਾਨ ਬਣਾਉਣਾ)

ਸੇਵਾਦਾਰ ਆਮ ਤੌਰ 'ਤੇ ਚਾਹੁੰਦੇ ਹਨ: ਸਾਈਨਅਪ, ਕੈਲੇਂਡਰ ਵਿਊ, ਕੈਂਸਲ/ਸਵੈਪ, ਦਿਸ਼ਾ-ਨਿਰਦੇਸ਼ ਅਤੇ ਹਦਾਇਤਾਂ, ਅਤੇ ਚੇਕ-ਇਨ।

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

ਸ਼ਿਫਟ ਲੀਡਰਾਂ ਨੂੰ ਚਾਹੀਦਾ ਹੈ: ਰੋਸਟਰ, ਸੇਵਾਦਾਰ ਨਾਲ ਸੰਪਰਕ, ਹਾਜ਼ਰੀ ਨਿਸ਼ਚਿਤ ਕਰਨਾ, ਅਤੇ ਘਟਨਾਵਾਂ ਨੋਟ ਕਰਨਾ।

ਉਹ ਸੀਮਾਵਾਂ ਜਿਨ੍ਹਾਂ ਨੂੰ ਤੁਸੀਂ ਨਜ਼ਰਅੰਦਾਜ਼ ਨਹੀਂ ਕਰ ਸਕਦੇ

ਅਸਲੀ ਓਪਰੇਸ਼ਨ ਤੁਹਾਡੇ ਡਿਜ਼ਾਈਨ ਨੂੰ ਆਕਾਰ ਦਿੰਦੇ ਹਨ:

• ਸੀਮਤ ਸਟਾਫ ਸਮਾਂ: ਵਰਕਫਲੋਜ਼ ਤੇਜ਼ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ; ਡੀਫਾਲਟ ਅਤੇ ਟੈਮਪਲੇਟ ਮਹੱਤਵਪੂਰਨ ਹਨ।
• ਸੇਵਾਦਾਰ ਚਰਨ: ਹਰ ਹਫ਼ਤੇ ਨਵੇਂ ਯੂਜ਼ਰ ਆਉਣ ਦੀ ਉਮੀਦ ਕਰੋ; ਓਨਬੋਰਡਿੰਗ ਸਪੱਸ਼ਟ ਅਤੇ ਦਿਲਾਸਾ ਦਿੰਦੀਆਂ ਹੋਣ।
• ਪਹੁੰਚਯੋਗਤਾ ਦੀ ਲੋੜ: ਪਾਠਕਤਾ ਵੱਡੀ, ਟੈਪ ਟાર્ગੇਟ ਵੱਡੇ, ਅਤੇ ਘੱਟ ਟਾਈਪਿੰਗ ਅਨਿਵਾਰਯ ਹਨ।
• ਕਮਜ਼ੋਰ ਕੁਨੈਕਸ਼ਨ: ਸਥਲਾਂ 'ਤੇ ਖਰਾਬ ਰਿਸੈਪਸ਼ਨ ਲਈ ਯੋਜਨਾ—ਘੱਟੋ-ਘੱਟ ਚੇਕ-ਇਨ ਅਤੇ ਰੋਸਟਰ ਦੇਖਣਾ gracefully degrade ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।

ਪਲੇਟਫਾਰਮ: ਮੋਬਾਈਲ + ਵੈੱਬ?

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

ਆਪਣਾ MVP ਫੀਚਰ ਸੈੱਟ ਪਰਿਭਾਸ਼ਤ ਕਰੋ

ਇੱਕ ਸੇਵਾਦਾਰ ਸੰਯੋਜਨ ਐਪ ਲਈ MVP "ਹਰ ਚੀਜ਼ ਦਾ ਛੋਟਾ ਵਰਜਨ" ਨਹੀਂ ਹੈ। ਇਹ ਇੱਕ ਸਪੱਸ਼ਟ ਵਾਅਦਾ ਹੈ: ਆਯੋਜਕ ਸ਼ਿਫਟਾਂ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰ ਸਕਦੇ ਹਨ, ਸੇਵਾਦਾਰ ਉਹਨਾਂ ਨੂੰ ਕਲੇਮ ਕਰ ਸਕਦੇ ਹਨ, ਅਤੇ ਸਭ ਨੂੰ ਸਹੀ ਸਮੇਂ ਰਿਮਾਈਂਡਰ ਮਿਲਦੇ ਹਨ।

MVP ਲਕੜੀ ਤੇ ਧਿਆਨ ਰੱਖੋ

ਪਹਿਲੀ ਰਿਲੀਜ਼ ਲਈ ਇੱਕ end-to-end ਲੂਪ ਨੂੰ ਪ੍ਰਾਥਮਿਕਤਾ ਦਿਓ:

• ਸ਼ਿਫਟ ਬਣਾਓ (ਤਾਰੀਖ, ਸਮਾਂ, ਟਿਕਾਣਾ, ਭੂਮਿਕਾ, ਸੀਟਾਂ ਦੀ ਗਿਣਤੀ)
• ਯੋਗ ਸੇਵਾਦਾਰਾਂ ਨੂੰ ਸ਼ਿਫਟ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰੋ
• ਸੇਵਾਦਾਰ ਇੱਕ ਸਥਾਨ ਕਲੇਮ (ਅਤੇ ਅਨਕਲੇਮ) ਕਰ ਸਕਣ
• ਪੁਸ਼ਟਿਕਰਨ ਅਤੇ ਰਿਮਾਈਂਡਰ ਭੇਜੋ (ਜਿਵੇਂ 24 ਘੰਟੇ ਅਤੇ 2 ਘੰਟੇ ਪਹਿਲਾਂ)

ਜੇ ਤੁਹਾਡਾ MVP ਸਿਰਫ ਇਹ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਕਰਦਾ ਹੈ, ਤਾਂ ਇਹ ਅਸਲ ਇਵੈਂਟਸ ਲਈ ਵੀ ਫਾਇਦੇਮੰਦ ਹੈ।

ਲਾਜ਼ਮੀ বনਾਮ ਚੰਗਾ-ਹੋਣ ਵਾਲਾ

ਆਮ ਨਿਯਮ: ਜੇ ਕੋਈ ਫੀਚਰ ਸ਼ਿਫਟ ਨੂੰ ਸਟਾਫ ਕਰਨ ਤੋਂ ਰੋਕਦਾ ਨਹੀਂ, ਤਾਂ ਇਹ ਸ਼ਾਇਦ v1 ਲਈ ਲਾਜ਼ਮੀ ਨਹੀਂ।

ਲਾਜ਼ਮੀ ਉਦਾਹਰਣਾਂ:

• ਉਪਲਬਧਤਾ ਕੈਪਚਰ (ਇੱਕ ਸਰਲ "ਮੈਂ ਹਫ਼ਤੇ ਦੇ ਅੰਤ ਤੇ ਖਾਲੀ ਹਾਂ")
• ਰਿਕਰਿੰਗ ਸ਼ਿਫਟ (ਹਫਤੇਵਾਰ/ਮਹੀਨਾਵਾਰ) ਜਾਂ ਸਿੰਗਲ-ਡੇਟ ਸ਼ਿਫਟ—ਆਪਣੇ ਵਰਕਫਲੋ ਦੇ ਆਧਾਰ ਤੇ ਚੁਣੋ
• ਬੁਨਿਆਦੀ ਐਡਮਿਨ ਵਿਊ: ਕੌਣ ਕਿਨ੍ਹਾਂ ਨੇ ਕਲੇਮ ਕੀਤਾ ਅਤੇ ਕਿੰਨੀ ਥਾਂ ਬਚੀ ਹੈ

ਚੰਗੇ-ਹੋਣ ਵਾਲੇ (بعد ਵਿੱਚ ਮਿਲਾਉਣ ਯੋਗ, ਪਹਿਲਾਂ ਖ਼ਤਰਾ): ਵੈਟਲਿਸਟ, ਘੰਟਾ ਟਰੈਕਿੰਗ/ਵਾਲੰਟੀਅਰ ਘੰਟੇ, ਪਿਛੋਕੜ ਚੈੱਕ, ਇਨ-ਐਪ ਚੈਟ, ਉੱਨਤ ਰਿਪੋਰਟਿੰਗ, ਜਟਿਲ ਮਨਜ਼ੂਰੀ ਚੇਨ।

ਇੱਕ ਪ੍ਰਾਇਮਰੀ ਵਰਕਫਲੋ ਚੁਣੋ

ਤੈਅ ਕਰੋ ਕਿ ਤੁਸੀਂ ਕਿਸ ਲਈ optimize ਕਰ ਰਹੇ ਹੋ:

• ਇਕ-ਇਵੈਂਟ: ਤੇਜ਼ ਸਾਈਨ-ਅਪ, ਸਪੱਸ਼ਟ ਸ਼ਿਫਟ ਰੋਸਟਰ, ਭਾਰੀ ਰਿਮਾਈਂਡਰ ਉਪਯੋਗ
• ਲਗਾਤਾਰ ਪ੍ਰੋਗਰਾਮ: ਰਿਕਰਿੰਗ ਸ਼ਿਫਟ, ਸੇਵਾਦਾਰ ਪ੍ਰੋਫਾਈਲ, ਲੰਬੀ ਮਿਆਦ ਦੀ ਉਪਲਬਧਤਾ

ਬਹੁਤ جلد ਦੋਹਾਂ ਨੂੰ ਮਿਲਾਉਣਾ ਅਕਸਰ ਗੁੰਝਲਦਾਰ ਸਕਰੀਨਾਂ ਅਤੇ ਏਡਜ-ਕੇਸ ਬਣਾਉਂਦਾ ਹੈ।

ਡਿਜ਼ਾਈਨ ਤੋਂ ਪਹਿਲਾਂ ਐਕਸੇਪਟੰਸ ਕਰਾਈਟੇਰੀਆ ਲਿਖੋ

5–10 ਸਪੱਸ਼ਟ-ਭਾਸ਼ਾ ਚੈੱਕ ਪਰਿਭਾਸ਼ਤ ਕਰੋ, ਜਿਵੇਂ:

• ਆਯੋਜਕ ਸਮਰੱਥਾ ਨਾਲ ਇੱਕ ਸ਼ਿਫਟ ਬਣਾਕੇ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰ ਸਕਦੇ ਹਨ (ਜਿਵੇਂ 5 ਸਥਾਨ)
• ਸੇਵਾਦਾਰ ਇੱਕ ਸਥਾਨ ਕਲੇਮ ਕਰ ਸਕਦੇ ਹਨ ਅਤੇ ਤੁਰੰਤ "ਮੇਰੀਆਂ ਸ਼ਿਫਟਾਂ" ਵਿੱਚ ਦੇਖ ਸਕਦੇ ਹਨ
• ਜਦੋਂ ਸਮਰੱਥਾ ਭਰ ਜਾਵੇ, ਹੋਰ ਸੇਵਾਦਾਰ ਕਲੇਮ ਨਹੀਂ ਕਰ ਸਕਦੇ
• ਸੇਵਾਦਾਰੋਂ ਨੂੰ ਪੁਸ਼ਟੀਕਰਨ ਅਤੇ ਨਿਰਧਾਰਿਤ ਸਮੇਂ 'ਤੇ ਰਿਮਾਈਂਡਰ ਮਿਲਦੇ ਹਨ
• ਆਯੋਜਕ ਸ਼ਿਫਟ ਰੱਦ ਕਰ ਸਕਦੇ ਹਨ ਅਤੇ ਸਾਰੇ ਕਲੇਮ ਕੀਤੇ ਸੇਵਾਦਾਰਾਂ ਨੂੰ ਸੂਚਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ

ਇਹ ਮਾਪਦੰਡ ਤੁਹਾਡੇ MVP ਨੂੰ ਫੋਕਸ ਵਿੱਚ ਰੱਖਦੇ ਹਨ ਅਤੇ "ਕਿਆ ਹੋਇਆ ਹੈ" ਨੂੰ ਮਾਪਯੋਗ ਬਣਾਉਂਦੇ ਹਨ।

ਮੁੱਖ ਸਕੇਜੂਲਿੰਗ ਅਤੇ ਸ਼ਿਫਟ ਲੌਜਿਕ

ਸਕੇਜੂਲਿੰਗ ਇੱਕ ਸੇਵਾਦਾਰ ਸੰਯੋਜਨ ਐਪ ਦੀ ਇੰਜਣ ਹੈ। ਜੇ ਨਿਯਮ ਅਸਪਸ਼ਟ ਹਨ, ਤਾਂ ਬਾਕੀ ਸਭ—ਨੋਟੀਫਿਕੇਸ਼ਨ, ਹਾਜ਼ਰੀ, ਰਿਪੋਰਟਿੰਗ—ਅਣਵਿੰਚਿਤ ਮਹਿਸੂਸ ਹੋਵੇਗਾ।

ਸ਼ਿਫਟ ਲਾਈਫਸਾਇਕਲ (ਸਥਿਤੀ ਮਾਡਲ)

ਹਰ ਸ਼ਿਫਟ ਨੂੰ ਇੱਕ ਸਧਾਰਨ, ਸਪੱਸ਼ਟ ਲਾਈਫਸਾਇਕਲ ਵਿੱਚ ਅੱਗੇ ਵਧਦੇ ਹੋਏ ਤਰ੍ਹਾਂ ਸੋਚੋ:

• Draft: ਕੇਵਲ ਕੋਆਰਡੀਨੇਟਰਾਂ ਲਈ ਦਿੱਸਦਾ ਹੈ; ਵੇਰਵੇ ਆਜ਼ਾਦੀ ਨਾਲ ਬਦਲੇ ਜਾ ਸਕਦੇ ਹਨ।
• Published: ਯੋਗ ਸੇਵਾਦਾਰਾਂ ਲਈ ਦਿੱਸਦਾ ਹੈ; ਕਲੇਮ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।
• Filled: ਸਮਰੱਥਾ ਪੂਰੀ ਹੋ ਗਈ (ਜਾਂ ਕੋਆਰਡੀਨੇਟਰ ਨੇ ਹੱਥੋਂ ਬੰਦ ਕੀਤਾ); ਫਿਰ ਵੀ ਦਿੱਸਦਾ ਹੈ ਪਰ ਕਲੇਮ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ।
• Completed: ਸ਼ਿਫਟ ਹੋ ਚੁਕੀ ਹੈ; ਚੇਕ-ਇਨ/ਆਊਟ ਨੂੰ ਅੰਤਿਮ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।
• Archived: ਦਿਨ-ਪਰ-ਦਿਨ ਵਿਊਜ਼ ਤੋਂ ਲੁਕਿਆ ਹੋਇਆ ਪਰ ਇਤਿਹਾਸ ਅਤੇ ਰਿਪੋਰਟਿੰਗ ਲਈ ਰੱਖਿਆ ਰਿਹਾ।

ਇਹ ਸਥਿਤੀਆਂ ਨਿਯਮ ਲਾਗੂ ਕਰਨਾ ਆਸਾਨ ਬਣਾਉਂਦੀਆਂ ਹਨ (ਉਦਾਹਰਣ ਲਈ, ਜਦੋਂ ਸ਼ਿਫਟ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਕਿਸੇ ਕੱਟ-ਆਫ਼ ਵਿਚ ਹੋਵੇ ਤਾਂ ਸਮਾਂ ਬਦਲਣਾ ਰੋਕੋ)।

ਸੇਵਾਦਾਰ ਫਲੋ: ਖੋਜ → ਕਲੇਮ → ਪੁਸ਼ਟੀ → ਰਿਮਾਈਂਡਰ

ਸੇਵਾਦਾਰਾਂ ਨੂੰ ਯੋਗਤਾ ਨਾਲ:

1. ਸ਼ਿਫਟ ਖੋਜਣੀ ਚਾਹੀਦੀ ਹੈ ਸਪੱਸ਼ਟ ਕੈਲੇਂਡਰ/ਲਿਸਟ ਦੁਆਰਾ।
2. ਫਿਲਟਰ ਕਰ ਸਕਣ (ਤਾਰੀਖ, ਟਿਕਾਣਾ, ਭੂਮਿਕਾ, ਕਾਰਨ, ਲੋੜੀਂਦੇ ਹੁਨਰ)।
3. ਕਲੇਮ ਕਰਨਾ, ਤੁਰੰਤ ਵੈਧਤਾ (ਯੋਗਤਾ, ਸਮਰੱਥਾ, ਟੱਕਰ) ਦੀ ਜਾਂਚ ਨਾਲ।
4. ਪੁਸ਼ਟੀ ਆਪਣੀ ਵਚਨਬੱਧਤਾ (ਖਾਸ ਕਰਕੇ ਉੱਚ-ਪ੍ਰਭਾਵ ਵਾਲੀਆਂ ਸ਼ਿਫਟਾਂ ਲਈ)।

ਫਿਰ ਐਪ ਆਪਣੇ ਆਪ ਰਿਮਾਈਂਡਰ ਸੈਡਿਊਲ ਕਰਦਾ ਹੈ (ਜਿਵੇਂ 24 ਘੰਟੇ ਅਤੇ 2 ਘੰਟੇ ਪਹਿਲਾਂ), ਨਾਲ ਹੀ "ਕੈਲੰਡਰ ਵਿੱਚ ਸ਼ਾਮਲ ਕਰੋ" ਵਿਕਲਪ।

ਕੋਆਰਡੀਨੇਟਰ ਫਲੋ: ਟੈਮਪਲੇਟ, ਰੱਦ, ਐਮਰਜੇੰਸੀ

ਕੋਆਰਡੀਨੇਟਰਾਂ ਨੂੰ ਤੇਜ਼ੀ ਅਤੇ ਇੱਕਸਾਰਤਾ ਚਾਹੀਦੀ ਹੈ:

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

ਉਹ ਏਡਜ-ਕੇਸ ਜਿਹੜੇ ਤੁਸੀਂ ਪਹਿਲਾਂ ਫ਼ੈਸਲਾ ਕਰੋ

ਕੁਝ ਨਿਯਮ ਉਲਝਣ ਰੋਕਦੇ ਹਨ:

• ਡਬਲ-ਬੁਕਿੰਗ: ਓਵਰਲੈਪਿੰਗ ਕਲੇਮ ਰੋਕੋ (ਕੋਆਰਡੀਨੇਟਰ ਲਈ ਓਵਰਰਾਈਡ ਦੇ ਨਾਲ)
• ਨਿਊਨਤਮ ਉਮਰ/ਹੁਨਰ: ਕਲੇਮ ਸਮੇਂ ਸੰਬੰਧੀ ਯੋਗਤਾ ਲਾਗੂ ਕਰੋ, ਬਾਅਦ 'ਚ ਨਹੀਂ
• ਮੈਕਸ ਸਮਰੱਥਾ: ਵੈਟਲਿਸਟ ਜਾਂ ਭਰ ਜਾਣ 'ਤੇ ਆਟੋ-ਕਲੋਜ਼ ਦਾ ਸਮਰਥਨ
• ਕੱਟ-ਆਫ਼ ਸਮੇਂ: ਸ਼ੁਰੂ ਹੋਣ ਲਈ X ਘੰਟੇ ਪਹਿਲਾਂ ਕਲੇਮ ਰੋਕੋ, ਜਾਂ ਕੱਟ-ਆਫ਼ ਦੌਰਾਨ ਕੋਆਰਡੀਨੇਟਰ ਮਨਜ਼ੂਰੀ ਲੋੜੀਏ

ਸਪੱਸ਼ਟ ਸਕੇਜੂਲਿੰਗ ਲੌਜਿਕ ਸਹਾਇਤਾ ਕਰਦੀ ਹੈ ਕਿ "ਕਲੇਮ ਕੀਤਾ" ਅਸਲ ਵਿੱਚ "ਤੁਸੀਂ ਆਉਣ ਦੀ ਉਮੀਦ ਰੱਖੋ" ਨੂੰ ਦਰਸਾਵੇ।

UX ਫਲੋਜ਼ ਅਤੇ ਸਕ੍ਰੀਨ ਮੈਪ

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

ਕੋਰ ਸਕ੍ਰੀਨ (ਅਤੇ ਹਰ ਇੱਕ ਦੇ ਕੀ ਕਾਰਜ ਹੋਣੇ ਚਾਹੀਦੇ)

Home ਨੂੰ ਨਿੱਜੀ ਡੈਸ਼ਬੋਰਡ ਵਾਂਗ ਕੰਮ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ: ਅਗਲੀ ਸ਼ਿਫਟ, ਤੇਜ਼ ਕਾਰਵਾਈਆਂ (ਚੇਕ-ਇਨ, ਕੋਆਰਡੀਨੇਟਰ ਨੂੰ ਸੰਦੇਸ਼), ਅਤੇ ਕੋਈ ਤੁਰੰਤ ਅਲਰਟ (ਸ਼ਿਫਟ ਬਦਲ ਗਿਆ, ਨਵੀਂ ਨਿਯੁਕਤੀ)।

Shift List ਮੁੱਖ ਬ੍ਰਾਊਜ਼ਿੰਗ ਸਤਹ ਹੈ। ਤੇਜ਼ ਫਿਲਟਰ ਸ਼ਾਮਲ ਕਰੋ: ਤਾਰੀਖ, ਟਿਕਾਣਾ, ਭੂਮਿਕਾ, ਅਤੇ "ਮੇਰੀ ਉਪਲਬਧਤਾ ਲਈ ਫਿੱਟ"। ਮੁੱਖ ਜਾਣਕਾਰੀਆਂ ਇੱਕ ਨਜ਼ਰ ਵਿੱਚ ਦਿਖਾਓ: ਸ਼ੁਰੂ/ਅੰਤ ਸਮਾਂ, ਭੂਮਿਕਾ, ਬਚੀਆਂ ਹੋਈਆਂ ਸਥਾਨ, ਅਤੇ ਦੂਰੀ ਜੇ ਲਾਗੂ ਹੁੰਦੀ ਹੈ।

Shift Detail ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਫੈਸਲੇ ਹੁੰਦੇ ਹਨ। ਇਸ ਵਿੱਚ ਜ਼ਿੰਮੇਵਾਰੀਆਂ, ਮਿਲਣ ਦਾ ਬਿੰਦੂ, ਸੰਪਰਕ ਵਿਅਕਤੀ, ਲਿਆਉਣ ਵਾਲੀਆਂ ਚੀਜ਼ਾਂ, ਅਤੇ ਇੱਕ ਸਪਸ਼ਟ ਪ੍ਰਾਇਮਰੀ ਬਟਨ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਸਥਿਤੀ ਦੇ ਨਾਲ ਬਦਲਦਾ ਹੈ: Sign up → Cancel → Checked in.

Calendar ਸੇਵਾਦਾਰਾਂ ਨੂੰ ਹਫ਼ਤਾਵਾਰ ਪੈਟਰਨ ਸਮਝਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ। ਇਸਨੂੰ ਉਸੇ ਸ਼ਿਫਟਸ ਦਾ ਵਿਰੋਧੀ ਦਰਸ਼ਨ ਬਣਾਓ (ਨਵਾਂ ਸ਼ਡਿਊਲਿੰਗ ਸਿਸਟਮ ਨਾ ਬਣਾਓ)।

Profile ਉਹ ਜਗ੍ਹਾ ਹੈ ਜਿੱਥੇ ਸੇਵਾਦਾਰ ਉਪਲਬਧਤਾ, ਪREFERੰਸਾਂ, ਅਤੇ ਬੁਨਿਆਦੀ ਜਾਣਕਾਰੀ ਜਿਵੇਂ ਐਮਰਜੈਂਸੀ ਸੰਪਰਕ ਸੰਭਾਲਦੇ ਹਨ। ਸੋਧਾਂ ਸਧਾਰਨ ਰੱਖੋ ਅਤੇ ਬਦਲਾਵਾਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ।

Messages ਕੋਆਰਡੀਨੇਸ਼ਨ 'ਤੇ ਕੇਂਦ੍ਰਿਤ ਹੋਣ ਚਾਹੀਦੇ ਹਨ: ਕੋਆਰਡੀਨੇਟਰ ਨਾਲ ਇਕ-ਉੱਤੇ-ਇੱਕ ਅਤੇ ਪ੍ਰਤੀ ਇਵੈਂਟ ਜਾਂ ਟੀਮ ਇੱਕ-ਗਰੁੱਪ ਥ੍ਰੈੱਡ।

ਉਪਲਬਧਤਾ ਆਸਾਨ ਬਣਾਓ (ਤਾਕਿ ਸਕੇਜੂਲਿੰਗ ਥਕਾਵਟ ਨਾ ਹੋਵੇ)

ਉਪਲਬਧਤਾ ਇੰਪੁਟ ਟੈਕਸਟ ਕਰਨ ਨਾਲ ਵੀ ਤੇਜ਼ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ:

• ਰਿਕਰਿੰਗ ਉਪਲਬਧਤਾ (ਉਦਾਹਰਣ: "ਮੰਗਲਵਾਰ 6–9pm") ਇੱਕ ਸਧਾਰਨ ਹਫਤਾਵਾਰ ਗਰਿਡ ਨਾਲ
• ਬਲੈਕਆਊਟ ਤਰੀਖਾਂ ਛੁੱਟੀਆਂ ਅਤੇ ਤੁਲਣਾ ਲਈ
• ਪREFERੰਸ ਰੋਲ ਤਾਂ ਜੋ ਗਲਤ-ਮੈਚ ਅਤੇ ਆਖਰੀ-ਮਿੰਟ ਸਵੈਪ ਘਟ ਸਕੇ

ਪਹੁੰਚਯੋਗਤਾ ਮਹੱਤਵਪੂਰਣ ਜੋ ਡ੍ਰੌਪ-ਆਫ਼ ਰੋਕੇ

ਥੱਕੇ ਹੋਏ ਅੰਗੂਠਿਆਂ ਅਤੇ ਬਾਹਰਲੇ ਰੋਸ਼ਨੀ ਹਾਲਾਤ ਦੇ ਲਈ ਡਿਜ਼ਾਈਨ ਕਰੋ:

• ਵੱਡੇ ਟੈਪ ਟਾਰਗੇਟ ਅਤੇ ਸਪੱਸ਼ਟ, ਲਗਾਤਾਰ ਬਟਨ
• ਪਾਠਕਤਾ-ਯੋਗ ਕਾਂਟਰਾਸਟ ਅਤੇ ਫ਼ੌਂਟ ਆਕਾਰ (ਛੋਟੀ ਸੈਕਿੰਡਰੀ ਟੈਕਸਟ ਤੋਂ ਬਚੋ)
• ਸਧਾਰਣ ਭਾਸ਼ਾ ("Sign up", "Cancel", "Directions") ਜਿਸ ਨਾਲ ਜਾਰਗਨ ਤੋਂ ਬਚਿਆ ਜਾ ਸਕੇ

ਅਫਲਾਈਨ-ਮਿੱਤਰ ਮੋਮੈਂਟ (ਖਾਸ ਕਰਕੇ ਚੇਕ-ਇਨ ਲਈ)

ਈਵੈਂਟਾਂ ਵਿੱਚ ਅਕਸਰ ਖਰਾਬ ਰਿਸੈਪਸ਼ਨ ਹੁੰਦੀ ਹੈ। ਚੇਕ-ਇਨ-ਸਬੰਧੀ ਕਾਰਵਾਈਆਂ ਲਈ ਇੱਕ ਅਫਲਾਈਨ ਰਾਹ ਯੋਜੋ: ਸਕੈਨਜ਼ ਜਾਂ ਟੈਪ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਸੇਵ ਕਰੋ, "queued to sync" ਸਥਿਤੀ ਦਿਖਾਓ, ਅਤੇ ਜਦੋਂ ਡਿਵਾਈਸ ਦੁਬਾਰਾ ਜੁੜੇ ਤਾਂ ਬਿਨਾਂ ਯੂਜ਼ਰ ਤੋਂ ਮੰਗੇ ਆਟੋ-ਸਿੰਕ ਕਰੋ।

ਡੇਟਾ ਮਾਡਲ: ਤੁਹਾਨੂੰ ਕੀ ਸਟੋਰ ਕਰਨ ਦੀ ਲੋੜ ਹੈ

ਇੱਕ ਸਪੱਸ਼ਟ ਡੇਟਾ ਮਾਡਲ ਸਕੇਜੂਲਿੰਗ ਨੂੰ ਸਹੀ, ਨੋਟੀਫਿਕੇਸ਼ਨ ਭਰੋਸੇਯੋਗ, ਅਤੇ ਰਿਪੋਰਟਿੰਗ ਸੁਗਮ ਰੱਖਦਾ ਹੈ। ਤੁਹਾਨੂੰ ਪਹਿਲੇ ਦਿਨ ਸੈਂਕੜੇ ਟੇਬਲਾਂ ਦੀ ਲੋੜ ਨਹੀਂ—ਪਰ ਤੁਹਾਨੂੰ ਕੁਝ ਮੁੱਖ ਰਿਕਾਰਡ ਅਤੇ ਕੁਝ ਖੇਤਰ ਚਾਹੀਦੇ ਹਨ ਜੋ ਅਸਲੀ-ਦੁਨੀਆ ਦੀਆਂ ਗਲਤੀਆਂ ਰੋਕਣ।

ਮੁੱਖ ਐੰਟਿਟੀਜ਼ (ਬਿਲਡਿੰਗ ਬਲਾਕ)

ਸ਼ੁਰੂਾਤ ਲਈ ਇਹ ਜ਼ਰੂਰੀ ਹਨ:

• Users (ਸੇਵਾਦਾਰ, ਕੋਆਰਡੀਨੇਟਰ, ਐਡਮਿਨ)
• Organizations (ਇੱਕ ਨਾਨ-ਪ੍ਰਾਫਿਟ ਜਾਂ ਪ੍ਰੋਗਰਾਮ; ਜੇ ਤੁਸੀਂ ਕਈ ਗਰੁੱਪ ਸਪੋਰਟ ਕਰੋਂਗੇ ਤਾਂ ਲਾਭਦਾਇਕ)
• Locations (ਐਡਰੈੱਸ, ਕਮਰਾ, ਮਿਲਣ-ਬਿੰਦੂ, ਅੌਪਸ਼ਨਲ ਜੀਓ ਇਨਫੋ)
• Roles (ਜਿਵੇਂ "Check-in desk", "Setup crew", "Team lead")
• Shifts (ਟਾਈਮ ਬਲਾਕ ਜੋ ਇੱਕ ਲੋਕੇਸ਼ਨ ਅਤੇ ਰੋਲ ਨਾਲ ਜੁੜਿਆ ਹੋਵੇ)
• Signups (ਇੱਕ ਯੂਜ਼ਰ ਦੀ ਕਿਸੇ ਵਿਸ਼ੇਸ਼ ਸ਼ਿਫਟ ਲਈ ਵਚਨਬੱਧਤਾ)

ਇਸ ਵੰਡ ਦਾ ਮਤਲਬ: ਇੱਕ Shift ਮੌਜੂਦ ਰਹਿ ਸਕਦਾ ਹੈ ਭਾਵੇਂ ਕਿਸੇ ਨੇ ਸਾਈਨਅਪ ਨਾ ਕੀਤਾ ਹੋਵੇ, ਅਤੇ ਇੱਕ Signup ਨੂੰ ਰੱਦ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਬਿਨਾਂ ਸ਼ਿਫਟ ਨੂੰ ਹਟਾਏ।

ਸਕੇਜੂਲਿੰਗ ਮੁਦਿਆਂ ਤੋਂ ਬਚਾਉਣ ਵਾਲੇ ਖੇਤਰ

ਘੱਟੋ-ਘੱਟ, ਹਰ ਸ਼ਿਫਟ ਵਿੱਚ ਇਹ ਰੱਖੋ:

• ਸ਼ੁਰੂ ਸਮਾਂ, ਅੰਤ ਸਮਾਂ, ਅਤੇ ਟਾਈਮਜ਼ੋਨ (ਟਾਈਮਜ਼ੋਨ "ਇੱਕ ਘੰਟਾ ਹਿਲ ਗਿਆ" ਵਾਲੀ ਗਲਤਫਹਮੀ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ)
• ਸਮਰੱਥਾ (ਕਿੰਨੇ ਸੇਵਾਦਾਰਾਂ ਦੀ ਲੋੜ)
• ਲੋੜੀਂਦੇ ਹੁਨਰ / ਸ਼ਰਤਾਂ (ਭਾਸ਼ਾ, ਸਰਟੀਫਿਕੇਸ਼ਨ, ਉਮਰ ਮਿੰਨੀਮਮ ਆਦਿ)
• ਸਥਿਤੀ (draft, published, canceled)

ਸਾਈਨਅਪ ਲਈ ਸ਼ਾਮਲ ਕਰੋ signup status (confirmed, waitlisted, canceled) ਅਤੇ ਟਾਈਮਸਟੈਂਪ।

ਆਡਿਟ ਇਤਿਹਾਸ ("ਕਿਸਨੇ ਇਹ ਬਦਲਿਆ?")

Shifts ਅਤੇ Signups 'ਤੇ created_by, updated_by, canceled_by ਅਤੇ ਸਮੇਂ ਦੇ ਟਾਈਮਸਟੈਂਪ ਟਰੈਕ ਕਰੋ। ਇਹ ਜ਼ਿੰਮੇਵਾਰੀ ਸਮਰਥਨ ਕਰਦਾ ਹੈ ਅਤੇ ਵਿਵਾਦ ਸੁਲਝਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ।

ਰਿਪੋਰਟਿੰਗ-ਤਿਆਰ ਡੇਟਾ

ਜੇ ਤੁਸੀਂ ਪ੍ਰਭਾਵ-ਰਿਪੋਰਟ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂattendance ਵੇਰਵਿਆਂ ਨੂੰ ਪ੍ਰਤੀ-ਸਾਈਨਅਪ ਸਟੋਰ ਕਰੋ:

• Attendance status (attended, no-show, excused, late)
• Check-in/check-out times ਅਤੇ ਸੇਵਾਏਂ ਘੰਟੇ
• ਰੱਦ ਕਰਨ ਦਾ ਕਾਰਨ (ਸੇਵਾਦਾਰ ਰੱਦ ਕੀਤਾ, ਕੋਆਰਡੀਨੇਟਰ ਰੱਦ ਕੀਤਾ, ਮੌਸਮ ਆਦਿ)

ਇਹ ਖੇਤਰ ਸਧਾਰਨ ਰਿਪੋਰਟਿੰਗ ਨੂੰ ਭਰੋਸੇਯੋਗ ਬਣਾਉਂਦੇ ਹਨ।

ਪ੍ਰਮਾਣੀਕਰਨ ਅਤੇ ਅਧਿਕਾਰ

ਪ੍ਰਮਾਣੀਕਰਨ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਸਹੂਲਤ ਅਤੇ ਨਿਯੰਤਰਣ ਮਿਲਦੇ ਹਨ। ਸੇਵਾਦਾਰ ਇੱਕ ਤੇਜ਼ ਸਾਈਨ-ਇਨ ਚਾਹੁੰਦੇ ਹਨ; ਕੋਆਰਡੀਨੇਟਰ ਅਤੇ ਐਡਮਿਨ ਨੂੰ ਯਕੀਨ ਚਾਹੀਦਾ ਹੈ ਕਿ ਸਹੀ ਲੋਕ ਹੀ ਸਹੀ ਚੀਜ਼ ਵੇਖ/ਸੰਪਾਦਨ ਕਰ ਸਕਦੇ ਹਨ।

ਪ੍ਰਮਾਣੀਕਰਨ ਵਿਕਲਪ (ਆਪਣੇ ਦਰਸ਼ਕ ਅਨੁਸਾਰ ਚੁਣੋ)

ਜ਼ਿਆਦਾਤਰ ਨਾਨਪ੍ਰਾਫਿਟ ਟੀਮਾਂ ਲਈ, ਸਧਾਰਨ ਰਾਹ ਚੁਣੋ ਅਤੇ friction ਘਟਾਓ:

• ਈਮੇਲ + ਇਕ-ਵਾਰੀ ਕੋਡ: "ਈਮੇਲ ਵਿੱਚ ਆਇਆ ਕੋਡ ਟਾਈਪ ਕਰੋ" ਫਲੋ ਸੌਖਾ ਹੈ ਅਤੇ ਪਾਸਵਰਡ ਥੱਕਾਵਟ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ।
• Passwordless magic links: ਈਮੇਲ ਤੋਂ ਇਕ-ਟੈਪ ਸਾਈਨ-ਇਨ। ਮੋਬਾਈਲ 'ਤੇ ਵਧੀਆ, ਪਰ ਸਾਂਝੇ ਇਨਬੌਕਸ ਵਰਤਣ ਵਾਲਿਆਂ ਲਈ ਸਾਵਧਾਨ ਰਹੋ।
• SSO (Google/Microsoft/Okta) ਵੱਡੀਆਂ ਸੰਸਥਾਵਾਂ ਲਈ: ਜਦੋਂ ਸਟਾਫ ਕੋਰਪੋਰੇਟ ਆਈਡੈਂਟੀਟੀ ਪ੍ਰਦਾਤਾ ਵਰਤਦਾ ਹੋਵੇ; ਵਿਕਲਪਕ ਰੱਖੋ ਤਾਂ ਜੋ ਸੇਵਾਦਾਰ ਮਜ਼ਬੂਰ ਨਾ ਹੋਣ।

ਇੱਕ ਹਿੱਕ-ਅਮਲ MVP ਦ੍ਰਿਸ਼ਟੀ: ਪਹਿਲਾਂ ਈਮੇਲ + ਕੋਡ ਸਹਾਇਤ ਕਰੋ, ਅਤੇ backend ਇੰਝ ਡਿਜ਼ਾਈਨ ਕਰੋ ਕਿ SSO ਬਾਅਦ ਵਿੱਚ ਜੋੜਿਆ ਜਾ ਸਕੇ।

ਰੋਲ-ਆਧਾਰਿਤ ਅਧਿਕਾਰ (ਹਰ ਰੋਲ ਕੀ ਕਰ ਸਕਦਾ)

ਸ਼ੁਰੂ ਵਿੱਚ ਅਧਿਕਾਰ ਪਰਿਭਾਸ਼ਤ ਕਰੋ ਤਾਂ ਕਿ ਬਾਅਦ ਵਿੱਚ ਏਡਜ-ਕੇਸ ਨਹੀਂ ਬਣਦੇ:

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

ਅਧਿਕਾਰ ਸਰਵਰ-ਪੱਖ ਤੇ ਲਾਗੂ ਕਰੋ (UI 'ਤੇ ਕੇਵਲ ਨਹੀਂ) ਤਾਂ ਜੋ ਕੋਈ ਕੌਤੁਕ ਯੂਜ਼ਰ ਐਪ ਨੂੰ ਹੱਕ ਨਾਲ ਟਵਿਕ ਕਰਕੇ ਕੋਆਰਡੀਨੇਟਰ ਟੂਲ ਨੂੰ ਨਾ ਵੇਖ ਸਕੇ।

ਬਹੁ-ਓਰਗਨਾਈਜੇਸ਼ਨ ਸਹਾਇਤਾ: "ਪਹਿਲਾਂ ਇੱਕ ਆਰਗ, ਬਾਅਦ ਵਿੱਚ ਵਧਾਉਣਾ"

ਜੇਕਰ ਤੁਸੀਂ ਹੁਣ ਇੱਕ ਆਰਗਨਾਈਜੇਸ਼ਨ ਲਈ ਲਾਂਚ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਫਿਰ ਵੀ ਡੇਟਾ ਨੂੰ ਇੱਕ Organization ID ਨਾਲ ਸਟੋਰ ਕਰੋ। ਇਹ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ:

• ਯੂਜ਼ਰ ਕਈ ਓਰਗਾਂ ਨਾਲ ਵੋਲੰਟੀਅਰ ਕਰ ਸਕਦੇ ਹਨ
• ਕੋਆਰਡੀਨੇਟਰ ਚੈਪਟਰਾਂ ਦੇ ਪਾਰ ਕੰਮ ਕਰ ਸਕਦੇ ਹਨ
• ਹਰ ਆਰਗ ਲਈ ਵੱਖ-ਵੱਖ ਸੈਟਿੰਗ, ਟੈਮਪਲੇਟ, ਅਤੇ ਮੈਸੇਜਿੰਗ ਹੋ ਸਕਦੀ ਹੈ

ਅਕਾਊਂਟ ਰੀਕਵਰੀ ਅਤੇ ਡੁਪਲਿਕੇਟ ਅਕੌਂਟ

ਅਸਲੀ ਦੁਨੀਆ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਲਈ ਯੋਜਨਾ ਬਣਾਓ: ਲੋਕ ਈਮੇਲ ਬਦਲਦੇ ਹਨ, ਉਪਨਾਮ ਵਰਤਦੇ ਹਨ, ਜਾਂ ਦੋ ਵਾਰੀ ਸਾਈਨ-ਅਪ ਕਰਦੇ ਹਨ।

ਸ਼ਾਮਲ ਕਰੋ:

• ਸਧਾਰਣ ਅਕਾਊਂਟ ਰੀਕਵਰੀ (ਕੋਡ/ਲਿੰਕ ਦੁਬਾਰਾ ਭੇਜਣਾ, ਸਹੀਕৰণ ਬਾਅਦ ਈਮੇਲ ਅਪਡੇਟ)
• ਐਡਮਿਨ ਮਰਜ ਟੂਲ ਡੁਪਲਿਕੇਟ ਅਕਾਊਂਟ ਲਈ (ਹਾਜ਼ਰੀ ਇਤਿਹਾਸ ਬਚਾਉਂਦੇ ਹੋਏ)
• ਸਪੱਸ਼ਟ ਆਡਿਟ ਨੋਟ ਤਾਂ ਜੋ ਸਟਾਫ ਵੇਖ ਸਕੇ ਕਿ ਕੀ ਬਦਲਿਆ ਅਤੇ ਕਦੋਂ

ਨੋਟੀਫਿਕੇਸ਼ਨ, ਰਿਮਾਈਂਡਰ ਅਤੇ ਮੈਸੇਜਿੰਗ

ਨੋਟੀਫਿਕੇਸ਼ਨ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਐਪ ਭਰੋਸਾ ਬਣਾਉਂਦੀ ਹੈ—ਜਾਂ ਸ਼ੋਰ। ਲੱਛਣ ਸਾਧਾ ਹੈ: ਸੇਵਾਦਾਰਾਂ ਨੂੰ ਪ੍ਰਯਾਪਤ ਜਾਣਕਾਰੀ ਮਿਲੇ ਤਾਂ ਕਿ ਉਹ ਤਿਆਰ ਆਉਣ, ਬਿਨਾਂ ਐਪ ਨੂੰ ਲਗਾਤਾਰ ਪਾਂਗੇ ਵਾਲਾ ਬਣਾਏ।

ਉਹ ਨੋਟੀਫਿਕੇਸ਼ਨ ਕਿਸਮਾਂ ਜੋ ਗੱਲ ਬਣਾਉਂਦੀਆਂ ਹਨ

ਛੋਟੀ ਸੋਚੀ ਗਈ ਸੁਚੀ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ:

• ਸ਼ਿਫਟ ਪੁਸ਼ਟੀਕਰਨ: ਜਦੋਂ ਸੇਵਾਦਾਰ ਸਾਈਨ ਅਪ ਕਰਦਾ ਹੈ (ਅਤੇ ਜੇ ਮਨਜ਼ੂਰੀ ਲੋੜੀਂਦੀ ਹੋਵੇ ਤਾਂ ਜਦੋਂ ਆਯੋਜਕ ਮਨਜ਼ੂਰ ਕਰਦਾ ਹੈ)
• ਰਿਮਾਈਂਡਰ: ਆਮ ਤੌਰ 'ਤੇ 24 ਘੰਟੇ ਅਤੇ 2–3 ਘੰਟੇ ਪਹਿਲਾਂ, ਟਿਕਾਣਾ ਅਤੇ ਚੇਕ-ਇਨ ਨਿਰਦੇਸ਼ਾਂ ਨਾਲ
• ਬਦਲਾਅ: ਸਮਾਂ/ਟਿਕਾਣਾ ਅਪਡੇਟ, ਰੱਦ ਸੂਚਨਾ, ਭੂਮਿਕਾ ਅਪਡੇਟ—ਇਹ ਉੱਚ ਪ੍ਰਾਥਮਿਕਤਾ ਨਾਲ ਜਾਣਕਾਰੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ
• ਤੁਰੰਤ ਲੋੜਾਂ: "ਸਾਨੂੰ 1 ਘੰਟੇ ਵਿੱਚ 3 ਹੋਰ ਗ੍ਰੀਟਰ ਚਾਹੀਦੇ ਹਨ". ਇਹ ਘੱਟ ਵਰਤੋ ਤਾਂ ਜੋ ਲੋਕ ਇਸਨੂੰ ਗੰਭੀਰਤਾ ਨਾਲ ਲੈਂ।

ਬਜਟ ਅਤੇ ਭਰੋਸੇਯੋਗਤਾ ਅਨੁਸਾਰ ਚੈਨਲ ਚੁਣੋ

• ਪੁਸ਼ ਨੋਟੀਫਿਕੇਸ਼ਨ: ਮੋਬਾਈਲ ਐਪ ਲਈ ਡੀਫਾਲਟ—ਐਪ ਇੰਸਟਾਲ ਹੋਣ 'ਤੇ ਤੇਜ਼ ਅਤੇ ਘੱਟ-ਲਾਗਤ
• ਈਮੇਲ: ਪੁਸ਼ਟੀਕਰਨ, ਸ਼ਡਿਊਲ ਅਤੇ ਵਿਸਤਾਰک ਸੁਨੇਹਿਆਂ ਲਈ ਚੰਗਾ
• SMS: ਸਮੇਂ ਸੰਵੇਦਨਸ਼ੀਲ ਅਲਰਟ ਲਈ ਸਭ ਤੋਂ ਭਰੋਸੇਯੋਗ ਪਰ ਮਹਿੰਗਾ; ਕਈ ਨਾਨਪ੍ਰਾਫਿਟ ਇਸਨੂੰ ਆਖਰੀ-ਮਿੰਟ ਬਦਲਾਅ ਲਈ ਰੱਖਦੇ ਹਨ

ਮੋਬਾਈਲ ਐਪ MVP ਲਈ ਪ੍ਰਾਇਕਟਿਕ ਤਰੀਕਾ: ਪੁਸ਼ + ਈਮੇਲ ਪਹਿਲਾਂ, ਫਿਰ ਲੋੜ ਅਤੇ ਬਜਟ ਦੇ ਅਨੁਸਾਰ SMS ਸ਼ਾਮਲ ਕਰੋ।

ਸੁਨੇਹੇ ਨੁਕਸਾਨ ਤੋਂ ਬਚਾਉਣ ਦੇ ਨਿਯਮ

ਮੂਲ ਰੱਖ-ਰਖਾਅ ਪਹਿਲਾਂ ਬਣਾਓ:

• ਸ਼ਾਂਤ ਘੰਟੇ (ਉਦਾਹਰਣ ਲਈ: ਰਾਤ 9pm ਤੋਂ ਬਾਦ ਗੈਰ-ਜ਼ਰੂਰੀ ਅਲਰਟ ਨਾ ਭੇਜੋ). ਤੁਰੰਤ ਜ਼ਰੂਰਤਾਂ ਇਸ ਤੋਂ ਛੂਟ ਹਨ।
• ਸ਼੍ਰੇਣੀ ਅਨੁਸਾਰ opt-outs (ਰਿਮਾਈਂਡਰ vs urgent requests) ਪਰ ਨਿਰਧਾਰਿਤ ਬਦਲਾਅ ਸੂਚਨਾਵਾਂ ਜ਼ਰੂਰੀ ਰੱਖੋ
• ਫ੍ਰਿਕਵੈਂਸੀ ਸੀਮਾਵਾਂ ਤਾਂ ਜੋ urgent alerts بار بار ਨਾ ਆਉਣ; ਇੱਕ ਡਾਈਜੈਸਟ ਵਿਕਲਪ ਵੀ ਸੋਚੋ

ਦੋ-ਤਰਫ਼ਾ ਸੰਚਾਰ (ਤੁਰੰਤ ਬੇਵਸਥਾ ਬਿਨਾਂ)

ਇਕ-ਤਰਫ਼ਾ ਅਲਰਟਾਂ ਕਾਫ਼ੀ ਨਹੀਂ ਹੁੰਦੀਆਂ। ਸੇਵਾਦਾਰਾਂ ਨੂੰ ਸੁਨੇਹੇ ਤੋਂ ਕਾਰਵਾਈ ਕਰਨ ਦਿਓ:

• ਐਪ ਤੋਂ ਪੁਸ਼ਟੀ, ਰੱਦ, ਜਾਂ ਸਵੈਪ ਦੀ ਬੇਨਤੀ ਕਰੋ।
• ਸ਼ਿਫਟ ਥ੍ਰੈਡ 'ਤੇ ਸਵਾਲ ਪੁੱਛੋ (ਜਿਵੇਂ: "ਮੇਰਾ ਪਰਕਿੰਗ ਕਿੱਥੇ ਹੈ?")

ਗੱਲ-ਬਾਤ ਨੂੰ ਖਾਸ ਸ਼ਿਫਟ ਜਾਂ ਇਵੈਂਟ ਨਾਲ ਜੋੜ ਕੇ ਰੱਖੋ ਤਾਂ ਜੋ ਆਯੋਜਕਾਂ ਨੂੰ ਬੇਵਸਥਾ ਨਾ ਹੋਵੇ ਅਤੇ ਵੇਰਵੇ ਤਲਾਸ਼ਣਯੋਗ ਰਹਿਣ।

ਚੇਕ-ਇਨ, ਹਾਜ਼ਰੀ ਅਤੇ ਵਾੱਲੰਟੀਅਰ ਘੰਟੇ

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

ਚੇਕ-ਇਨ ਢੰਗ (ਅਤੇ ਕਦੋਂ ਵਰਤਣ)

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

• QR ਕੋਡ ਚੇਕ-ਇਨ: ਸਾਈਟ 'ਤੇ QR ਕੋਡ ਲਗਾਓ (ਜਾਂ ਇਹ ਲੀਡਰ ਦੇ ਡਿਵਾਈਸ 'ਤੇ ਵੇਖਾਓ). ਤੇਜ਼ ਹੈ ਅਤੇ ਉੱਚ-ਵਾਲੀਅਮ ਇਵੈਂਟ ਲਈ ਚੰਗਾ।
• GPS ਜਿਓਫੈਂਸ ਚੇਕ-ਇਨ: ਚੇਕ-ਇਨ ਸਿਰਫ਼ ਜਦੋਂ ਫੋਨ ਨਿਰਧਾਰਤ ਰੇਡੀਅਸ ਦੇ ਅੰਦਰ ਹੋਵੇ ਆਨੁਮਤ ਕਰੋ। ਇਹ "ਮੈਂ ਚੇਕ-ਇਨ ਭੁੱਲ ਗਿਆ" ਦੀ ਗਲਤੀਆਂ ਘਟਾਉਂਦਾ ਹੈ ਅਤੇ ਹੌਲੀ-ਹੌਲੀ ਸਥਾਪਤ ਪੁਸ਼ਟੀ ਦਿੰਦਾ ਹੈ।
• ਲੀਡਰ ਦੁਆਰਾ ਹੱਥੋਂ ਪੁਸ਼ਟੀ: ਲੀਡਰ ਰੋਸਟਰ ਤੋਂ ਸੇਵਾਦਾਰਾਂ ਨੂੰ ਚੇਕ-ਇਨ ਕਰ ਸਕਦਾ ਹੈ (ਛੋਟੇ ਸਮੂਹ, ਅੰਦਰੂਨੀ ਸਾਈਟਾਂ ਜਿੱਥੇ GPS ਖ਼राब ਹੋਵੇ, ਜਾਂ ਜਦੋਂ ਕਿਸੇ ਕੋਲ ਐਪ ਨਹੀਂ ਹੈ)

ਚੰਗਾ ਡਿਫਾਲਟ: ਸਵੈ-ਸੇਵਾ ਲਈ QR ਜਾਂ GPS, ਅਤੇ ਫੈਲਬੈਕ ਲਈ ਲੀਡਰ ਪੁਸ਼ਟੀ।

ਦੇਰ ਨਾਲ ਆਉਣ ਅਤੇ ਅਧ-ਘੰਟਿਆਂ ਲਈ ਨਿਯਮ

ਸਧਾਰਨ, ਪਾਰਦਰਸ਼ੀ ਨਿਯਮ ਪਰਿਭਾਸ਼ਤ ਕਰੋ ਤਾਂ ਜੋ ਸੇਵਾਦਾਰ ਅਤੇ ਕੋਆਰਡੀਨੇਟਰ ਉਸੇ ਨੰਬਰ ਦੇਖਣ:

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

ਇਹ ਨਿਯਮ UI ਵਿੱਚ ਦਿੱਸਣ ਚਾਹੀਦੇ ਹਨ ("Hours credited: 2h 15m") ਤਾਂ ਕਿ ਵਿਵਾਦ ਨਾ ਹੋਣ।

ਨਿਰਲੇਪਣ-ਰੋਕਥਾਮ ਬਿਨਾਂ ਬੇਹਦ ਖਿਚਾਵਟ

ਅਕਸਰ ਭਾਰੀ ਨਿਯੰਤਰਣ ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ। ਇਸ ਦੀ ਥਾਂ ਹਲਕੀ-ਫੈਲਟੀ ਜਾਂਚ 'ਤੇ ਧਿਆਨ ਦਿਓ ਜੋ ਸੇਵਾਦਾਰਾਂ ਦੇ ਸਮੇਂ ਦਾ ਸਤਕਾਰ ਕਰਦੀ ਹੈ:

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

ਇਹ ਦ੍ਰਿਸ਼ਟੀ ਦੁਰਵਰਤਨ ਨੂੰ ਰੋਕਦੀ ਹੈ, ਅਨੁਭਵ ਨੂੰ ਮਿੱਤਰਵਾਨ ਰੱਖਦੀ ਹੈ।

ਨਾਨਪ੍ਰਾਫਿਟ ਵਾਸਤੇ ਨਿਰਯਾਤ ਅਤੇ ਸਾਰ

ਘੰਟਿਆਂ ਦਾ ਡੇਟਾ ਤਦ ਹੀ ਕੀਮਤੀ ਬਣਦਾ ਹੈ ਜਦੋਂ ਇਸਨੂੰ ਸਿਰਫ਼ ਅਸਾਨੀ ਨਾਲ ਸੰਖੇਪ ਕੀਤਾ ਅਤੇ ਸਾਂਝਾ ਕੀਤਾ ਜਾ ਸਕੇ। ਸਧਾਰਨ ਫਿਲਟਰ ਅਤੇ ਨਿਰਯਾਤ ਸ਼ਾਮਲ ਕਰੋ:

• ਵਿਅਕਤੀ-ਵਾਰ ਘੰਟੇ (ਪਹਚਾਣ, ਪ੍ਰਸ਼ੰसा, ਜਾਂ ਗ੍ਰੈਂਟ ਰਿਪੋਰਟਿੰਗ ਲਈ)
• ਪ੍ਰੋਗਰਾਮ/ਈਵੈਂਟ ਵਾਰ ਘੰਟੇ (ਸਟਾਫਿੰਗ ਜ਼ਰੂਰਤਾਂ ਦਾ ਮੁਲਾਂਕਣ ਕਰਨ ਲਈ)
• ਤਾਰੀਖ ਰੇਂਜ ਵਾਰ (ਮਾਸਿਕ ਅਤੇ ਤਿਮਾਹੀ ਰਿਪੋਰਟ)

ਨਿਰਯਾਤ ਪਹਿਲਾਂ CSV ਹੋਣ (ਸਭ ਲਈ ਵਰਤੋਂਯੋਗ), ਪ੍ਰਿੰਟ ਕਰਨਯੋਗ ਸਾਰ ਜੋੜੋ। ਟੋਟਲ ਅਤੇ ਪ੍ਰਤੀ-ਸ਼ਿਫਟ ਵੇਰਵਾ ਸ਼ਾਮਲ ਕਰੋ ਤਾਂ ਕਿ ਪ੍ਰਸ਼ਾਸਕ ਜਲਦੀ ਆਡਿਟ ਕਰ ਸਕਣ।

ਨਿੱਜਤਾ, ਸੁਰੱਖਿਆ, ਅਤੇ ਬੁਨਿਆਦੀ ਸੁਰੱਖਿਆ

ਸੇਵਾਦਾਰ ਸੰਯੋਜਨ ਐਪ ਅਕਸਰ ਸੰਵੇਦਨਸ਼ੀਲ ਵੇਰਵੇ (ਨਾਂ, ਫੋਨ ਨੰਬਰ, ਉਪਲਬਧਤਾ, ਅਤੇ ਕਿ ਕੋਈ ਫਿਰ ਡਿੱਠਾ ਜਾਵੇਗਾ) ਸੰਭਾਲਦਾ ਹੈ। ਨਿੱਜਤਾ ਅਤੇ ਸੁਰੱਖਿਆ early-stage 'ਤੇ ਠੀਕ ਕਰਨ ਨਾਲ ਭਰੋਸਾ ਬਣਦਾ ਹੈ—ਅਤੇ ਸੰਸਥਾ ਲਈ ਖ਼ਤਰਾ ਘਟਦਾ ਹੈ।

ਸੰਪਰਕ ਜਾਣਕਾਰੀ ਲਈ ਵਿਜ਼ੀਬਿਲਟੀ ਕੰਟਰੋਲ

ਹਰ ਸੇਵਾਦਾਰ ਆਪਣਾ ਨੰਬਰ/ਈਮੇਲ ਸਾਰਿਆਂ ਨਾਲ ਸਾਂਝਾ ਨਹੀਂ ਕਰਨਾ ਚਾਹੁੰਦਾ। ਸਧਾਰਣ ਕੰਟਰੋਲ ਜੋੜੋ:

• ਡੀਫਾਲਟ ਤੌਰ 'ਤੇ ਫੋਨ/ਈਮੇਲ ਲੁਕਾਓ, ਅਤੇ ਸੇਵਾਦਾਰਾਂ ਨੂੰ opt-in ਦੀ ਆਗਿਆ ਦਿਓ
• ਰੋਲ-ਆਧਾਰਿਤ ਵਿਜ਼ੀਬਿਲਟੀ: ਕੋਆਰਡੀਨੇਟਰ ਸੰਪਰਕ ਵੇਰਵਾ ਵੇਖ ਸਕਦੇ ਹਨ; ਹੋਰ ਸੇਵਾਦਾਰਾਂ ਨੂੰ ਸਿਰਫ ਪਹਿਲਾ ਨਾਮ ਜਾਂ ਇਨ-ਐਪ ਮੈਸੇਜਿੰਗ
• ਪ੍ਰਤੀ-ਇਵੈਂਟ ਓਵਰਰਾਈਡ ਹਾਈ-ਸੈਂਸਿਟਿਵ ਇਵੈਂਟਾਂ ਲਈ (ਜਿਵੇਂ ਨਾਬਾਲਿਗ, ਘਰੇਲੂ ਹਿੰਸਾ ਝਗੜੇ): ਵੋਲੰਟੀਅਰ-ਟੁ-ਵੋਲੰਟੀਅਰ ਸੰਪਰਕ sharing ਬੰਦ ਕਰੋ

ਡੇਟਾ ਘਟਾਉਣਾ (ਕੇਵਲ ਜੋ ਲੋੜੀਦਾ ਹੈ ਇਕੱਠਾ ਕਰੋ)

ਹਰ ਫੀਲਡ ਨੂੰ ਇੱਕ ਜ਼ਿਮੇਵਾਰੀ ਸਮਝੋ। ਜੇ ਇਹ ਸੀਧਾ ਸਕੇਜੂਲਿੰਗ, ਰਿਮਾਈਂਡਰ, ਜਾਂ ਚੇਕ-ਇਨ ਵਿੱਚ ਸਹਾਇਕ ਨਹੀਂ, ਤਾਂ ਇਸਨੂੰ skip ਕਰੋ।

ਵਾਪਸੀ ਕੌਮਾਂਤਰੀ ਨਿਯਮ: ਸ਼ੁਰੂ ਵਿੱਚ ਨਾਂ, ਪREFERੰਡ ਸੰਪਰਕ ਪ੍ਰਣਾਲੀ, ਉਪਲਬਧਤਾ, ਅਤੇ ਐਮਰਜੈਂਸੀ ਸੰਪਰਕ (ਜੇ ਜ਼ਰੂਰੀ) ਰੱਖੋ। ਜਨਮ ਤਾਰੀਖ, ਘਰ ਪਤਾ, ਜਾਂ ਵਿਸਥਾਰਕ ਨੋਟਾਂ ਨਾ ਲਵੋ ਬਿਨਾਂ ਸਪਸ਼ਟ ਕਾਰਨ ਅਤੇ ਦੇਖਣ ਵਾਲੇ ਨੀਤੀ ਦੇ।

ਬੁਨਿਆਦੀ ਸੁਰੱਖਿਆ ਜੋ ਬਹੁਤਖੇਤਰ ਖਤਰੇ ਦਾ ਕਵਰ ਕਰਦੀ ਹੈ

ਤੁਹਾਨੂੰ ਵੱਡੀਆਂ ਸਰਕਾਰੀ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੀ ਲੋੜ ਨਹੀਂ; ਬੁਨਿਆਦੀ ਚੀਜ਼ਾਂ ਪ੍ਰਾਥਮਿਕਤਾ ਨਾਲ:

• ਇੰ-ਟ੍ਰਾਂਜ਼ਿਟ ਇਨਕ੍ਰਿਪਸ਼ਨ: ਸਾਰੇ API ਕਾਲ HTTPS/TLS ਵਰਤੋਂ
• ਪਾਸਵਰਡ (ਜੇ ਵਰਤੇ ਜਾਂ): ਸਿਰਫ salted, hashed ਰੱਖੋ (ਕਦੇ ਵੀ plain text ਨਾ)
• least-privilege ਅਧਿਕਾਰ: ਸਟਾਫ ਅਕਾਉਂਟਜ਼ ਨੂੰ ਕੇਵਲ ਜਿਨ੍ਹਾਂ ਦੀ ਲੋੜ ਹੈ ਉਹੀ ਪਹੁੰਚ
• ਲੌਗਿੰਗ ਅਤੇ ਆਡਿਟ ਟ੍ਰੇਲ: ਮੁੱਖ ਐਡਮਿਨ ਕਾਰਵਾਈਆਂ (ਰੋਲ-ਚੇਂਜ, نਿਰਯਾਤ, ਮਿਟਾਉ) ਰਿਕਾਰਡ ਕਰੋ

ਐਡਮਿਨ ਪ੍ਰਕਿਰਿਆ ਜੋ ਤੁਸੀਂ ਪਰਿਭਾਸ਼ਤ ਕਰੋ

ਸੁਰੱਖਿਆ ਆਪਰੇਸ਼ਨਲ ਵੀ ਹੈ। ਪਹਿਲਾਂ ਹੀ ਫੈਸਲੇ ਕਰੋ:

• ਵਰਤੋਂਕਾਰ ਕਿਵੇਂ ਅਕਾਊਂਟ ਮਿਟਾਉਣ ਦੀ ਬੇਨਤੀ ਕਰ ਸਕਦੇ ਹਨ (ਅਤੇ ਕੰਪਲਾਇੰਸ ਲਈ ਕੀ ਡੇਟਾ ਰੱਖਣਾ ਲਾਜ਼ਮੀ ਹੈ)
• ਪਹੁੰਚ ਸਮੀਖਿਆ ਦੀ ਇੱਕ ਕਰੈੰਡ (ਉਦਾਹਰਣ: ਹਰ ਮਹੀਨੇ ਪੁਰਾਣੇ ਕੋਆਰਡੀਨੇਟਰ ਹਟਾਓ)
• ਇੱਕ ਹਲਕੀ-ਫੈਲਟੀ Incident response plan: ਕਿੰਨੇ ਨੂੰ ਸੂਚਿਤ ਕਰਨਾ, ਪਹੁੰਚ ਰੱਦ ਕਿਵੇਂ ਕਰਨੀ ਹੈ, ਅਤੇ ਪ੍ਰਭਾਵਤ ਯੂਜ਼ਰਾਂ ਨੂੰ ਕਿਵੇਂ ਸੰਚਾਰ ਕਰਨਾ

ਟੈਕ ਸਟੈਕ ਚੋਣਾਂ ਅਤੇ ਆਰਕੀਟੈਕਚਰ

ਤੁਹਾਡਾ ਟੈਕ ਸਟੈਕ ਦੋ ਚੀਜ਼ਾਂ ਨੂੰ ਸਮਰਥਨ ਕਰੇ: ਭਰੋਸੇਯੋਗ ਸਕੇਜੂਲਿੰਗ (ਕੋਈ ਮਿਸਡ ਸ਼ਿਫਟ ਨਾ ਹੋਵੇ) ਅਤੇ ਆਸਾਨ ਚੇਂਜ-ਮੈਨੇਜਮੈਂਟ (ਕਿੋਂਕਿ ਪ੍ਰੋਗਰਾਮ ਬਦਲਦੇ ਹਨ)। ਇੱਕ ਸਧਾਰਨ, ਮੋਢੇਇੰਟ ਮਾਡਿਊਲਰ ਆਰਕੀਟੈਕਚਰ MVP ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਸ਼ਿਪ ਕਰਨ ਅਤੇ ਫਿਰ ਫੀਚਰ ਜੋੜਨ ਵਿੱਚ ਮਦਦ ਕਰਦੀ ਹੈ।

ਮੋਬਾਈਲ: ਨੈਟਿਵ ਬਨਾਮ ਕ੍ਰਾਸ-ਪਲੇਟਫਾਰਮ

ਨੈਟਿਵ (Swift iOS ਲਈ, Kotlin Android ਲਈ) ਆਮ ਤੌਰ 'ਤੇ ਸਭ ਤੋਂ ਨਰਮ ਅਨੁਭਵ ਅਤੇ ਪਲੇਟਫਾਰਮ-ਕੁਦਰਤੀ ਮਹਿਸੂਸ ਦਿੰਦਾ—ਖਾਸ ਤੌਰ 'ਤੇ ਕੈਲੇਂਡਰ, ਪੁਸ਼ ਨੋਟੀਫਿਕੇਸ਼ਨ, ਬੈਕਗ੍ਰਾਊਂਡ ਟਾਸਕ, ਅਤੇ ਪਹੁੰਚਯੋਗਤਾ ਸੈਟਿੰਗਜ਼ ਲਈ। ਕਿੰਮਤ ਅਤੇ ਸਮਾਂ ਵੱਧ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਦੋ ਕੋਡਬੇਸ ਰੱਖਣੇ ਪੈਂਦੇ ਹਨ।

ਕ੍ਰਾਸ-ਪਲੇਟਫਾਰਮ (React Native ਜਾਂ Flutter) ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਸਾਂਝੇ ਕੋਡਬੇਸ ਨਾਲ ਮਾਰਕੀਟ ਤੱਕ ਤੇਜ਼ੀ ਲਿਆਉਂਦਾ ਹੈ। ਇਹ ਇੱਕ ਮਜ਼ਬੂਤ ਫਿਟ ਹੈ ਜਿੱਥੇ ਜ਼ਿਆਦਾਤਰ ਸਕ੍ਰੀਨ ਫਾਰਮ, ਲਿਸਟ, ਅਤੇ ਸਕੇਜੂਲ ਹਨ। ਘਟਕ ਸਮੱਸਿਆਵਾਂ (ਪੁਸ਼ ਵਿਵਹਾਰ, ਡੀਪ ਲਿੰਕ, OS ਅੱਪਡੇਟ) ਲਈ ਕਦੇ-ਕਦੇ ਪਲੇਟਫਾਰਮ-ਨਿਰਦੇਸ਼ ਕੋਡ ਲਗਦਾ ਹੈ।

ਇੱਕ ਪ੍ਰਾਇਕਟਿਕ MVP ਦ੍ਰਿਸ਼ਟੀ: ਕ੍ਰਾਸ-ਪਲੇਟਫਾਰਮ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, ਪਰ ਜਦੋਂ OS ਇਕਲਪਤਾ ਆਏ ਤਾਂ ਛੋਟੀ ਬਜਟ ਨੈਟਿਵ ਬ੍ਰਿਜ ਲਈ ਰੱਖੋ।

ਜੇ ਤੁਸੀਂ ਵਰਕਫਲੋ (shifts → signups → reminders → check-in) ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਵੈਰੀਫਾਈ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ ਬਿਨਾਂ ਪੂਰੇ ਪਾਈਪਲਾਈਨ ਬਣਾਉਣ ਦੇ, ਤਾਂ ਇੱਕ vibe-coding ਪਲੇਟਫਾਰਮ ਜਿਵੇਂ Koder.ai ਤੁਹਾਡੀ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ—ਆਮ ਤੌਰ 'ਤੇ React ਵੈੱਬ, Go ਬੈਕਐਂਡ, ਅਤੇ PostgreSQL ਲਈ। ਜਦੋਂ ਤੁਸੀਂ ਤਿਆਰ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਸੋਰਸ ਕੋਡ ਨਿਰਯਾਤ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਆਪਣੀ ਟੀਮ ਨਾਲ ਅੱਗੇ ਵਧ ਸਕਦੇ ਹੋ।

ਬੈਕਐਂਡ: API, ਡੇਟਾਬੇਸ, ਅਤੇ ਫਾਇਲ ਸਟੋਰੇਜ

ਬੈਕਐਂਡ ਲਈ surface area ਛੋਟੀ ਰੱਖੋ:

• API: ਇੱਕ ਸਿੱਧਾ REST API ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ ਲਈ ਸਭ ਤੋਂ ਅਸਾਨ; GraphQL ਲਾਭਦਾਇਕ ਹੋ ਸਕਦਾ ਹੈ ਜੇ ਤੁਹਾਨੂੰ ਕਈ ਕਲਾਇੰਟ ਵਿਊਜ਼ ਦੀ ਉਮੀਦ ਹੈ (ਕੋਆਰਡੀਨੇਟਰ ਡੈਸ਼ਬੋਰਡ ਵਜ਼ਨ ਵਾਲੇ vs ਸੇਵਾਦਾਰ), ਪਰ ਇਹ ਜਟਿਲਤਾ ਵਧਾਉਂਦਾ ਹੈ।
• ਡੇਟਾਬੇਸ: ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸ ਜਿਵੇਂ PostgreSQL shifts, roles, assignments ਅਤੇ attendance ਲਈ ਇਕ ਵਧੀਆ ਡੀਫਾਲਟ ਹੈ।
• ਫਾਇਲ ਸਟੋਰੇਜ: ਡਾਕੂਮੈਂਟ (waivers, training PDFs) ਵਸਤੂ ਸਟੋਰੇਜ (S3-ਕੰਪੈਟਿਬਲ) ਵਿੱਚ ਰੱਖੋ, DB ਵਿੱਚ ਲਿੰਕ। ਫਾਇਲਾਂ ਨੂੰ ਸਿੱਧਾ ਡੇਟਾਬੇਸ ਵਿੱਚ ਨਾ ਰੱਖੋ।

ਕੈਲੇਂਡਰ ਇੰਟਿਗ੍ਰੇਸ਼ਨ (ਲੋ-ਫ੍ਰਿਕਸ਼ਨ)

ਸਧਾਰਨ ਰੱਖੋ:

• Add-to-calendar ਬਟਨ (Google/Apple/Outlook) ਸ਼ਿਫਟ ਵੇਰਵਾ ਤੋਂ
• iCal (.ics) ਨਿਰਯਾਤ ਇੱਕ ਇਕੱਲੀ ਸ਼ਿਫਟ ਜਾਂ ਸੇਵਾਦਾਰ ਦੇ ਆਗਲੇ ਸ਼ਡਿਊਲ ਲਈ

ਇਹ ਸੇਵਾਦਾਰਾਂ ਨੂੰ ਕਾਬੂ ਦਿੰਦਾ ਹੈ ਬਿਨਾਂ ਦੁਨੀਆਂ-ਪਾਸੇ ਦੁਆਰਾ ਦੋ-ਤਰਫ਼ਾ ਕੈਲੇਂਡਰ ਸਿੰਕਿੰਗ ਦੇ ਜਟਿਲਤਾਂ ਦੇ।

CTA ਉਹਥੇ ਜਿੱਥੇ ਫ਼ੈਸਲੇ ਹੋ ਰਹੇ

ਜੇ ਇਹ ਲੇਖ ਕਿਸੇ ਉਤਪਾਦ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ, ਤਾਂ CTAs ਓਸਥਾਨਾਂ 'ਤੇ ਰੱਖੋ ਜਿੱਥੇ ਪਾਠਕ ਕੁਦਰਤੀ ਰੂਪ ਵਿੱਚ ਰੁਕਦੇ ਹਨ:

• stack options ਤੋਂ ਬਾਅਦ: “See plans and hosting options” → /pricing
• ਡੇਟਾ ਲੋੜਾਂ ਅਤੇ ਰੋਲ ਬਾਰੇ ਵਰਣਨ ਤੋਂ ਬਾਅਦ: “Talk through your requirements” → /contact

ਜੇ ਤੁਸੀਂ Koder.ai ਨਾਲ ਬਣਾ ਰਹੇ ਹੋ, ਤਾਂ ਇਹ ਕੁਦਰਤੀ ਨਕਸ਼ੇ ਵੀ ਹਨ—ਟਿਅਰ ਚੁਣੋ ਜਾਂ planning mode ਵਰਤ ਕੇ roles, permissions, ਅਤੇ shift lifecycle ਨਕਸ਼ਾ ਬਣਾਉਣਾ ਪਹਿਲਾਂ, ਫਿਰ ਐਪ ਜਨਰੇਟ ਕਰੋ।

ਟੈਸਟਿੰਗ, ਲਾਂਚ, ਅਤੇ ਇਟਰੇਸ਼ਨ ਯੋਜਨਾ

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

1) UI ਤੋਂ ਪਹਿਲਾਂ ਸਕੇਜੂਲਿੰਗ ਨਿਯਮ ਟੈਸਟ ਕਰੋ

ਸਭ ਤੋਂ ਪਹਿਲਾਂ "ਗਣਿਤ" ਟੈਸਟ ਕਰੋ। ਕੁਝ ਟੈਸਟ ਸਿਨੇਰੀਓ ਬਣਾਓ ਅਤੇ ਹਰ ਵਾਰੀ ਸਕੇਜੂਲਿੰਗ ਲੌਜਿਕ ਬਦਲੋ ਤਾਂ ਉਨ੍ਹਾਂ ਨੂੰ ਚਲਾਓ:

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

ਅਜੇਹੇ ਨਿਯਮਾਂ 'ਤੇ ਹਲਕੀ automated test suite ਹੋਵੇ ਤਾਂ regressions ਜ਼ਰੂਰ ਜਲਦੀ पकड़ੇ ਜਾ ਸਕਦੇ ਹਨ।

2) ਅਸਲੀ ਸੇਵਾਦਾਰਾਂ ਨਾਲ usability ਟੈਸਟਿੰਗ

5–8 ਸੇਵਾਦਾਰ ਲਿਆਓ ਜੋ ਤੁਹਾਡੇ ਹਕੀਕਤੀ ਦਰਸ਼ਕ ਨੂੰ ਨਥਾ ਕਰਦੇ ਹਨ (ਘੱਟੋ-ਘੱਟ ਇੱਕ ਪਹਿਲੀ ਵਾਰ ਆਉਣ ਵਾਲਾ)। ਓਹਨਾਂ ਨੂੰ ਕਾਰਜ ਦਿਓ ਜਿਵੇਂ "ਅਗਲੇ ਸ਼ਨੀਵਾਰ ਲਈ ਸ਼ਿਫਟ ਲੱਭੋ" ਜਾਂ "ਇੱਕ ਸ਼ਿਫਟ ਰੱਦ ਕਰੋ ਅਤੇ ਕੋਆਰਡੀਨੇਟਰ ਨੂੰ ਸੁਨੇਹਾ ਭੇਜੋ"।

ਧਿਆਨ ਦੇਖੋ:

• ਗੁੰਝਲਦਾਰ ਲੇਬਲ ("role" ਬਨਾਮ "position")
• ਸਾਈਨ ਅਪ ਲਈ ਬਹੁਤ ਜ਼ਿਆਦਾ ਕਦਮ
• ਪੁਸ਼ਟੀ ਦੀਆਂ ਸਥਿਤੀਆਂ ਮਿਸ ਹੋ ਰਹੀਆਂ

ਜਿੱਥੇ ਜਲੰਬਦਾਰੀ ਹੋ, ਉਹ ਅਕਸਰ ਅਸਲ ਵਰਤੋਂ ਵਿੱਚ ਡ੍ਰੌਪ-ਆਫ ਬਣਦਾ ਹੈ।

3) ਬੀਟਾ ਰੋਲਆਊਟ: ਪਹਿਰੇਦਾਰ, ਫਿਰ ਵਧਾਓ

ਇੱਕ ਬੀਟਾ ਇੱਕ ਇਕ ਪ੍ਰੋਗਰਾਮ ਜਾਂ ਇਕ ਇਵੈਂਟ ਸਿਰੀਜ਼ ਨਾਲ شروع ਕਰੋ। ਟੀਮ ਐਨੀ ਹੋਵੇ ਕਿ ਤੁਸੀਂ ਨੇੜੇ ਨਾਲ ਸਮਰਥਨ ਕਰ ਸਕੋ, ਪਰ ਕਾਫੀ ਵੱਡੀ ਹੋ ਕਿ ਅਸਲੀ ਸਕੇਜੂਲਿੰਗ ਗਤੀਵਿਧੀ ਪੈਦਾ ਹੋਵੇ।

ਬੀਟਾ ਦੌਰਾਨ ਉਮੀਦਾਂ ਸੈੱਟ ਕਰੋ: ਫੀਚਰ ਬਦਲ ਸਕਦੇ ਹਨ ਅਤੇ ਫੀਡਬੈਕ ਭਾਗੀਦਾਰੀ ਦਾ ਹਿੱਸਾ ਹੈ। ਇੱਕ ਸਪੱਸ਼ਟ ਸਹਾਇਤਾ ਰਸਤਾ ਰੱਖੋ (ਹੈਲਪ ਈਮੇਲ ਜਾਂ ਇਨ-ਐਪ ਸੰਪਰਕ ਵਿਕਲਪ)।

4) ਮਾਪੋ, ਦੁਬਾਰਾ ਬਣਾਓ, ਅਤੇ ਰਿਸ਼ਿਪ ਕਰੋ

ਕੁਝ ਮੈਟ੍ਰਿਕਸ ਚੁਣੋ ਜੋ ਨਤੀਜਿਆਂ ਨਾਲ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਜੁੜੇ ਹੋਣ:

• Fill rate (ਕਿੰਨੀ ਸ਼ਿਫਟਾਂ ਸਮਰੱਥਾ ਤੱਕ ਭਰੀਆਂ)
• No-show rate
• Time-to-fill (ਪੋਸਟ ਹੋਣ ਤੋਂ ਲੈ ਕੇ ਫੁੱਲ ਹੋਣ ਤੱਕ)
• Reminder open rate (ਅਤੇ ਕੀ opens ਹਾਜ਼ਰੀ ਨਾਲ ਜੁੜੇ ਹਨ)

ਹਫਤਾਵਾਰ ਸਮੀਖਿਆ ਕਰੋ, ਸਭ ਤੋਂ ਵੱਡੇ friction point ਨੂੰ ਪ੍ਰਾਥਮਿਕਤਾ ਦਿਓ, ਅਤੇ ਨਿੱਕੇ increments ਵਿੱਚ ਸੁਧਾਰ ਸ਼ਿਪ ਕਰੋ। ਰੀਲੀਜ਼ ਨੋਟਸ ਜੋੜੋ ਤਾਂ ਕਿ ਸੇਵਾਦਾਰ ਸਮਝਣ ਕਿ ਕੀ ਬਦਲਿਆ ਅਤੇ ਕਿਉਂ।