ਕਲਾਸਰੂਮ ਡਿਵਾਈਸ ਨੁਕਸਾਨ ਰਿਪੋਰਟ ਫਾਰਮ — ਮੁਰammat ਅਤੇ ਫੋਟੋਆਂ ਟਰੈਕ ਕਰਨ ਲਈ

ਕਲਾਸਰੂਮ ਵਿੱਚ ਖਰਾਬ ਡਿਵਾਈਸ ਆਮ ਤੌਰ 'ਤੇ ਕਿੱਥੇ ਹੋ ਜਾਂਦੇ ਹਨ

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

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

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

ਔਰ ਨੀਮ ਹੁਣੇ ਹੀ ਮੁੜ-ਮੁੜ ਦਰਸਾਈਆਂ ਜਾਂਦੀਆਂ ਗਲਤੀਆਂ ਹਨ:

• ਐਸੇ ਬੇਸਿਕ ਵੇਰਵੇ ਗ਼ਾਇਬ: ਐਸੈੱਟ ਟੈਗ, ਵਿਦਿਆਰਥੀ ਦਾ ਨਾਮ, ਤਾਰੀਖ ਅਤੇ ਟਿਕਾਣਾ
• ਫੋਟੋ ਸਬੂਤ ਨਹੀਂ ਹਨ, ਜਾਂ ਫੋਟੋਆਂ ਨੁਕਸਾਨ ਨੂੰ ਸਾਫ਼ ਨਹੀਂ ਦਿਖਾਉਂਦੀਆਂ
• ਅਗਲੇ ਹੇਠਾਂ ਹਵਾਲੇ ਅਸਪਸ਼ਟ (ਹੁਣ ਕਿਸ ਦੇ ਕੋਲ ਹੈ, ਅਗਲਾ ਜ਼ਿੰਮੇਵਾਰ ਕੌਣ ਹੈ)

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

ਕੁਝ ਸਕੂਲ ਇਸਨੂੰ ਇੱਕ ਸਾਹਮਣੇ-ਸਾਧਾ ਅੰਦਰੂਨੀ ਟੂਲ ਵਿੱਚ ਬਣਾਉਂਦੇ ਹਨ ਤਾਂ ਜੋ ਫਾਰਮ, ਸਥਿਤੀ ਅੱਪਡੇਟ ਅਤੇ ਮਰammat ਇਤਿਹਾਸ ਇਕੱਠੇ ਰਹਿਣ। ਉਦਾਹਰਣ ਲਈ, ਟੀਮਾਂ ਕਈ ਵਾਰੀ Koder.ai ਵਰਤ ਕੇ ਆਪਣੇ ਵਰਕਫਲੋ ਅਨੁਸਾਰ ਇੱਕ ਲਾਈਟਵੇਟ ਟਰੈਕਰ ਚੈਟ-ਬਿਲਡ ਕਰਦੀਆਂ ਹਨ। ਟੂਲ ਘੱਟ ਮਹੱਤਵਪੂਰਣ ਹੈ—ਆਦਤ ਜ਼ਰੂਰੀ ਹੈ: ਇੱਕ ਰਿਪੋਰਟ, ਇੱਕ ਡਿਵਾਈਸ, ਇੱਕ ਟਾਈਮਲਾਈਨ।

ਫਾਰਮ ਨੂੰ ਕੀ ਜਾਣਕਾਰੀ ਇਕੱਠੀ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ

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

ਪਹਿਲਾਂ ਐਸੇ ਪਛਾਣ-ਸੂਤਰ ਲਿਖੋ ਜੋ ਯਾਦ 'ਤੇ ਨਿਰਭਰ ਨਾ ਹੋਣ: ਐਸੈੱਟ ਟੈਗ (ਸਟਾਫ਼ ਦੇਖ ਸਕਦੇ ਹਨ), ਸੀਰੀਅਲ ਨੰਬਰ (ਵਾਰੰਟੀ ਅਤੇ ਵੈਂਡਰ ਰਿਪੇਅਰ ਲਈ), ਅਤੇ ਡਿਵਾਈਸ ਮਾਡਲ। ਜੇ ਸਕੂਲ ਕਾਰਟ ਵਰਤਦੇ ਹਨ, ਤਾਂ ਕਾਰਟ ਨੰਬਰ ਅਤੇ ਸਲਾਟ ਪੋਜ਼ੀਸ਼ਨ ਵੀ ਜੋੜੋ ਤਾਂ ਕਿ ਸਟਾਫ਼ ਮਰammat ਮਗਰੋਂ ਸਹੀ ਢੰਗ ਨਾਲ ਵਾਪਸ ਰੱਖ ਸਕਣ।

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

ਇਨਸਿਡੈਂਟ ਲਈ, ਸੰਖੇਪ ਅਤੇ ਸਪਸ਼ਟ ਰਖੋ: ਕੀ ਹੋਇਆ, ਕਦੋਂ, ਅਤੇ ਕਿੱਥੇ। ਇੱਕ ਵਾਕ ਜਿਵੇਂ “Room 204 ਵਿੱਚ 3rd period ਦੌਰਾਨ ਡੈਸਕ ਤੋਂ ਡਿੱਗਿਆ” ਲੰਮੇ ਕਹਾਣੀ ਨਾਲੋਂ ਵਧੇਰੇ ਉਪਯੋਗੀ ਹੈ।

ਇਕ ਛੋਟਾ ਯੂਜ਼ਬਿਲਟੀ ਫੀਲਡ ਜੋੜੋ ਤਾਂ ਕਿ IT ਤੁਰੰਤ ਤਯਾਰ ਕਰ ਸਕੇ:

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

ਅਖੀਰ 'ਤੇ, ਤੁਰੰਤ ਕੀ ਕਾਰਵਾਈ ਕੀਤੀ ਗਈ ਉਸਨੂੰ ਰਿਕਾਰਡ ਕਰੋ: ਕੀ ਡਿਵਾਈਸ ਬੰਦ ਕੀਤਾ ਗਿਆ, ਸਟਾਫ਼ ਨੇ ਇਕੱਠਾ ਕੀਤਾ, ਲੇਬਲ ਕੀਤਾ ਗਿਆ ਬਿਨ ਵਿੱਚ ਰੱਖਿਆ ਗਿਆ, ਅਤੇ ਕੀ ਲੋਨਰ ਦਿੱਤਾ ਗਿਆ। ਉਦਾਹਰਣ: “Power off ਕੀਤਾ, ਟੈਗ ਕੀਤਾ, ਲੋਨਰ Chromebook #C-118 ਵਿਦਿਆਰਥੀ ਨੂੰ ਦਿੱਤਾ।”

ਫੋਟੋਆਂ ਦੇ ਨਿਯਮ ਜੋ ਪ੍ਰਾਈਵੇਸੀ ਦਾ ਧਿਆਨ ਰੱਖਣਗੇ

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

ਫੋਟੋ ਸੈੱਟ ਛੋਟਾ ਅਤੇ ਸਥਿਰ ਰੱਖੋ। ਜ਼ਿਆਦਾਤਰ ਕੇਸਾਂ ਵਿੱਚ 2 ਤੋਂ 4 ਫੋਟੋ ਕਾਫੀ ਹੁੰਦੀਆਂ ਹਨ ਜੇ ਉਹ ਨੁਕਸਾਨ ਨੂੰ ਸਾਫ਼ ਦਿਖਾਉਂਦੀਆਂ ਹਨ:

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

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

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

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

ਉਦਾਹਰਣ: ਇੱਕ ਵਿਦਿਆਰਥੀ ਨੇ ਟੈਬਲੇਟ 'ਤੇ ਕ੍ਰੈਕ ਦੀ ਰਿਪੋਰਟ ਕੀਤੀ। ਅਧਿਆਪਕ ਇੱਕ ਫਰੰਟ ਫੋਟੋ ਸਕ੍ਰੀਨ ਬੰਦ ਰੱਖ ਕੇ, ਇੱਕ ਪਿੱਛੋਂ ਦੀ ਤਸਵੀਰ ਜਿਸ ਵਿੱਚ ਕੋਨਾ ਦਿੱਖ ਰਿਹਾ ਹੈ, ਅਤੇ ਕ੍ਰੈਕ ਦਾ ਨਜ਼ਦੀਕੀ-ਸ਼ਾਟ ਲੈਂਦਾ ਹੈ। IT ਲਈ ਮੁਰammat ਸ਼ੁਰੂ ਕਰਨ ਲਈ ਇਹ ਕਾਫੀ ਹੈ ਬਿਨਾਂ ਵਿਦਿਆਰਥੀ ਡੇਟਾ ਇਕੱਠਾ ਕੀਤੇ।

ਹਰ ਵਾਰੀ ਪਾਲਣ ਲਈ ਇੱਕ ਸਾਦਾ ਮਰammat ਵਰਕਫਲੋ

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

ਕੁਝ ਸਥਿਤੀਆਂ ਦੀ ਇੱਕ ਛੋਟੀ ਲਿਸਟ ਵਰਤੋ, ਅਤੇ ਹਰ ਬਦਲਾਅ ਲਈ ਇੱਕ ਮਾਲਿਕ ਨਿਯਤ ਕਰੋ:

• Reported (ਅਧਿਆਪਕ ਜਾਂ ਸਟਾਫ਼ ਫਾਰਮ ਪੇਸ਼ ਕਰਦਾ ਹੈ)
• Collected (ਦਫ਼ਤਰ ਜਾਂ ਨਿਯਤ ਰਨਰ ਪਿਕਅੱਪ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ)
• Diagnosing (IT ਜਾਂਚ ਕਰਦਾ ਹੈ ਕਿ ਕੀ ਖਰਾਬ ਹੈ ਅਤੇ ਅਗਲਾ ਕਦਮ ਕੀ ਹੋਵੇਗਾ)
• Sent for repair (IT ਜਾਂ ਵੈਂਡਰ ਸ਼ਿਪਮੈਂਟ ਜਾਂ ਡ੍ਰੌਪ-ਆਫ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ)
• Ready (IT ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ ਕਿ ਇਹ ਵਾਪਸ ਆ ਗਿਆ, ਟੈਸਟ ਹੋਇਆ, ਅਤੇ ਚਾਰਜ ਕੀਤਾ ਗਿਆ)
• Returned (ਅਧਿਆਪਕ ਜਾਂ ਵਿਦਿਆਰਥੀ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ ਕਿ ਉਨ੍ਹਾਂ ਨੇ ਇਹ ਪ੍ਰਾਪਤ ਕੀਤਾ)
• Closed (IT ਟਿਕਟ ਨੂੰ ਡਾਕਯੂਮੈਂਟੇਸ਼ਨ ਪੂਰੀ ਹੋਣ 'ਤੇ ਬੰਦ ਕਰਦਾ ਹੈ)

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

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

ਨੋਟਸ ਇਕ ਸਥਾਨ ਵਿੱਚ ਰੱਖੋ, ਸਥਿਤੀ ਦੇ ਉਹੀ ਰਿਕਾਰਡ ਵਿੱਚ। ਵੈਂਡਰ ਕੋਟਸ, ਮਰammat ਫੈਸਲੇ, ਅਤੇ “ਮਾਪੇ ਨੂੰ ਕਾਲ ਕੀਤਾ” ਅੱਪਡੇਟਸ ਨੂੰ ਇੱਥੇ ਰੱਖੋ, ਈਮੇਲ ਥ੍ਰੈੱਡ ਵਿੱਚ ਨਹੀਂ।

ਫਾਰਮ ਅਤੇ ਇੰਟੇਕ ਪ੍ਰਕਿਰਿਆ: ਕਦਮ-ਦਰ-ਕਦਮ

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

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

ਇੱਕ ਸਾਦਾ ਲਾਜ਼ਮੀ ਸੈੱਟ ਆਮ ਤੌਰ 'ਤੇ ਚੰਗਾ ਕੰਮ ਕਰਦਾ ਹੈ:

• ਡਿਵਾਈਸ ID ਜਾਂ ਐਸੈੱਟ ਟੈਗ (ਨਾਲ ਮੌਜੂਦਾ ਟਿਕਾਣਾ)
• ਰਿਪੋਰਟਰ ਦਾ ਨਾਮ ਅਤੇ ਭੂਮਿਕਾ (ਅਧਿਆਪਕ, ਸਹਾਇਕ, ਵਿਦਿਆਰਥੀ)
• ਕੀ ਖਰਾਬ ਹੈ (ਛੋਟੀ ਲਿਸਟ ਵਿੱਚੋਂ ਚੁਣੋ, ਫਿਰ ਨੋਟ ਜੋੜੋ)
• ਕਦੋਂ ਮਿਲਿਆ ਅਤੇ ਹੁਣ ਕਿੱਥੇ ਹੈ (ਕਾਰਟ, ਕਲਾਸਰੂਮ, ਦਫ਼ਤਰ)
• ਤਾਤਕਾਲਤਾ (ਕੀ ਇਹ ਅੱਜ ਵਰਤੀ ਜਾ ਸਕਦੀ ਹੈ: ਹਾਂ/ਨਹੀਂ)

ਫੋਟੋ ਅਪਲੋਡ ਲਈ ਇੱਕ ਸਪਸ਼ਟ ਸੀਮਾ ਜੋੜੋ। ਦੋ ਤੋਂ ਤਿੰਨ ਫੋਟੋ ਆਮ ਤੌਰ 'ਤੇ ਕਾਫੀ ਹੁੰਦੀਆਂ ਹਨ: ਇੱਕ ਪੂਰਾ ਡਿਵਾਈਸ, ਇੱਕ ਨਜ਼ਦੀਕੀ ਨੁਕਸਾਨ, ਅਤੇ (ਜੇ ਲੋੜ ਹੋਵੇ) ਸਮੱਸਿਆ ਦਿਖਾਉਂਦੀ ਸਕ੍ਰੀਨ। ਅਪਲੋਡ ਤੀਜ਼ ਰਹਿਣ ਲਈ ਸਾਈਜ਼ ਲਿਮਿਟ ਰੱਖੋ ਤਾਂ ਕਿ ਸਕੂਲ Wi-Fi 'ਤੇ ਵੀ ਫਾਸਟ ਰਹੇ।

ਜਦੋਂ ਫਾਰਮ ਸਬਮਿਟ ਹੁੰਦਾ ਹੈ, ਤੁਰੰਤ ਇੱਕ ਟਿਕਟ ਨੰਬਰ ਅਤੇ ਮਾਲਿਕ ਨਿਯਤ ਕਰੋ। ਪਹਿਲਾਂ ਇਹ “IT ਕਿਊ” ਹੋ ਸਕਦਾ ਹੈ, ਫਿਰ ਕਿਸੇ ਵਿਅਕਤੀਗਤ ਟੈਕਨਿਸ਼ਨ ਨੂੰ ਰੀਅਸਾਇਨ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਮੁੱਖ ਗੱਲ ਇਹ ਹੈ ਕਿ ਹਰ ਰਿਪੋਰਟ ਦਾ ਇੱਕ ਘਰ ਹੋਵੇ, ਭਾਵੇਂ ਮਰammatੋਂ ਪਹਿਲਾਂ।

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

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

ਉਦਾਹਰਣ: ਇੱਕ ਅਧਿਆਪਕ Chromebook ਕਾਰਟ ਦੇ QR ਨੂੰ ਸਕੈਨ ਕਰਦਾ ਹੈ, ਇੱਕ ਕ੍ਰੈਕ ਹੋਏ ਹੀੰਜ ਦੀਆਂ ਦੋ ਫੋਟੋਆਂ ਸਬਮਿਟ ਕਰਦਾ ਹੈ, ਅਤੇ ਟਿਕਟ #1047 ਮਿਲਦਾ ਹੈ। ਡਿਵਾਈਸ ਦਫਤਰ ਬਿਨ ਵਿੱਚ ਰੱਖ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ, ਤੇ IT ਤੁਰੰਤ ਖੁੱਲ੍ਹੀ ਸੂਚੀ 'ਚ ਦੇਖ ਸਕਦਾ ਹੈ ਬਜਾਏ ਇਸਦੇ ਕਿ ਇਹ ਹਫ਼ਤਿਆਂ ਤੱਕ ਕਲਾਸਰੂਮ ਕੋਨੇ ਵਿੱਚ ਪੈ ਰਹੇ।

ਮਰammat ਟਰੈੱਕਿੰਗ ਤਾਂ ਕਿ ਕੁਝ ਰੁਕੇ ਨਾ

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

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

IT ਲਈ ਇਕ ਡੂੰਘੀ ਦ੍ਰਿਸ਼ਟੀ ਲੋੜੀਦੀ ਹੈ ਤਾਂ ਕਿ ਅਚਾਨਕ ਖਰਚੇ ਜਾਂ ਦੁਹਰਾਈ ਕੰਮ ਦੂਰ ਰਹਿਣ। ਉਹੀ ਰਿਕਾਰਡ ਵਿੱਚ ਖੇਤਰ ਜੋ ਫੈਸਲੇ ਵਿੱਚ ਮਦਦ ਕਰਨ: ਪ੍ਰਾਇਰਿਟੀ (ਕਲਾਸਰੂਮ-ਆਵਸ਼ਯਕ ਮੁਕਾਬਲਾ ਕਰਨ ਵਾਲਾ), ਲੋੜੀਂਦੇ ਪਾਰਟ ਅਤੇ ਕੀ ਉਹ ਆਰਡਰ ਹੋ ਚੁੱਕੇ, ਮਰammat ਮਾਰਗ (ਇਨ-ਹਾਊਸ vs ਬਾਹਰੀ), ਵਾਰੰਟੀ ਨੋਟਸ, ਅਤੇ ਛੋਟਾ ਟੈਕ ਨੋਟਸ।

ਲਗਤ ਅਤੇ ਸਮਾਂ ਦਰਜ ਕਰਨ ਲਈ ਤੇਜ਼ ਰੇਂਜੇ ਵਰਤੋ (0 ਤੋਂ 15 ਮਿੰਟ, 15 ਤੋਂ 60, 1 ਤੋਂ 3 ਘੰਟੇ) ਅਤੇ ਇੱਕ ਸਿਰਫ਼ ਪਾਰਟਾਂ ਲਈ ਖਰਚ ਫੀਲਡ। ਜੇ ਬਾਅਦ ਵਿੱਚ ਸਹੀ ਨੰਬਰ ਚਾਹੀਦੇ ਹੋਣ, ਤਾਂ IT ਉਹਨਾਂ ਨੂੰ ਬੰਦ ਕਰਨ ਵੇਲੇ ਭਰ ਸਕਦਾ ਹੈ।

ਸਟਾਲ ਹੋਏ ਸਥਿਤੀਆਂ ਨੂੰ ਰਿਮਾਈਂਡਰ ਟ੍ਰਿਗਰ ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ। ਇੱਕ ਸਧਾਰਨ ਨਿਯਮ: ਜੇ 3 ਸਕੂਲ ਦਿਨਾਂ ਵਿੱਚ ਕੋਈ ਅਪਡੇਟ ਨਹੀਂ, ਤਾਂ ਡਿਵਾਈਸ ਮਾਲਿਕ ਅਤੇ IT ਨੂੰ ਸੂਚਿਤ ਕਰੋ; ਜੇ 7 ਦਿਨ ਬੀਤ ਜਾਂਦੇ ਹਨ, ਤਾਂ ਐਡਮਿਨ ਸਮੀਖਿਆ ਲਈ ਫਲੈਗ ਕਰੋ।

ਹਰ ਟਿਕਟ ਨੂੰ ਇੱਕ ਸਪੱਸ਼ਟ ਨਤੀਜੇ ਨਾਲ ਬੰਦ ਕਰੋ: repaired and returned, replaced, loaner issued, sent to vendor, or written off. ਇਹ ਅਖੀਰੀ ਕਦਮ ਹੀ ਉਹ Accountability ਬਣਾਉਂਦਾ ਹੈ ਜੋ ਕਿਸੇ ਰਿਪੋਰਟ ਨੂੰ ਅਸਲ ਜਵਾਬਦੇਹ ਬਣਾਉਂਦਾ ਹੈ।

ਭੂਮਿਕਾਵਾਂ, ਐਕਸੈੱਸ, ਅਤੇ ਵਿਦਿਆਰਥੀਆਂ ਬਾਰੇ ਕੀ ਦਰਜ ਕਰਨਾ ਹੈ

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

ਜ਼ਿਆਦਾਤਰ ਸਕੂਲਾਂ ਲਈ, ਇਹ ਭੂਮਿਕਾਵਾਂ ਸਪਸ਼ਟ ਰੱਖਦੀਆਂ ਹਨ:

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

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

ਦਰਜ ਕਰੋ: ਵਿਦਿਆਰਥੀ ਦਾ ਨਾਮ (ਜਾਂ ID), ਗਰੇਡ ਜਾਂ ਹੋਮਰੂਮ, ਡਿਵਾਈਸ ਐਸੈੱਟ ਟੈਗ/ਸੀਰੀਅਲ, ਤਾਰੀਖ/ਸਮਾਂ, ਟਿਕਾਣਾ, ਅਤੇ ਜੋ ਨੋਟਿਸ ਕੀਤਾ ਗਿਆ ਉਸਦੀ ਛੋਟੀ ਵਰਣਨਾ।

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

ਪ੍ਰਤੀਰਕ ਨੀਤੀ ਲਗਾਓ ਅਤੇ ਲਿਖੋ। ਇੱਕ ਆਮ ਤਰੀਕਾ ਇਹ ਹੈ ਕਿ ਰਿਪੋਰਟ ਨੂੰ ਮਰammat ਬੰਦ ਹੋਣ ਤਕ ਰੱਖੋ, ਫਿਰ ਇੱਕ ਨਿਰਧਾਰਿਤ ਸਮੇਂ ਲਈ ਰੱਖੋ (ਉਦਾਹਰਣ ਲਈ, ਸਕੂਲ ਸਾਲ ਦੇ ਬਾਕੀ ਸਮੇਂ)। ਫੋਟੋਆਂ ਦੀ ਮਿਆਦ ਛੋਟੀ ਹੋ ਸਕਦੀ ਹੈ, ਜਿਵੇਂ ਬੰਦ ਕਰਨ ਤੋਂ 30 ਤੋਂ 90 ਦਿਨਾਂ ਬਾਅਦ ਮਿਟਾਉਣਾ ਜੇਕਰ ਕੋਈ ਵਿਵਾਦ ਨਾ ਹੋਵੇ।

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

ਆਮ ਗਲਤੀਆਂ ਜੋ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਖਰਾਬ ਕਰਦੀਆਂ ਹਨ

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

ਪਹਿਲੀ ਨਾਕਾਮੀ ਇਹ ਹੈ ਕਿ ਹਰ ਵਾਰੀ ਇੱਕ ਵਿਲੱਖਣ ਡਿਵਾਈਸ ID ਵਰਤਿਆ ਨਾ ਜਾਵੇ। ਜੇ ਰਿਪੋਰਟ ਕਹਿੰਦੀ ਹੈ “Room 12 ਤੋਂ iPad” ਬਜਾਏ ਐਸੈੱਟ ਟੈਗ ਜਾਂ ਸੀਰੀਅਲ ਨੰਬਰ ਦੇ, ਤਾਂ ਗਲਤ ਡਿਵਾਈਸ ਦੀ ਮੁਰammat ਹੋ ਸਕਦੀ ਹੈ, ਜਾਂ ਬਦਲੀ ਗਲਤ ਕਹਾਣੀ ਵਿੱਚ ਮਿਕਸ ਹੋ ਸਕਦੀ ਹੈ। ਇਹੀ ਤਰੀਕਾ ਹੈ ਜਿਸ ਨਾਲ ਡਿਵਾਈਸ “ਗੁੰਮ” ਹੋ ਜਾਂਦੇ ਹਨ ਹਾਲਾਂਕਿ ਹਰ ਕੋਈ ਠੀਕ ਕੰਮ ਕਰ ਰਿਹਾ ਸੀ।

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

ਜੋ ਗਲਤੀਆਂ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਹਲਚਲ ਪੈਦਾ ਕਰਦੀਆਂ ਹਨ ਉਹ ਆਮ ਤੌਰ 'ਤੇ ਇਕੋ ਜਿਹੀਆਂ ਹਨ:

• ਰਿਪੋਰਟ ਪੇਸ਼ ਕੀਤੀ ਗਈ, ਪਰ ਡਿਵਾਈਸ ਕਦੇ ਇਕੱਠੀ ਨਹੀਂ ਕੀਤਾ ਜਾਂਦਾ ਜਾਂ ਲੇਬਲ ਨਹੀਂ ਕੀਤਾ ਜਾਂਦਾ
• ਸਥਿਤੀ ਅਪਡੇਟਸ ਚੈਟ ਜਾਂ ਈਮੇਲ ਵਿੱਚ ਹੁੰਦੀਆਂ ਹਨ, ਟਰੈਕਿੰਗ ਰਿਕਾਰਡ ਵਿੱਚ ਨਹੀਂ
• ਲੋਨਰਾਂ ਨੂੰ ਲੌਗ ਕੀਤੇ ਬਿਨਾਂ ਦੇ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ
• ਟਿਕਟ ਬੰਦ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ ਬਿਨਾਂ ਦਰਜ ਕੀਤੇ ਕਿ ਡਿਵਾਈਸ ਕਿੱਥੇ ਖਤਮ ਹੋਇਆ (returned, swapped, recycled)
• ਇੱਕੋ ਘਟਨਾ ਲਈ ਕਈ ਲੋਕ ਵੱਖ-ਵੱਖ ਰਿਪੋਰਟਾਂ ਕਰਦੇ ਹਨ, ਟਾਈਮਲਾਈਨ ਸੁੱਟ ਜਾਂਦੀ ਹੈ

ਇੱਕ ਛੋਟੀ ਉਦਾਹਰਣ: ਵਿਦਿਆਰਥੀ ਨੇ ਮੈਥ ਦੌਰਾਨ ਟੈਬਲੇਟ ਦੀ ਸਕ੍ਰੀਨ ਤੋੜ ਦਿੱਤੀ। ਅਧਿਆਪਕ ਇੱਕ ਵਿਦਿਆਰਥੀ ਡਿਵਾਈਸ ਇਨਸਿਡੈਂਟ ਰਿਪੋਰਟ ਕਰਦਾ ਹੈ ਪਰ ਡਿਵਾਈਸ ਕਾਰਟ 'ਤੇ ਛੱਡ ਦਿੰਦਾ ਹੈ। IT ਬਾਅਦ ਵਿੱਚ ਇੱਕ ਹੋਰ ਸਮਾਨ ਕੇਸ ਵਾਲਾ ਟੈਬਲੇਟ ਚੁੱਕ ਲੈਂਦਾ, ਉਸਨੂੰ ਮੁਰammat ਕਰਦਾ, ਅਤੇ ਵਾਪਸ ਕਰਦਾ। ਅਸਲੀ ਕ੍ਰੈਕ ਕੀਤਾ ਡਿਵਾਈਸ ਕਲਾਸਰੂਮ ਵਿੱਚ ਰਹਿ ਜਾਂਦਾ ਹੈ ਅਤੇ ਹੁਣ ਕੋਈ ਸਾਬਤ ਨਹੀਂ ਕਰ ਸਕਦਾ ਕਿ ਕੌਣ-ਕੌਣਸਾ ਡਿਵਾਈਸ ਨੁਕਸਾਨੀਹੀ ਸੀ।

ਜੇ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ ਕਿ ਸਕੂਲਾਂ ਲਈ ਡਿਵਾਈਸ ਮਰammat ਟਰੈਕਿੰਗ ਟਿਕੇ ਰਹੇ, ਤਾਂ ਇੱਕ ਛੋਟਾ ਨਿਯਮ ਬਣਾਓ: ਜੇ ਇਹ ਸਿਸਟਮ ਵਿੱਚ ਨਹੀਂ ਹੈ, ਤਾਂ ਇਹ ਨਹੀਂ ਹੋਇਆ। ਫਿਰ ਹਰ ਵਾਰੀ ਉਸ ਨਿਯਮ ਨੂੰ ਆਸਾਨ ਬਣਾਓ ਤਾਂ ਲੋਕ ਉਸਨੂੰ ਪਾਲਣ।

ਸਟਾਫ਼ ਅਤੇ IT ਲਈ ਤੇਜ਼ ਚੈੱਕਲਿਸਟ

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

ਸਟਾਫ਼ ਇੰਟੇਕ (ਅਧਿਆਪਕ, ਸਹਾਇਕ, ਫਰੰਟ ਦਫ਼ਤਰ)

• ਥੀਕ ਥਾਂ ਤੇ ਡਿਵਾਈਸ ID ਪੁਸ਼ਟੀ ਕਰੋ: ਪਹਿਲਾਂ ਐਸੈੱਟ ਟੈਗ, ਫਿਰ ਸੀਰੀਅਲ ਨੰਬਰ ਜੇ ਟੈਗ ਗਾਇਬ ਜਾਂ ਅਪੜਣਯੋਗ ਹੋਵੇ।
• ਉਪਯੋਗੀ ਫੋਟੋਆਂ ਲਵੋ: ਘੱਟੋ-ਘੱਟ ਦੋ ਸਾਫ਼ ਸ਼ਾਟ (ਇੱਕ ਵਿਆਪਕ, ਇੱਕ ਨਜ਼ਦੀਕੀ)।
• ਹਿਰਾਸਤ ਅਤੇ ਪਿਕਅੱਪ ਵੇਰਵੇ ਦਰਜ ਕਰੋ: ਆਖ਼ਰੀ ਕਿਸ ਕੋਲ ਸੀ, ਕਿੱਥੋਂ ਇਕੱਠਾ ਕੀਤਾ ਗਿਆ, ਅਤੇ ਤਾਰੀਖ/ਸਮਾਂ।
• ਫਾਰਮ ਸਬਮਿਟ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਅਗਲਾ ਕਦਮ ਫੈਸਲਾ ਕਰੋ: ਕਿੱਥੇ ਰੱਖਿਆ ਜਾਵੇਗਾ ਅਤੇ ਕਿਸ ਨੂੰ ਹਵਾਲਾ ਕੀਤਾ ਜਾਵੇਗਾ।
• ਜੇ ਤੁਸੀਂ ਲੋਨਰ ਜਾਰੀ ਕਰੋ, ਤੁਰੰਤ ਲੌਗ ਕਰੋ: ਲੋਨਰ ID, ਵਿਦਿਆਰਥੀ ਦਾ ਨਾਮ, ਅਤੇ ਉਮੀਦਿਤ ਵਾਪਸੀ ਤਾਰੀخ।

ਫਾਰਮ ਸਬਮਿਟ ਹੋਣ ਤੋਂ ਬਾਅਦ, ਡਿਵਾਈਸ ਨੂੰ ਕਦੇ “ਅਸਾਇਨ ਨਾ ਛੱਡੋ।” ਜੇ ਅਗਲਾ ਕਦਮ ਕਿਸੇ ਦੇ ਕੋਲ ਨਹੀਂ, ਤਾਂ ਇਹ ਪੈ ਹੋ ਜਾਏਗਾ।

IT ਟਰੈਕਿੰਗ (ਮਰammat, ਵਾਰੰਟੀ, ਵਾਪਸੀ)

• ਇੱਕ ਮੌਜੂਦਾ ਸਥਿਤੀ ਅਤੇ ਇੱਕ ਇਕੱਲਾ ਮਾਲਿਕ ਨਿਯਤ ਕਰੋ (triage, waiting on parts, vendor repair, ready for pickup).
• ਅਗਲੀ ਅਪਡੇਟ ਦੀ ਤਾਰੀਖ ਨੋਟ ਕਰੋ, ਭਾਵੇਂ ਕੁਝ ਬਦਲੇ ਨਾ ਵੀ ਹੋਵੇ।
• ਫੈਸਲੇ ਦਾ ਮਾਰਗ ਦਰਜ ਕਰੋ: in-house repair, vendor, warranty claim, ਜਾਂ retire and replace.
• ਮੂਲ ਫੋਟੋਆਂ ਜੁੜੀਆਂ ਰੱਖੋ ਅਤੇ ਮਰammat ਦੇ ਬਾਅਦ ਨਵੇਂ ਸ਼ਾਟ ਜੋੜੋ ਜੇ ਹਾਲਤ ਬਦਲੀ ਹੋਈ ਹੋਵੇ।
• ਜਦੋਂ ਇਹ ਵਾਪਸ ਹੋਵੇ, ਲੂਪ ਬੰਦ ਕਰੋ: ਵਾਪਸੀ ਤਾਰੀਖ, ਜਿਸਨੇ ਪ੍ਰਾਪਤ ਕੀਤਾ, ਅਤੇ ਕਿੱਥੇ ਗਿਆ।

ਉਦਾਹਰਣ: ਇੱਕ ਖਰਾਬ ਟੈਬਲੇਟ ਰਿਪੋਰਟ ਤੋਂ ਵਾਪਸੀ ਤੱਕ

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

ਦੋ ਮਿੰਟ ਤੋਂ ਘੱਟ ਸਮੇਂ ਵਿੱਚ, ਅਧਿਆਪਕ ਆਪਣੇ ਫੋਨ 'ਤੇ ਕਲਾਸਰੂਮ ਡਿਵਾਈਸ ਨੁਕਸਾਨ ਰਿਪੋਰਟ ਫਾਰਮ ਭਰਦਾ ਹੈ। ਉਹ ਐਸੈੱਟ ਟੈਗ ਦਰਜ ਕਰਦਾ ਹੈ, ਟਿਕਾਣਾ (Room 214) ਚੁਣਦਾ ਹੈ, ਅਤੇ ਇੱਕ ਸਪਸ਼ਟ ਵਾਕ ਲਿਖਦਾ ਹੈ: “ਲੈਬ ਕਲੀਨਅੱਪ ਤੋਂ ਬਾਅਦ ਸਕ੍ਰੀਨ ਕ੍ਰੈਕ, ਟਚ ਅਕਸਰ ਦਿੱਖਦਾ ਹੈ।” ਉਹ ਦੋ ਫੋਟੋ ਜੋੜਦਾ ਹੈ: ਇੱਕ ਕ੍ਰੈਕ ਦਾ ਨਜ਼ਦੀਕੀ-ਸ਼ਾਟ ਅਤੇ ਇੱਕ ਵਿਆਪਕ ਸ਼ਾਟ ਜੋ ਪੂਰੇ ਫਰੰਟ ਨੂੰ ਦਿਖਾਉਂਦਾ ਹੈ। ਕਿਸੇ ਵੀ ਵਿਦਿਆਰਥੀ ਦਾ ਚਿਹਰਾ ਫਰੇਮ ਵਿੱਚ ਨਹੀਂ ਹੈ।

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

IT ਆਪਣੀ ਰੋਜ਼ਾਨਾ ਰਾਊਂਡ ਦੌਰਾਨ ਖਰਾਬ ਟੈਬਲੇਟ ਉਠਾ ਲੈਂਦਾ ਹੈ। ਟਰੈਕਿੰਗ ਰਿਕਾਰਡ ਵਿੱਚ ਉਹ ਸਥਿਤੀ ਨੂੰ “Received” ਤੋਂ “Diagnosing” 'ਚ ਮੋੜਦਾ ਹੈ ਅਤੇ ਛੋਟੇ ਨੋਟਾਂ ਜੋੜਦਾ ਹੈ:

• Screen cracked, needs replacement
• Touch issues likely due to digitizer damage
• Parts needed: screen assembly for this model
• Estimated return: 3 to 5 school days

ਜਦੋਂ ਪਾਰਟ ਆ ਜਾਂਦਾ ਹੈ, IT ਸਥਿਤੀ ਨੂੰ “Repair in progress” ਤੇ ਫਿਰ ਟੈਸਟਿੰਗ ਪੂਰੀ ਹੋਣ 'ਤੇ “Ready for return” ਕਰ ਦਿੰਦਾ ਹੈ। ਦਫ਼ਤਰ ਮੂਲ ਡਿਵਾਈਸ ਵਾਪਸ ਚੁੱਕਦਾ, ਲੋਨਰ ਦੀ ਵਾਪਸੀ ਪੱਕੀ ਕਰਦਾ, ਅਤੇ ਰਿਕਾਰਡ ਨੂੰ ਵਾਪਸੀ ਦੀ ਤਾਰੀਖ ਅਤੇ ਅੰਤਿਮ ਨੋਟਸ ਨਾਲ ਬੰਦ ਕਰਦਾ। ਕੁਝ ਵੀ ਢੇਰ ਵਿੱਚ ਨਹੀਂ ਰਹਿ ਜਾਂਦਾ, ਅਤੇ ਹਰ ਕਿਸੇ ਨੂੰ ਹਰ ਕਦਮ ਦਾ ਪਤਾ ਹੁੰਦਾ ਹੈ।

ਅਗਲੇ ਕਦਮ: ਰੋਲਆਉਟ ਕਰੋ ਅਤੇ ਸਮਾਂ-ਸਮਾਂ 'ਤੇ ਸੁਧਾਰ ਕਰੋ

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

ਇੱਕ ਮਜ਼ਬੂਤ ਬੇਸਲਾਈਨ ਇਹ ਹੋ ਸਕਦੀ ਹੈ:

• ਇੱਕ ਨੁਕਸਾਨ ਰਿਪੋਰਟ ਫਾਰਮ (ਵਿਦਿਆਰਥੀ, ਡਿਵਾਈਸ ID, ਕੀ ਹੋਇਆ, ਕਦੋਂ, ਕਿੱਥੇ)
• ਫੋਟੋ ਅਪਲੋਡ (2 ਤੋਂ 4 ਸਾਫ਼ ਸ਼ਾਟ)
• ਸਥਿਤੀਆਂ ਜਿਵੇਂ New, In Review, Sent to Repair, Waiting on Parts, Ready to Return
• ਇੱਕ ਸਰਲ ਡੈਸ਼ਬੋਰਡ ਜਾਂ ਸਪ੍ਰੈਡਸ਼ੀਟ ਵਿਊ ਜੋ IT ਛਾਂਟੀ ਅਤੇ ਫਿਲਟਰ ਕਰ ਸਕੇ

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

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

ਪਾਇਲਟ ਤੋਂ ਬਾਅਦ ਦੇਖੋ ਕਿ ਲੋਕ ਕਿਹੜੇ ਫੀਲਡ ਛੱਡਦੇ ਹਨ। ਜੇ ਕੋਈ ਫੀਲਡ ਅਕਸਰ ਖਾਲੀ ਰਹਿੰਦੀ ਹੈ, ਤਾਂ ਫੈਸਲਾ ਕਰੋ ਕਿ ਕੀ ਇਹ ਸਚਮੁਚ ਲੋੜੀਦੀ ਹੈ, ਇਸਨੂੰ ਡ੍ਰੌਪਡਾਊਨ ਬਣਾਉਣਾ ਚਾਹੀਦਾ ਹੈ, ਜਾਂ ਇਹ IT ਲਈ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ ਨਾ ਕਿ ਅਧਿਆਪਕਾਂ ਲਈ। ਛੋਟੇ ਤਬਦੀਲੀਆਂ, ਜਿਵੇਂ ਛੋਟੇ ਵਿਕਲਪ ਅਤੇ ਘੱਟ_REQUIRED_ ਫੀਲਡ, ਪੂਰੇ ਪੂਰਨਤਾ ਦਰ ਨੂੰ ਜਲਦੀ ਵਧਾ ਸਕਦੇ ਹਨ।

ਜੇ ਤੁਹਾਡੇ ਸਕੂਲ ਨੂੰ ਫਾਰਮਾਂ ਅਤੇ ਸ਼ੀਟਾਂ ਦੀ ਥਾਂ ਇੱਕ ਕਸਟਮ ਅੰਦਰੂਨੀ ਟੂਲ ਚਾਹੀਦਾ ਹੈ, ਤਾਂ ਇੱਕ ਵਿਕਲਪ ਇਹ ਹੈ ਕਿ Koder.ai 'ਤੇ ਚੈਟ ਰਾਹੀਂ ਆਪਣੇ ਵਰਕਫਲੋ ਦੀ ਵਰਣਨਾ ਕਰਕੇ ਇੱਕ ਛੋਟਾ ਟਰੈਕਰ ਬਣਾਇਆ ਜਾਵੇ, ਫਿਰ ਸੋਰਸ ਕੋਡ ਨਿਰਯਾਤ ਕਰਕੇ ਆਪਣੇ IT ਟੀਮ ਨੂੰ ਦੇ ਦਿੱਤਾ ਜਾਵੇ। ਇਹ ਭੂਮਿਕਾਵਾਂ, ਮਰammat ਸਥਿਤੀ ਟਰੈਕਿੰਗ, ਅਤੇ ਖੋਜਯੋਗ ਇਤਿਹਾਸ ਨੂੰ ਇੱਕ ਥਾਂ ਰੱਖਣ ਦਾ ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਤਰੀਕਾ ਹੈ।