ਸਿੱਖੋ ਕਿ ਕਿਵੇਂ ਯੋਜਨਾ ਬਣਾਈਏ, ਡਿਜ਼ਾਈਨ ਅਤੇ ਤਿਆਰ ਕਰੋ ਇੱਕ ਵੈੱਬ ਐਪ ਜੋ ਗ੍ਰਾਹਕਾਂ ਦੀ ਕੋਰਸ ਰਜਿਸਟ੍ਰੇਸ਼ਨ, ਪ੍ਰਗਤੀ ਅਤੇ ਪੂਰਨਤਾ ਟ੍ਰੈਕ ਕਰੇ—ਨਾਲ ਹੀ ਯਾਦ ਦਿਵਾਉਣ, ਰਿਪੋਰਟਾਂ ਅਤੇ ਸਰਟੀਫਿਕੇਟ।

ਟਰੇਨਿੰਗ ਪੂਰਨਤਾ ਟਰੈਕਿੰਗ ਸਿਰਫ ਇੱਕ ਚੈਕਲਿਸਟ ਨਹੀਂ—ਇਹ ਇੱਕ ਠوس ਓਪਰੇਸ਼ਨਲ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦੀ ਹੈ: ਕਿਸ ਨੇ ਕਿਹੜੀ ਟਰੇਨਿੰਗ ਕੀਤੀ, ਕਦੋਂ, ਅਤੇ ਕਿਸ ਨਤੀਜੇ ਦੇ ਨਾਲ। ਜੇ ਤੁਹਾਡੀ ਟੀਮ ਇਸ ਜਵਾਬ 'ਤੇ ਭਰੋਸਾ ਨਹੀਂ ਕਰ ਸਕਦੀ, ਤਾਂ ਗ੍ਰਾਹਕ ਓਨਬੋਰਡਿੰਗ ਤੇਜ਼ ਨਹੀਂ ਹੋਵੇਗੀ, ਨਵੀਂ ਰੀਨਿਊਅਲਜ਼ ਵਿੱਚ ਜੋਖਮ ਵਧੇਗਾ, ਅਤੇ ਕੰਪਲੀਅੰਸ ਚਰਚਾ ਤਣਾਅਭਰੀ ਹੋ ਜਾਏਗੀ।
ਘੱਟੋ-ਘੱਟ, ਤੁਹਾਡੇ ਲਰਨਿੰਗ ਪ੍ਰਗਤੀ ਵੈੱਬ ਐਪ ਨੂੰ ਆਸਾਨ ਬਣਾਉਣਾ ਚਾਹੀਦਾ ਹੈ:
ਇਹ ਤੁਹਾਡੀ “ਸੋਰਸ ਆਫ਼ ਟਰੂਥ” ਬਣ ਜਾਂਦਾ ਹੈ—ਖਾਸ ਕਰਕੇ ਜਦ ਕਈ ਟੀਮਾਂ (CS, Support, Sales, Compliance) ਨੂੰ ਉਹੀ ਜਾਣਕਾਰੀ ਚਾਹੀਦੀ ਹੋਵੇ।
“ਗ੍ਰਾਹਕ ਟਰੇਨਿੰਗ” ਵakh-ਵੱਖ ਦਰਸ਼ਕਾਂ ਦਾ ਅਰਥ ਹੋ ਸਕਦਾ ਹੈ:
ਪਹਿਲਾਂ ਦਰਸ਼ਕ ਦੀ ਪਛਾਣ ਕਰਨ ਨਾਲ ਹਰ ਚੀਜ਼ 'ਤੇ ਅਸਰ ਪੈਂਦਾ ਹੈ: ਲਾਜ਼ਮੀ ਵਿਰੁੱਧ ਵਿਕਲਪਤ ਕੋਰਸ, ਯਾਦ ਦਿਵਾਉਣ ਦੀ ਰੀਤ, ਅਤੇ “ਕੰਪਲੀਸ਼ਨ” ਦਾ ਅਸਲ ਮਤਲਬ ਕੀ ਹੈ।
ਇੱਕ ਕਾਰਗਰ ਸਿੱਖਿਆ ਪੂਰਨਤਾ ਡੈਸ਼ਬੋਰਡ ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਲੋੜੀਂਦਾ ਹੈ:
“ਇਹ ਕੰਮ ਕਰਦਾ ਹੈ” ਤੋਂ ਅੱਗੇ ਮਾਪਦੰਡ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ:
ਇਹ ਮੈਟ੍ਰਿਕਸ ਤੁਹਾਨੂੰ ਦਿਖਾਉਂਦੇ ਹਨ ਕਿ ਪਹਿਲਾਂ ਕੀ ਬਣਾਉਣਾ ਹੈ—ਅਤੇ ਕਿਹੜੀਆਂ ਚੀਜ਼ਾਂ ਬਾਅਦ ਵਿੱਚ ਛੱਡ ਸਕਦੇ ਹੋ।
ਇੱਕ ਟਰੇਨਿੰਗ-ਕੰਪਲੀਸ਼ਨ ਐਪ ਵਧੇਰੇ ਆਸਾਨੀ ਨਾਲ ਮੈਨੇਜ ਹੋ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਇਹ ਵੱਖਰਾ ਕਰ ਲੈਂਦੇ ਹੋ ਕੌਣ ਕੋਈ ਹੈ (ਉਹਦਾ ਰੋਲ) ਅਤੇ ਕਿਸਦੇ ਨਾਲ ਉਹ ਜੁੜਿਆ ਹੈ (ਉਹਦੀ ਗ੍ਰਾਹਕ ਅਕਾਊਂਟ)। ਇਹ ਰਿਪੋਰਟਿੰਗ ਸਹੀ ਬਣਾਉਂਦਾ ਹੈ, ਅਕਸਮਾਤ ਡਾਟਾ ਲੀਕ ਨੂੰ ਰੋਕਦਾ ਹੈ, ਅਤੇ ਪਰਮੀਸ਼ਨ ਪੇਸ਼ਗੋਈਯੋਗ ਬਣਾਂਦਾ ਹੈ।
Learner
ਲਰਨਰਾਂ ਲਈ ਸਭ ਤੋਂ ਸਧਾਰਣ ਤਜ਼ਰਬਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ: ਅਸਾਈਨ ਕੀਤੇ ਕੋਰਸ ਦੇਖਣਾ, ਟਰੇਨਿੰਗ ਸ਼ੁਰੂ/ਰਿਸਿਊਮ ਕਰਨਾ, ਅਤੇ ਆਪਣੀ ਪ੍ਰਗਤੀ ਅਤੇ ਕੰਪਲੀਸ਼ਨ ਸਥਿਤੀ ਦੇਖਣਾ। ਉਹ ਇਕੋ ਸੰਸਥਾ ਦੇ ਹੋਰ ਲੋਕਾਂ ਦਾ ਡਾਟਾ ਨਹੀਂ ਦੇਖਣਾ ਚਾਹੀਦਾ।
Customer Admin
ਇੱਕ ਕਸਟਮਰ ਐਡਮਿਨ ਆਪਣੀ ਸੰਗਠਨਾ ਲਈ ਟਰੇਨਿੰਗ ਮੈਨੇਜ ਕਰਦਾ ਹੈ: ਲਰਨਰ ਨੂੰ ਨਿਯਤਾ ਕਰਨਾ, ਕੋਰਸ ਅਸਾਈਨ ਕਰਨਾ, ਆਪਣੀ ਟੀਮਾਂ ਲਈ ਕੰਪਲੀਸ਼ਨ ਦੇਖਣਾ, ਅਤੇ ਆਡਿਟ ਲਈ ਰਿਪੋਰਟ ਐਕਸਪੋਰਟ ਕਰਨਾ। ਉਹ ਯੂਜ਼ਰ ਐਟਰੀਬਿਊਟ (ਨਾਂ, ਟੀਮ, ਸਥਿਤੀ) ਸੋਧ ਸਕਦਾ ਹੈ ਪਰ ਗਲੋਬਲ ਕੋਰਸ ਸਮੱਗਰੀ ਬਦਲਣ ਨਹੀਂ ਕਰਨੀ ਚਾਹੀਦੀ, ਜਦ ਤੱਕ ਤੁਸੀਂ ਗਾਹਕ-ਵਿਸ਼ੇਸ਼ ਕੋਰਸ ਸਪੋਰਟ ਨਾ ਕਰੋ।
Internal Admin (ਤੁਹਾਡੀ ਟੀਮ)
ਇੰਟਰਨਲ ਐਡਮਿਨਾਂ ਨੂੰ ਗ੍ਰਾਹਕਾਂ 'ਤੇ ਵਿਸ਼ੇਸ਼ ਦਿੱਖ ਚਾਹੀਦੀ ਹੈ: ਅਕਾਊਂਟ ਮੈਨੇਜ, ਐਕਸੈੱਸ ਟ੍ਰਬਲਸ਼ੂਟ, ਐਨਰੋਲਮੈਂਟ ਸਹੀ ਕਰਨਾ, ਅਤੇ ਗਲੋਬਲ ਰਿਪੋਰਟ ਚਲਾਉਣਾ। ਇਹ ਰੋਲ ਸੰਵੇਦਨਸ਼ੀਲ ਕਾਰਵਾਈਆਂ ਜਿਵੇਂ ਉਪਭੋਗਤਿਆਂ ਨੂੰ ਹਟਾਉਣਾ, ਅਕਾਊਂਟ ਮਰਜ ਕਰਨਾ, ਜਾਂ ਬਿਲਿੰਗ-ਸਬੰਧੀ ਫੀਲਡ ਚੇਨਜ਼ ਕਰਨ ਦੀ ਕਾਬਿਲੀਅਤ ਰੱਖੇ।
Instructor / Content Manager (ਐਚੋਇਸ਼ਨਲ)
ਜੇ ਤੁਸੀਂ ਲਾਈਵ ਸੈਸ਼ਨ ਚਲਾਉਂਦੇ ਹੋ ਜਾਂ ਕੋਰਸ ਸਮੱਗਰੀ ਅਪਡੇਟ ਕਰਨ ਵਾਲਾ ਸਟਾਫ਼ ਹੈ, ਇਹ ਰੋਲ ਕੋਰਸ ਬਣਾਉਣ/ਸੋਧਣ, ਸੈਸ਼ਨ ਮੈਨੇਜ ਕਰਨ ਅਤੇ ਲਰਨਰ ਗਤੀਵਿਧੀ ਦੀ ਸਮੀਖਿਆ ਕਰਨ ਲਈ ਹੋ ਸਕਦਾ ਹੈ। ਆਮ ਤੌਰ 'ਤੇ ਇਨ੍ਹਾਂ ਨੂੰ ਗ੍ਰਾਹਕ ਬਿਲਿੰਗ ਡੇਟਾ ਜਾਂ ਕ੍ਰਾਸ-ਕਸਟਮਰ ਐਨਾਲਿਟਿਕਸ ਨਹੀਂ ਦੇਖਣੇ ਚਾਹੀਦੇ।
ਜ਼ਿਆਦਾਤਰ B2B ਐਪਸ ਇੱਕ ਸਧਾਰਣ ਹਾਇਰਾਰਕੀ ਨਾਲ ਚੰਗੇ ਕੰਮ ਕਰਦੇ ਹਨ:
ਟੀਮਾਂ ਦੈਨਿਕ ਮੈਨੇਜਮੈਂਟ ਵਿੱਚ ਮਦਦ ਕਰਦੀਆਂ ਹਨ; cohorts ਰਿਪੋਰਟਿੰਗ ਅਤੇ ਡੇਡਲਾਈਨ ਲਈ ਮਦਦਗਾਰ ਹੁੰਦੇ ਹਨ।
ਹਰ ਗਾਹਕ ਸੰਗਠਨਾ ਨੂੰ ਇੱਕ ਆਪਣਾ ਸੁਰੱਖਿਅਤ ਕੰਟੇਨਰ ਸਮਝੋ। ਘੱਟੋ-ਘੱਟ:
ਰੋਲ ਅਤੇ ਟੈਨੈਂਸੀ ਸਰਹੱਦ ਪਹਿਲਾਂ ਡਿਜ਼ਾਈਨ ਕਰਨ ਨਾਲ ਬਾਅਦ ਵਿੱਚ ਰਿਪੋਰਟਿੰਗ, ਯਾਦ ਦਿਵਾਉਣ ਅਤੇ ਇੰਟਿਗਰੇਸ਼ਨ ਜੋੜਨ ਵੇਲੇ ਦੁੱਖਦੇ ਰੀ-ਰਾਈਟ ਤੋਂ ਬਚਿਆ ਜਾ ਸਕਦਾ ਹੈ।
ਇੱਕ ਸਪਸ਼ਟ ਡੇਟਾ ਮਾਡਲ ਜ਼ਿਆਦਾਤਰ “ਇਹ ਯੂਜ਼ਰ ਅਧੂਰਾ ਕਿਉਂ ਲੱਗ ਰਿਹਾ ਹੈ?” ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਰੋਕਦਾ ਹੈ। ਕੋਸ਼ਿਸ਼ ਕਰੋ ਕਿ ਤੁਸੀਂ ਸਟੋਰ ਕਰੋ ਕੀ ਅਸਾਈਨ ਕੀਤਾ ਗਿਆ ਸੀ, ਕੀ ਹੋਇਆ, ਅਤੇ ਤੁਸੀਂ ਕਿਉਂ ਇਹ ਪੂਰਾ ਮੰਨ ਰਹੇ ਹੋ—ਬਿਨਾਂ ਅਨੁਮਾਨ ਲਗਾਉਣ ਦੇ।
ਸ਼ੁਰੂਆਤ ਇਸ ਤਰੀਕੇ ਨਾਲ ਕਰੋ ਕਿ ਸਮੱਗਰੀ ਨੂੰ ਵਧਾਈਅਤ ਦੇ ਨਾਲ ਮਾਡਲ ਕੀਤਾ ਜਾਵੇ:
ਜੇ ਤੁਹਾਡਾ MVP ਸਿਰਫ “courses” ਹੈ, ਫਿਰ ਵੀ modules/lessons ਲਈ ਡਿਜ਼ਾਈਨ ਕਰਨਾ ਬਾਅਦ ਵਿਚ ਹੋਣ ਵਾਲੀ ਦੁੱਖਦੀ ਮਾਈਗ੍ਰੇਸ਼ਨ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ।
ਕੰਪਲੀਸ਼ਨ ਸਪਸ਼ਟ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਨੁਮਾਨ ਨਹੀਂ। ਆਮ ਨਿਯਮ:
ਕੋਰਸ ਪੱਧਰ 'ਤੇ ਤੈਅ ਕਰੋ ਕਿ ਪੂਰਨਤਾ ਲਈ ਸਾਰੇ ਲਾਜ਼ਮੀ ਪਾਠ, ਸਾਰੇ ਲਾਜ਼ਮੀ ਮੋਡੀਊਲ, ਜਾਂ N ਵਿੱਚੋਂ M ਆਈਟਮ ਲਾਜ਼ਮੀ ਹਨ। ਜੋ ਨਿਯਮ ਵਰਤਿਆ ਗਿਆ, ਉਹ ਵਰਜ਼ਨ ਸਹਿਤ ਸਟੋਰ ਕਰੋ ਤਾਂ ਕਿ ਜੇ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਟਰੈਸ਼ਹੋਲਡ ਬਦਲੋ ਤਾਂ ਰਿਪੋਰਟਿੰਗ ਅਸਥਿਰ ਨਾ ਹੋਏ।
ਹਰ ਲਰਨਰ ਅਤੇ ਆਈਟਮ ਲਈ ਇੱਕ ਪ੍ਰਗਤੀ ਰਿਕਾਰਡ ਟਰੈਕ ਕਰੋ। ਲਾਭਦਾਇਕ ਫੀਲਡ:
started_at, last_activity_at, completed_atexpires_at (ਸਾਲਾਨਾ ਰੀਨਿਊਅਲ ਜਾਂ ਕੰਪਲੀਅੰਸ ਸਾਈਕਲ ਲਈ)ਇਹ ਯਾਦ ਦਿਵਾਉਣ ("7 ਦਿਨਾਂ ਲਈ ਗਤੀਵਿਧੀ ਨਹੀਂ"), ਨਵੀਨੀਕਰਨ ਰਿਪੋਰਟਿੰਗ, ਅਤੇ ਆਡੀਟ ਟਰੇਲ ਸਮਰਥਨ ਕਰਦਾ ਹੈ।
ਹਰ ਕੰਪਲੀਸ਼ਨ ਲਈ ਕੀ ਸਬੂਤ ਸਟੋਰ ਕਰਨੇ ਹਨ, ਇਹ ਫੈਸਲਾ ਕਰੋ:
ਸਬੂਤ ਨਰਮ ਰੱਖੋ: ਐਪ ਵਿੱਚ ਸਮਰੀ ਅਤੇ ਆਈਡੀ ਰੱਖੋ, ਅਤੇ ਰਾਵ ਆਰਟੀਫੈਕਟ (ਕੁਇਜ਼ ਉੱਤਰ, ਵੀਡੀਓ ਲੌਗ) ਨੂੰ ਸਿਰਫ਼ ਜ਼ਰੂਰਤ ਹੋਵੇ ਤਾਂ ਲਿੰਕ ਕਰੋ।
ਪ੍ਰਮਾਣਿਕਤਾ ਅਤੇ ਐਨਰੋਲਮੈਂਟ ਨੂੰ ਠੀਕ ਰੱਖਣਾ ਲਰਨਰ ਲਈ ਅਨੁਭਵ ਨਰਮ ਬਣਾਂਦਾ ਹੈ ਅਤੇ ਐਡਮਿਨ ਲਈ ਨਿਯੰਤਰਣਯੋਗ। ਲਕਸ਼ ਹੈ friction ਘਟਾਉਣਾ ਬਿਨਾਂ ਇਹ ਗੁਆਚੇ ਕਿ ਕਿਸ ਨੇ ਕੀ ਪੂਰਾ ਕੀਤਾ—ਅਤੇ ਕਿਸ ਗਾਹਕ ਅਕਾਊਂਟ ਹੇਠਾਂ।
MVP ਲਈ ਇੱਕ ਪ੍ਰਾਇਮਰੀ ਸਾਈਨ-ਇਨ ਵਿਕਲਪ ਅਤੇ ਇੱਕ fallback ਚੁਣੋ:
ਵੱਡੇ ਗ੍ਰਾਹਕ ਮੰਗਣ 'ਤੇ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ SSO (SAML/OIDC) ਜੋੜ ਸਕਦੇ ਹੋ। ਹੁਣ ਲਈ identity ਲਚਕੀਲਾ ਰੱਖੋ: ਇੱਕ ਯੂਜ਼ਰ ਇਕੋ ਪ੍ਰੋਫਾਈਲ ਨਾਲ ਕਈ auth ਤਰੀਕਿਆਂ ਨੂੰ ਜੋੜ ਸਕਦਾ ਹੋਵੇ।
ਜ਼ਿਆਦਾਤਰ ਟਰੇਨਿੰਗ ਐਪਸ ਨੂੰ ਤਿੰਨ ਐਨਰੋਲਮੈਂਟ ਰਾਹਾਂ ਦੀ ਲੋੜ ਪੈਂਦੀ ਹੈ:
ਇੱਕ ਵਿਵਹਾਰਕ ਨਿਯਮ: ਹਰ ਐਨਰੋਲਮੈਂਟ ਹਮੇਸ਼ਾ ਰਿਕਾਰਡ ਕਰੇ ਕਿਸਨੇ ਐਨਰੋਲ ਕੀਤਾ, ਕਦੋਂ, ਅਤੇ ਕਿਹੜੇ ਗਾਹਕ ਅਕਾਊਂਟ ਹੇਠਾਂ।
Re-enrollment ਅਤੇ retakes: ਐਡਮਿਨਾਂ ਨੂੰ ਪ੍ਰਗਤੀ ਰੀਸੈੱਟ ਕਰਨ ਜਾਂ ਨਵਾਂ ਅਟੈਂਪਟ ਬਣਾਉਣ ਦੀ ਆਗਿਆ ਦਿਓ। ਇਤਿਹਾਸ ਰੱਖੋ ਤਾਂ ਕਿ ਰਿਪੋਰਟਿੰਗ "ਆਖਰੀ ਅਟੈਂਪਟ" ਵੱਲੋਂ 'ਤੇ ਨਜ਼ਰ ਰੱਖ ਸਕੇ।
Course version updates: ਜਦ ਸਮੱਗਰੀ ਬਦਲਦੀ ਹੈ, ਤੈਅ ਕਰੋ ਕਿ ਕੀ ਪੂਰਨਤਾ ਵੈਧ ਰਹਿੰਦੀ ਹੈ। ਆਮ ਵਿਕਲਪ:
ਜੇ ਤੁਸੀਂ passwords ਵਰਤਦੇ ਹੋ, ਤਾਂ "ਭੁੱਲ ਗਏ ਪਾਸਵਰਡ" ਲਈ ਈਮੇਲ ਰਾਹੀਂ ਛੋਟੇ-ਸਮੇਂ ਵਾਲੇ ਟੋਕਨ, ਰੇਟ ਲਿਮਿਟ ਅਤੇ ਸਪਸ਼ਟ ਸੁਨੇਹੇ ਸਹਾਇਕ ਹਨ। ਜੇ Magic links ਵਰਤਦੇ ਹੋ, ਤਾਂ ਵੀ ਘਟਾਓਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਜੇ ਈਮੇਲ ਬਦਲ ਜਾਵੇ ਤਾਂ ਰਿਕਵਰੀ ਕਿਵੇਂ ਹੋਵੇ—ਆਮ ਤੌਰ 'ਤੇ ਏਡਮਿਨ ਸਹਾਇਤਾ ਜਾਂ ਵੈਰੀਫਾਈਡ ਈਮੇਲ ਬਦਲ ਫਲੋ ਨਾਲ ਨਿਪਟਿਆ ਜਾਂਦਾ ਹੈ।
ਸਭ ਤੋਂ ਵਧੀਆ ਟੈਸਟ: ਕੀ ਇੱਕ ਲਰਨਰ ਇੱਕ ਇਨਵਾਈਟ 'ਤੇ ਇਕ ਮਿੰਟ ਤੋਂ ਘੱਟ ਵਿੱਚ ਕੋਰਸ ਜੁੜ ਸਕਦਾ ਹੈ, ਅਤੇ ਕੀ ਐਡਮਿਨ ਗਲਤੀਆਂ (ਗਲਤ ਈਮੇਲ, ਗਲਤ ਕੋਰਸ, ਰੀਟੇਕ) ਇੰਜੀਨੀਅਰਿੰਗ ਮਦਦ ਬਿਨਾਂ ਠੀਕ ਕਰ ਸਕਦਾ ਹੈ?
ਇੱਕ ਟਰੇਨਿੰਗ ਟਰੈਕਰ ਤਦ ਹੀ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦ ਲਰਨਰ ਤੇਜ਼ੀ ਨਾਲ ਸਮਝ ਸਕਣ ਕਿ ਉਹਨਾਂ ਨੂੰ ਅਗਲਾ ਕੀ ਕਰਨਾ ਹੈ—ਬਿਨਾਂ ਮੇਨੂਜ ਦੇਖਣ ਜਾਂ "ਪੂਰਾ" ਦਾ ਅਰਥ ਜਾਣਨ ਲਈ ਅਟਕਣ। ਲਰਨਰ ਅਨੁਭਵ ਨੂੰ ਫੈਸਲਾ ਘਟਾਉਣ ਅਤੇ ਗਤੀ ਬਣਾਈ ਰੱਖਣ ਲਈ ਡਿਜ਼ਾਈਨ ਕਰੋ।
ਇੱਕ ਹੀ ਹੋਮ ਸਕ੍ਰੀਨ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਤਿੰਨ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਦੇ:
ਅਸਾਈਨ ਕੀਤੇ ਟਰੇਨਿੰਗ ਕਾਰਡ ਜਾਂ ਰੋਜ਼ ਵਜੋਂ ਦਿਖਾਓ:
ਜੇ ਤੁਹਾਨੂੰ ਕੰਪਲੀਅੰਸ ਦੀ ਲੋੜ ਹੈ ਤਾਂ ਸਥਿਤੀ ਦੇ ਨਿਸ਼ਾਨ ਜਿਵੇਂ “Overdue” ਜਾਂ “Due in 3 days” ਜੁੜੋ, ਪਰ ਡਰਾਉਣ ਵਾਲਾ UI ਨਾ ਬਣਾਓ।
ਜ਼ਿਆਦਾਤਰ ਗਾਹਕ ਮੀਟਿੰਗਾਂ ਵਿਚ ਜਾਂ ਛੋਟੇ ਸਮੇਂ ਲਈ ਸਿਖਣਗے। ਪਲੇਅਰ ਨੂੰ resume-first ਬਣਾਓ: ਆਖਰੀ ਅਣਪੂਰਾ ਕਦਮ 'ਤੇ ਖੁਲਣਾ ਅਤੇ ਨੈਵੀਗੇਸ਼ਨ ਸਪਸ਼ਟ ਰੱਖਣਾ।
ਵਿਆਵਹਾਰਿਕ ਜ਼ਰੂਰੀ ਚੀਜ਼ਾਂ:
ਕੋਰਸ ਦੇ ਸ਼ੀਰਸ਼ ਤੇ (ਅਤੇ ਲੋੜ ਹੋਏ ਤਾਂ ਹਰ ਕਦਮ 'ਤੇ) ਕੰਪਲੀਸ਼ਨ ਦੀਆਂ ਸ਼ਰਤਾਂ ਦਿਖਾਓ: ਜਿਵੇਂ “ਸਾਰੇ lessons ਪੂਰੇ ਕਰੋ”, “Quiz ਪਾਸ ਕਰੋ (80%+)”, “Video 90% ਤੱਕ ਦੇਖੋ”। ਫਿਰ ਬਾਕੀ ਰਹੀ ਚੀਜ਼ ਦਿਖਾਓ: “2 lessons ਬਾਕੀ” ਜਾਂ “Quiz ਨਹੀਂ ਕੀਤਾ”।
ਜਦ ਲਰਨਰ ਮੁਕੰਮਲ ਕਰ ਲੈਂਦਾ ਹੈ, ਤੁਰੰਤ ਇਕ ਕੰਪਲੀਸ਼ਨ ਸਕ੍ਰੀਨ ਦਿਖਾਈਏ ਅਤੇ ਸਰਟੀਫਿਕੇਟ ਜਾਂ ਇਤਿਹਾਸ (ਉਦਾਹਰਨ: /certificates) ਲਈ ਲਿੰਕ ਦਿਓ।
ਸ਼ੁਰੂਆਤ ਤੋਂ ਕੁਝ ਮੂਲ ਚੀਜ਼ਾਂ ਸ਼ਾਮਲ ਕਰੋ: ਪਲੇਅਰ ਲਈ ਕੀਬੋਰਡ ਨੈਵੀਗੇਸ਼ਨ, ਸਪਸ਼ਟ ਫੋਕਸ ਸਟੇਟ, ਚੰਗਾ ਰੰਗ ਕਾਂਟ੍ਰਾਸਟ, ਵੀਡੀਓ ਲਈ ਕੈਪਸ਼ਨ/ਟ੍ਰਾਂਸਕ੍ਰਿਪਟ, ਅਤੇ ਸਪਸ਼ਟ ਐਰਰ ਸੁਨੇਹੇ। ਇਹ ਸੁਧਾਰ ਸਹਾਇਤਾ ਟਿਕਟ ਅਤੇ ਛੱਡਣ ਦੀ ਦਰ ਘਟਾਉਂਦੇ ਹਨ।
ਤੁਹਾਡਾ ਐਡਮਿਨ ਡੈਸ਼ਬੋਰਡ ਇੱਕ ਤੁਰੰਤ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦੇਵੇ: “ਕੀ ਸਾਡੇ ਗ੍ਰਾਹਕ ਅਸਲ ਵਿੱਚ ਟਰੇਨਿੰਗ ਪੂਰੀ ਕਰ ਰਹੇ ਹਨ?” ਚੰਗੇ ਡੈਸ਼ਬੋਰਡ ਐਸਾ ਕਰਨ ਲਈ ਐਡਮਿਨ ਨੂੰ ਪੰਜ ਸਕ੍ਰੀਨਾਂ ਉਤੇ ਕਲਿੱਕ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਨਾ ਪਵੇ।
ਇੱਕ ਅਕਾਊਂਟ ਚੁਣਨ ਵਾਲਾ ਕੰਟਰੋਲ (account selector) ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਤਾਂ ਕਿ ਐਡਮਿਨ ਨੂੰ ਹਮੇਸ਼ਾ ਪਤਾ ਹੋਵੇ ਕਿ ਉਹ ਕਿਹੜਾ ਗਾਹਕ ਦੇਖ ਰਿਹਾ ਹੈ। ਹਰ ਗਾਹਕ ਅਕਾਊਂਟ ਦੀ ਅੰਦਰ ਇੱਕ ਸਾਫ਼ ਟੇਬਲ ਦਿਖਾਓ:
ਟੇਬਲ ਉੱਪਰ ਇੱਕ ਛੋਟਾ “ਹੈਲਥ ਸੰਖੇਪ” ਰੱਖੋ: ਟੋਟਲ ਐਨਰੋਲਡ, ਕੰਪਲੀਸ਼ਨ ਰੇਟ, ਅਤੇ ਕਿੰਨੇ stalled ਹਨ (ਉਦਾਹਰਣ: 14 ਦਿਨਾਂ ਤੋਂ ਕੋਈ activity ਨਹੀਂ)।
ਐਡਮਿਨ ਆਮ ਤੌਰ 'ਤੇ ਪੁੱਛਦੇ ਹਨ “ਕੌਣ ਕੋਰਸ A ਸ਼ੁਰੂ ਨਹੀਂ ਕੀਤਾ?” ਜਾਂ “Support ਟੀਮ ਕਿਵੇਂ ਕਰ ਰਹੀ ਹੈ?” ਫਿਲਟਰਸ ਪ੍ਰਮੁੱਖ ਅਤੇ ਤੇਜ਼ ਹੋਣ:
ਦੀ ਨਤੀਜੇ ਤੁਰੰਤ last activity, status, ਅਤੇ completion date ਦੁਆਰਾ sort ਕਰਨ ਯੋਗ ਹੋਣ। ਇਹ ਡੈਸ਼ਬੋਰਡ ਨੂੰ ਰੋਜ਼ਾਨਾ ਕੰਮ ਦਾ ਟੂਲ ਬਣਾ ਦਿੰਦਾ ਹੈ ਨਾ ਕਿ ਸਿਰਫ ਰਿਪੋਰਟ।
ਕੰਪਲੀਸ਼ਨ ਟਰੈਕਿੰਗ ਤਦ ਹੀ ਮੁੱਲਵਾਨ ਬਣਦੀ ਹੈ ਜਦ ਐਡਮਿਨ ਫੌਰਾਂ ਕਾਰਵਾਈ ਕਰ ਸਕਦੇ ਹਨ। ਨਤੀਜਾ ਸੂਚੀ 'ਤੇ ਬਲਕ ਕਾਰਵਾਈਆਂ ਸ਼ਾਮਲ ਕਰੋ:
ਬਲਕ ਕਾਰਵਾਈਆਂ ਫਿਲਟਰ ਦੀ ਪਾਲਣਾ ਕਰਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ। ਜੇ ਐਡਮਿਨ ਫਿਲਟਰ ਕਰਦਾ ਹੈ “In progress → Course B → Team: Onboarding”, ਤਾਂ export ਸਿਰਫ਼ ਉਸ ਕੋਹੋਰਟ ਨੂੰ ਹੀ ਸ਼ਾਮਿਲ ਕਰੇ।
ਕਿਸੇ ਵੀ ਟੇਬਲ ਰੋ ਤੋਂ, ਐਡਮਿਨ ਨੂੰ ਲਰਨਰ ਡੀਟੇਲ ਵਿਊ ਵਿੱਚ ਕਲਿੱਕ ਕਰਨ ਦੀ ਆਸਾਨੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਕੁੰਜੀ ਇੱਕ ਪੜ੍ਹਨ ਯੋਗ ਟਾਈਮਲਾਈਨ ਹੈ ਜੋ ਦੱਸਦੀ ਹੈ ਕਿ ਕੋਈ ਕਿਉਂ ਫਸਿਆ ਹੋਇਆ ਹੈ:
ਇਹ ਡ੍ਰਿਲ-ਡਾਊਨ ਗਾਹਕਾਂ ਨਾਲ ਵਾਪਸੀ-ਫਰੰਟ ਕਰਨ ਦੀ ਜਗ੍ਹਾ ਘਟਾਉਂਦਾ ਹੈ (“ਮੈਂ ਵਾਕਈ ਮੁਕੰਮਲ ਕੀਤਾ ਸੀ”) ਕਿਉਂਕਿ ਐਡਮਿਨ ਵੇਖ ਸਕਦੇ ਹਨ ਕਿ ਕੀ ਹੋਇਆ ਅਤੇ ਕਦੋਂ।
ਰਿਪੋਰਟਾਂ ਉਹ ਜਗ੍ਹਾ ਹਨ ਜਿੱਥੇ ਟਰੇਨਿੰਗ ਕੰਪਲੀਸ਼ਨ ਟਰੈਕਿੰਗ ਕਾਰਵਾਈਯੋਗ ਬਣਦੀ ਹੈ—ਅਤੇ ਜਿੱਥੇ ਤੁਸੀਂ ਆਡੀਟ ਜਾਂ ਰੀਨਿਊਅਲ ਦੌਰਾਨ ਦਲੀਲ ਦੇ ਸਕਦੇ ਹੋ।
ਛੋਟੀ ਰਿਪੋਰਟ ਸੈੱਟ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਆਮ ਫੈਸਲਿਆਂ ਨਾਲ ਮੇਲ ਖਾਂਦੀ ਹੈ:
ਹਰ ਰਿਪੋਰਟ drillable ਹੋਵੇ: ਚਾਰਟ ਤੋਂ underlying learners ਦੀ ਲਿਸਟ ਤੱਕ ਤਾ ਕਿ ਐਡਮਿਨ ਤੇਜ਼ੀ ਨਾਲ ਫਾਲੋ-ਅਪ ਕਰ ਸਕਣ।
ਕਈ ਟੀਮਾਂ ਸਪਰੇੱਡਸ਼ੀਟਾਂ 'ਚ ਕੰਮ ਕਰਦੀਆਂ ਹਨ, ਇਸ ਲਈ CSV export ਮੁੱਖ ਹੈ। ਸਥਿਰ ਕਾਲਮ ਸ਼ਾਮਲ ਕਰੋ: customer account, learner email, course name, enrollment date, completion date, status, ਅਤੇ ਸਕੋਰ (ਜੇ ਲਾਗੂ ਹੋ)।
ਕੰਪਲੀਅੰਸ ਜਾਂ ਗਾਹਕ ਸਮੀਖਿਆ ਲਈ, ਇੱਕ PDF ਸੰਖੇਪ ਵਿਕਲਪ ਹੋ ਸਕਦਾ ਹੈ: ਹਰ ਗਾਹਕ ਅਕਾਊਂਟ ਜਾਂ ਹਰ ਕੋਰਸ ਲਈ ਇੱਕ ਸਫ਼ਾ totals ਅਤੇ dated snapshot ਨਾਲ। MVP ਨੂੰ ਸ਼ਿਪ ਕਰਨ ਲਈ ਪੂਰੇ PDF ਫਾਰਮੈਟਿੰਗ 'ਤੇ ਰੁਕਾਅ ਨਾ ਰੱਖੋ—ਪਹਿਲਾਂ CSV ਸ਼ਿਪ ਕਰੋ।
ਸਰਟੀਫਿਕੇਟ ਬਣਾਉਣਾ ਆਮ ਤੌਰ 'ਤੇ ਸਿੱਧਾ ਹੁੰਦਾ ਹੈ:
/verify/<certificate_id>ਜਾਂਚ ਪੇਜ ਲਰਨਰ, ਕੋਰਸ, ਅਤੇ ਜਾਰੀ ਕਰਨ ਦੀ ਤਾਰੀਖ ਦੀ ਪੁਸ਼ਟੀ ਕਰੇ ਬਿਨਾਂ ਵਾਧੂ ਨਿੱਜੀ ਜਾਣਕਾਰੀ ਦਿਖਾਉਣ ਦੇ।
ਪੂਰਨਤਾ ਇਤਿਹਾਸ ਤੇਜ਼ੀ ਨਾਲ ਵਧਦਾ ਹੈ। ਫੈਸਲਾ ਕਰੋ:
ਰਿਟੈਨਸ਼ਨ ਨੂੰ ਪ੍ਰਤੀ ਗਾਹਕ ਅਕਾਊਂਟ ਅਨੁਸਾਰ ਕਨਫਿਗਰ ਕਰਨ ਯੋਗ ਬਣਾਓ ਤਾਂ ਕਿ ਤੁਸੀਂ ਵੱਖ-ਵੱਖ ਕੰਪਲੀਅੰਸ ਲੋੜਾਂ ਨੂੰ ਬਿਨਾਂ ਬੜੀ ਰੀ-ਬਿਲਡਿੰਗ ਦੇ ਸਪੋਰਟ ਕਰ ਸਕੋ।
ਨੋਟੀਫਿਕੇਸ਼ਨ ਇਕ ਤਫ਼ਾਵਤ ਹੈ “ਅਸੀਂ ਟਰੇਨਿੰਗ ਅਸਾਈਨ ਕੀਤੀ” ਅਤੇ “ਲੋਕ ਇਹ ਅਸਲ ਵਿੱਚ ਮੁਕੰਮਲ ਕਰਦੇ ਹਨ” ਵਿੱਚ। ਲਕਸ਼ ਹੈ ਬੇ-ਨਕ-ਨਗ ਨਾ ਕਰਨਾ—ਇਕ ਨਰਮ, ਪੇਸ਼ਗੋਈਯੋਗ ਸਿਸਟਮ ਬਣਾਉਣਾ ਜੋ ਗਾਹਕਾਂ ਨੂੰ ਪਿੱਛੇ ਨਹੀਂ ਛੱਡਦਾ।
ਸ਼ੁਰੂਆਤ ਲਈ ਕੁਝ ਛੋਟੇ ਟ੍ਰਿਗਰ ਕਾਫ਼ੀ ਹਨ:
ਟ੍ਰਿਗਰ ਪ੍ਰਤੀ ਕੋਰਸ ਜਾਂ ਪ੍ਰਤੀ ਗਾਹਕ ਅਕਾਊਂਟ ਕਨਫਿਗਰ ਕਰਨ ਯੋਗ ਰੱਖੋ, ਕਿਉਂਕਿ ਕੰਪਲੀਅੰਸ ਟਰੇਨਿੰਗ ਅਤੇ ਉਤਪਾਦ ਓਨਬੋਰਡਿੰਗ ਲਈ urgency ਬਹੁਤ ਵੱਖਰਾ ਹੁੰਦਾ ਹੈ।
ਈਮੇਲ ਜ਼ਿਆਦਾਤਰ ਗ੍ਰਾਹਕ ਟਰੇਨਿੰਗ ਲਈ ਮੁੱਖ ਚੈਨਲ ਹੈ ਕਿਉਂਕਿ ਇਹ ਉਹਨਾਂ ਤੱਕ ਪਹੁੰਚਦੀ ਹੈ ਜੋ ਲੌਗ-ਇਨ ਨਹੀਂ ਹੁੰਦੇ। In-app notifications ਲੋੜੀਂਦੇ ਹਨ ਪਰ reinforcement ਲਈ—ਮੁੱਖ ਡਿਲਿਵਰੀ ਮਕੈਨੀਜ਼ਮ ਨਾ ਬਣਾਉ।
ਜੇ ਦੋਹਾਂ ਜੋੜੇ ਜਾਣ, ਇਹ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਉਹ ਇੱਕੋ underlying schedule ਸਾਂਝਾ ਕਰਦੇ ਹਨ ਤਾਂ ਕਿ ਲਰਨਰ ਨੂੰ ਡਬਲ-ਪਿਂਗ ਨਾ ਮਿਲੇ।
ਐਡਮਿਨਾਂ ਨੂੰ ਆਸਾਨ ਕੰਟਰੋਲ ਦਿਓ:
ਇਸ ਨਾਲ ਯਾਦ ਦਿਵਾਉਣ ਗਾਹਕ ਓਨਬੋਰਡਿੰਗ ਦੇ ਅੰਦਾਜ਼ ਨਾਲ ਮੇਲ ਖਾਂਦੇ ਹਨ ਅਤੇ spam ਸ਼ਿਕਾਇਤਾਂ ਘਟਦੀਆਂ ਹਨ।
ਹਰ ਭੇਜੇ ਗਏ ਸੁਨੇਹੇ ਲਈ ਇੱਕ ਨੋਟੀਫਿਕੇਸ਼ਨ ਇਤਿਹਾਸ ਰਿਕਾਰਡ ਸਟੋਰ ਕਰੋ: ਟ੍ਰਿਗਰ ਟਾਈਪ, ਚੈਨਲ, ਟੈਂਪਲੇਟ ਵਰਜ਼ਨ, ਪ੍ਰਾਪਤਕਰਤਾ, ਟਾਈਮਸਟੈਂਪ, ਅਤੇ ਨਤੀਜਾ (sent, bounced, suppressed)। ਇਹ ਡੁਪਲਿਕੇਟ ਰੋਕਦਾ ਹੈ, ਟਰੇਨਿੰਗ ਕੰਪਲੀਅੰਸ ਰਿਪੋਰਟਿੰਗ ਨੂੰ ਸਹਾਇਕ ਹੈ, ਅਤੇ ਜਦ ਗ੍ਰਾਹਕ ਪੁੱਛਦੇ ਹਨ “ਮੈਨੂੰ ਇਹ ਈਮੇਲ ਕਿਉਂ ਮਿਲੀ?” ਤਾਂ ਸਪਸ਼ਟਤਾ ਦਿੰਦਾ ਹੈ।
ਇੰਟਿਗ੍ਰੇਸ਼ਨ ਇੱਕ ਟਰੇਨਿੰਗ ਟਰੈਕਰ ਨੂੰ “ਹੋਰ ਇਕ ਟੂਲ” ਤੋਂ ਇੱਕ ਭਰੋਸੇਯੋਗ ਸਿਸਟਮ ਬਣਾਉਂਦਾ ਹੈ। ਲਕਸ਼ ਸਧਾਰਨ ਹੈ: ਜੋ ਸਿਸਟਮ ਤੁਸੀਂ ਪਹਿਲਾਂ ਵਰਤਦੇ ਹੋ ਉਹਨਾਂ ਦੇ ਨਾਲ accounts, learners, ਅਤੇ completion ਸਥਿਤੀ ਸਿੰਕ ਰੱਖੋ।
ਉਹ ਸਿਸਟਮ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਪਹਿਲਾਂ ਹੀ ਗਾਹਕ ਦੀ ਪਹਿਚਾਣ ਅਤੇ ਵਰਕਫਲੋ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਨ:
ਇੱਕ-ਇਕ entity ਲਈ ਇੱਕ "ਸਿਸਟਮ ਆਫ਼ ਰਿਕਾਰਡ" ਚੁਣੋ ਤਾਂ ਕਿ ਟਕਰਾਅ ਘਟੇ:
ਸਰਫ਼ੇਸ ਛੋਟਾ ਅਤੇ ਸਥਿਰ ਰੱਖੋ:
POST /api/users (create/update by external_id or email)POST /api/enrollments (enroll user in course)POST /api/completions (set completion status + completed_at)GET /api/courses (for external systems to map course IDs)ਇੱਕ ਮੂਲ webhook ਦਸਤਾਵੇਜ਼ ਕਰੋ ਜਿਸ 'ਤੇ ਤੁਹਾਡੇ ਗ੍ਰਾਹਕ ਨਿਰਭਰ ਕਰ ਸਕਣ:
course.completedaccount_id, user_id, course_id, completed_at, score (optional)ਜੇ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਹੋਰ events (enrolled, overdue, certificate issued) ਜੋੜਦੇ ਹੋ, ਤਾਂ ਉਹੀ conventions ਰੱਖੋ ਤਾਂ ਕਿ ਇੰਟਿਗ੍ਰੇਸ਼ਨ ਪੇਸ਼ਗੋਈਯੋਗ ਰਹਿਣ।
ਟਰੇਨਿੰਗ ਕੰਪਲੀਸ਼ਨ ਡਾਟਾ ਨਿਰਦੋਸ਼ ਲੱਗ ਸਕਦਾ ਹੈ—ਪਰ ਜਦ ਤੁਸੀਂ ਇਸਨੂੰ ਅਸਲ ਲੋਕਾਂ, ਗ੍ਰਾਹਕ ਅਕਾਊਂਟਸ, ਸਰਟੀਫਿਕੇਟ ਅਤੇ ਆਡੀਟ ਇਤਿਹਾਸ ਨਾਲ ਜੋੜਦੇ ਹੋ ਤਾਂ ਇਹ ਸੰਵੇਦਨਸ਼ੀਲ ਹੋ ਜਾਂਦਾ ਹੈ। ਇੱਕ ਪ੍ਰਭਾਵਸ਼ਾਲੀ MVP ਨੂੰ ਪ੍ਰਾਈਵੇਸੀ ਅਤੇ ਸੁਰੱਖਿਆ ਨੂੰ ਇਕ ਫੀਚਰ ਵਜੋਂ ਲੈਣਾ ਚਾਹੀਦਾ ਹੈ, ਨਾ ਕਿ ਬਾਅਦ ਦੀ ਸੋਚ।
ਹੁਣੇ ਹੀ ਹਰ ਨਿੱਜੀ ਡਾਟਾ ਆਈਟਮ ਦੀ ਸੂਚੀ ਬਣਾਓ (ਨਾਂ, ਈਮੇਲ, ਨੌਕਰੀ ਦਾ ਤਖ਼ਤਾਂ, ਟਰੇਨਿੰਗ ਇਤਿਹਾਸ, ਸਰਟੀਫਿਕੇਟ IDs)। ਜੇ ਤੁਹਾਨੂੰ ਇਹ ਸਬੂਤ ਨਹੀਂ ਚਾਹੀਦਾ ਤਾਂ ਇਸਨੂੰ ਇਕੱਠਾ ਨਾ ਕਰੋ।
ਨਿਰਧਾਰਤ ਕਰੋ ਕਿ ਕੀ ਤੁਹਾਨੂੰ ਆਡੀਟ ਸਹਾਇਤਾ ਦੀ ਲੋੜ ਹੈ (ਬਿਹਤਰ ਸਮੇਤ immutable timestamps: enrolled, started, completed), ਕਿਸ ਨੇ ਬਦਲਾਅ ਕੀਤੇ ਅਤੇ ਕੀ ਬਦਲਿਆ—ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਲਾਜ਼ਮੀ ਹੁੰਦਾ ਹੈ।
ਜੇ ਲਰਨਰ EU/UK ਜਾਂ ਮਿਲਦੀਆਂ-ਜੁਰਿਸਡਿਕਸ਼ਨਾਂ ਵਿਚ ਹਨ ਤਾਂ ਤੁਹਾਨੂੰ processing ਲਈ ਸਪਸ਼ਟ lawful basis ਜਾਂ ਕਈ ਕੇਸਾਂ ਵਿੱਚ ਸਹਿਮਤੀ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ। ਭਾਵੇਂ ਜਦ ਸਹਿਮਤੀ ਜ਼ਰੂਰੀ ਨਾ ਹੋਵੇ, ਵੀ ਪਾਰਦਰਸ਼ੀ ਬਣੋ: ਇੱਕ ਛੋਟੀ ਪ੍ਰਾਈਵੇਸੀ ਨੋਟਿਸ ਦਿਓ ਅਤੇ ਦੱਸੋ ਕਿ ਐਡਮਿਨ ਕੀ ਦੇਖ ਸਕਦੇ ਹਨ। ਇੱਕ ਸਮਰਪਿਤ page ਜਿਵੇਂ /privacy ਵਿਚ ਵੀ ਦਿਓ।
least-privilege permissions ਵਰਤੋ:
“export all” ਅਤੇ “delete user” ਨੂੰ ਉੱਚ-ਜੋਖਿਮ ਕਾਰਵਾਈਆਂ ਮੰਨੋ—ਤਾਂ ਉਨ੍ਹਾਂ ਨੂੰ ਉਚਿਤ ਰੋਲ ਦੇ ਪਿੱਛੇ ਰੱਖੋ।
ਯੋਜਨਾ ਬਣਾਓ:
ਇਹ ਮੁੱਢਲੇ ਤੱਤ ਬਾਅਦ ਵਿੱਚ ਜ਼ਿਆਦਾ “ਸਾਡੇ ਕੋਲ ਸਬੂਤ ਨਹੀਂ” ਜਾਂ “ਇਹ ਕਿੰਨੇ ਨੇ ਬਦਲਿਆ?” ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਰੋਕਦੇ ਹਨ।
ਤੁਹਾਡਾ MVP ਤੇਜ਼ੀ ਨਾਲ ਡਿਲਿਵਰੀ ਅਤੇ ਸਾਰੀ ਮਾਲਕੀਤਾ (ਕੌਣ ਕੋਰਸ ਸੰਭਾਲਦਾ ਹੈ, ਕੌਣ ਪ੍ਰਗਤੀ ਵੇਖਦਾ, ਅਤੇ ਕੰਪਲੀਸ਼ਨ ਕਿਵੇਂ ਦਰਜ ਕੀਤੀ ਜਾਂਦੀ ਹੈ) ਲਈ optimize ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। “ਸਭ ਤੋਂ ਵਧੀਆ” ਤਕਨੀਕ ਉਹ ਹੈ ਜੋ ਤੁਹਾਡੀ ਟੀਮ ਅਗਲੇ 12–24 ਮਹੀਨੇ ਲਈ ਸਹਿਯੋਗ ਕਰ ਸਕੇ।
Custom appPerfect਼ ਹੈ ਜਦੋਂ ਤੁਹਾਨੂੰ ਅਕਾਊਂਟ-ਆਧਾਰਿਤ ਐਕਸੈੱਸ, ਮਸਦ-ਵਿਸ਼ੇਸ਼ ਰਿਪੋਰਟਿੰਗ ਜਾਂ ਬ੍ਰੈਂਡਡ ਲਰਨਰ ਪੋਰਟਲ ਦੀ ਲੋੜ ਹੋਵੇ। ਇਹ ਤੁਹਾਨੂੰ ਰੋਲ, ਸਰਟੀਫਿਕੇਟਿਕੇ, ਅਤੇ ਇੰਟਿਗਰੇਸ਼ਨ 'ਤੇ ਪੂਰਾ ਨਿਯੰਤਰਣ ਦਿੰਦਾ—ਪਰ ਤੁਸੀਂ ਮੈਨਟੇਨੈਂਸ ਨੂੰ ਸੰਭਾਲਣਾ ਪਛਰਦੇ ਹੋ।
Low-code (ਅੰਦਰੂਨੀ ਟੂਲ + ਡੇਟਾਬੇਸ) ਕੰਮ ਕਰ ਸਕਦਾ ਹੈ ਜੇ ਲੋੜਾਂ ਸਧਾਰਣ ਹਨ ਅਤੇ ਤੁਸੀਂ ਅਮੂਮਨ ਚੈੱਕਲਿਸਟ ਅਤੇ ਹਾਜ਼ਰੀ ਟਰੈਕ ਕਰ ਰਹੇ ਹੋ। ਪਰ ਪਰਮੀਸ਼ਨ, ਐਕਸਪੋਰਟ ਅਤੇ ਆਡੀਟ ਇਤਿਹਾਸ 'ਤੇ ਲਿਮਿਟੇਸ਼ਨ ਦੇਖੋ।
Maujੂਦਾ LMS + ਪੋਰਟਲ ਅਕਸਰ ਤੇਜ਼ ਹੈ ਜੇ ਤੁਹਾਨੂੰ quizzes, SCORM, ਜਾਂ ਰੀਚ ਕੋਰਸ ਆਥਰਿੰਗ ਚਾਹੀਦੀ ਹੈ। ਤੁਹਾਡੀ “ਐਪ” ਇੱਕ ਪਤਲਾ ਪੋਰਟਲ ਅਤੇ ਰਿਪੋਰਟਿੰਗ ਲੇਅਰ ਬਣ ਜਾਂਦੀ ਹੈ ਜੋ LMS ਤੋਂ completion ਡਾਟਾ ਖਿੱਚਦੀ ਹੈ।
ਆਰਕੀਟੈਕਚਰ ਨਿਆਣੀ ਰੱਖੋ: ਇੱਕ ਵੈੱਬ ਐਪ + ਇੱਕ API + ਇੱਕ ਡੇਟਾਬੇਸ MVP ਲਈ ਕਾਫ਼ੀ ਹੈ।
ਜੇ ਮੁੱਖ ਪਾਬੰਦੀ ਡਿਲਿਵਰੀ ਗਤੀ ਹੈ (ਲੰਬੇ ਸਮੇਂ ਤੱਕ ਵੱਖ-ਵੱਖ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਨਹੀਂ), Koder.ai ਵਾਂਗ ਇੱਕ vibe-coding ਪਲੇਟਫਾਰਮ ਤੁਹਾਨੂੰ ਪਹਿਲੀ ਵਰਜਨ ਤੇਜ਼ੀ ਨਾਲ ਸ਼ਿਪ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ। ਤੁਸੀਂ ਆਪਣੇ ਚਾਹੀਦੇ ਫਲੋਸ ਨੂੰ ਚੈਟ ਵਿੱਚ ਵਰਣਨ ਕਰ ਸਕਦੇ ਹੋ—ਮਲਟੀ-ਟੇਨੈਂਟ ਅਕਾਊਂਟ, ਐਨਰੋਲਮੈਂਟ, ਕੋਰਸ ਪ੍ਰਗਤੀ, ਐਡਮਿਨ ਟੇਬਲ, CSV ਐਕਸਪੋਰਟ—ਅਤੇ ਇੱਕ ਕੰਮ ਕਰਨ ਵਾਲਾ ਬੇਸਲਾਈਨ ਜਨਰੇਟ ਕਰ ਸਕਦੇ ਹੋ ਜੋ ਮਾਡਰਨ ਸਟੈਕ ਵਰਤਦਾ ਹੈ (React frontend, Go + PostgreSQL backend)।
MVP ਲਈ ਦੋ ਪ੍ਰਯੋਗੀ ਫਾਏਦੇ:
ਸ਼ੁਰੂ ਤੋਂ ਹੀ ਤਿੰਨ ਮਾਹੌਲ ਯੋਜਨਾ ਕਰੋ: dev (ਤੇਜ਼ iteration), staging (ਰੀਅਲਿਸਟਿਕ ਡੇਟਾ ਨਾਲ ਟੈਸਟ), production (ਕਠੋਰ ਐਕਸੈੱਸ, ਬੈਕਅੱਪ, ਮਾਨੀਟਰਿੰਗ)। ਮੈਨੇਜਡ ਹੋਸਟਿੰਗ (AWS/GCP/Render/Fly) ਵਰਤਣਾ ਓਪਸ ਕੰਮ ਘਟਾਉਂਦਾ ਹੈ।
MVP (ਹਫ਼ਤੇ): auth + customer accounts, course enrollment, progress/completion tracking, basic admin dashboard, CSV export.
Nice-to-haves (ਬਾਅਦ): ਸਰਟੀਫਿਕੇਟ ਟੈਂਪਲੇਟ, ਉੱਚ-ਗੁਣਵੱਤਾ ਐਨਾਲੇਟਿਕਸ, ਫਾਇਨ-ਗਰੇਨਡ ਪਰਮੀਸ਼ਨ, LMS/CRM sync, ਆਟੋਮੇਟਿਕ ਰੀਮਾਈਂਡਰ ਜਰਨੀਆਂ, ਆਡੀਟ ਲੌਗ।
ਇੱਕ ਟਰੇਨਿੰਗ ਕੰਪਲੀਸ਼ਨ ਐਪ ਤਦ ਹੀ ਕਾਮਯਾਬ ਹੁੰਦੀ ਹੈ ਜਦ ਇਹ ਨਿਰੋਲ-ਭਰੋਸੇਯੋਗ ਹੋ: ਲਰਨਰ ਮੁਕੰਮਲ ਕਰ ਸਕਦੇ, ਐਡਮਿਨ ਸਬੂਤ ਵੈਰੀਫਾਈ ਕਰ ਸਕਦੇ, ਅਤੇ ਹਰ ਕੋਈ ਨੰਬਰਾਂ 'ਤੇ ਭਰੋਸਾ ਕਰਦਾ। ਸਭ ਤੋਂ ਤੇਜ਼ ਰਸਤਾ ਇੱਕ ਸੰਕੁਚਿਤ MVP ਨੂੰ ਰਿਲੀਜ਼ ਕਰਨਾ, ਅਸਲੀ ਗਾਹਕਾਂ ਨਾਲ ਫੁਟ ਕਰਕੇ ਉਸਨੂੰ ਪ੍ਰਮਾਣਿਤ ਕਰਨਾ ਅਤੇ ਫਿਰ ਫੈਲਾਉਣਾ ਹੈ।
ਉਹ ਲਾਜ਼ਮੀ ਸਕ੍ਰੀਨਾਂ ਅਤੇ ਸਮਰੱਥਾਵਾਂ ਚੁਣੋ ਜੋ end-to-end “ਪ੍ਰੂਫ ਆਫ਼ ਕੰਪਲੀਸ਼ਨ” ਦਿੰਦੇ ਹਨ:
ਹੁਣ ਕੰਪਲੀਸ਼ਨ ਨਿਯਮ ਤੈਅ ਕਰੋ (ਉਦਾਹਰਣ: “ਸਾਰੇ modules ਵੇਖੇ” vs “quiz ਪਾਸ”) ਅਤੇ ਉਹ acceptance criteria ਵਜੋਂ ਲਿਖੋ।
ਸਾਰੀ ਟੀਮ ਇੱਕ ਹੀ ਚੈੱਕਲਿਸਟ ਨੂੰ ਸਾਂਝਾ ਕਰੇ:
ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਤ ਰਹੇ ਹੋ ਤਾਂ ਇਹ ਚੈੱਕਲਿਸਟ ਜ਼ਰੂਰੀ ਤੌਰ 'ਤੇ ਚੈਟ ਵਿੱਚ ਇੱਕ "spec" ਵਜੋਂ ਤਬਦੀਲ ਹੋ ਸਕਦੀ ਹੈ ਜਿਸ ਤੇ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ iteration ਕਰ ਸਕਦੇ ਹੋ।
ਵਾਸਤਵਿਕ ਟੈਸਟ ਚਲਾਓ ਜੋ ਗ੍ਰਾਹਕਾਂ ਦੀ ਵਰਤੋਂ ਦੀ ਤਰ੍ਹਾਂ ਹੋਣ:
ਇੱਕ ਗਾਹਕ ਅਕਾਊਂਟ ਨਾਲ 2–3 ਹਫ਼ਤੇ ਪਾਇਲਟ ਕਰੋ। time-to-first-completion, drop-off points, ਅਤੇ ਐਡਮਿਨ ਪ੍ਰਸ਼ਨ ਟਰੈਕ ਕਰੋ। ਫੀਡਬੈਕ ਦੇ ਆਧਾਰ 'ਤੇ ਅਗਲੇ ਇਟਰੇਸ਼ਨ ਦੀ ਤਰਜੀਹ ਨਿਰਧਾਰਿਤ ਕਰੋ: ਸਰਟੀਫਿਕੇਟ, ਯਾਦ ਦਿਵਾਉਣ, ਇੰਟਿਗਰੇਸ਼ਨ, richer analytics।
ਜੇ ਤੁਸੀਂ MVP ਦਾ ਸਕੋਪ ਨਿਰਧਾਰਤ ਕਰਨ ਜਾਂ ਇਸਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਸ਼ਿਪ ਕਰਨ ਵਿੱਚ ਮਦਦ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ /contact ਤੇ ਸਾਡੇ ਨਾਲ ਰਾਬਤਾ ਕਰੋ।
ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਉਸ ਕਾਰੋਬਾਰੀ ਸਵਾਲ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ: ਕਿਸ ਨੇ ਕਿਹੜੀ ਟਰੇਨਿੰਗ ਕੀਤੀ, ਕਦੋਂ, ਤੇ ਕਿਸ ਨਤੀਜੇ ਨਾਲ। ਤੁਹਾਡੇ MVP ਨੂੰ ਵਿਸ਼ਵਾਸਯੋਗ ਤਰੀਕੇ ਨਾਲ ਇਹ ਜਾਣਕਾਰੀ ਕੈਪਚਰ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ:
started_at, last_activity_at, completed_atਜੇ ਇਹ ਫੀਲਡ ਭਰੋਸੇਯੋਗ ਹਨ, ਤਾਂ ਡੈਸ਼ਬੋਰਡ, ਐਕਸਪੋਰਟ ਅਤੇ ਕੰਪਲੀਅੰਸ ਗੱਲਬਾਤ ਆਸਾਨ ਹੋ ਜਾਂਦੀਆਂ ਹਨ।
ਕੰਪਲੀਸ਼ਨ ਨਿਯਮ ਸਪਸ਼ਟ ਤਰੀਕੇ ਨਾਲ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਸਟੋਰ ਕਰੋ (ਅਤੇ ਵਰਜ਼ਨ) — ਕਲਿੱਕਾਂ ਤੋਂ ਅਨੁਮਾਨ ਨਾ ਲਵੋ।
ਆਮ ਨਿਯਮ ਟਾਈਪ:
ਕੋਰਸ ਪੱਧਰ 'ਤੇ ਫ਼ੈਸਲਾ ਕਰੋ ਕਿ ਕੰਪਲੀਸ਼ਨ ਲਈ ਸਾਰੇ ਲਾਜ਼ਮੀ ਆਈਟਮ ਲਾਜ਼ਮੀ ਹਨ ਜਾਂ N ਵਿੱਚੋਂ M ਅਤੇ ਨਿਯਮ ਵਰਜ਼ਨ ਸਟੋਰ ਕਰੋ ਤਾਂ ਜੋ ਸਮੱਗਰੀ ਬਦਲਣ 'ਤੇ ਰਿਪੋਰਟਿੰਗ ਇੱਕਸਰ ਰਹੇ।
ਏਕ ਬਹੁਤ ਸਧਾਰਣ ਸੁਰੱਖਿਆ (ਟੈਨੈਂਟ) ਸਰਹੱਦ ਬਣਾਓ:
ਫਿਰ ਰੋਲਾਂ ਨੂੰ ਉਪਰ ਲਗਾਓ:
ਵੱਧਤੋਂ ਵੱਧ ਤਰੀਕੇ ਜੋ ਜ਼ਿਆਦਾਤਰ ਵਰਕਫਲੋਜ਼ ਨੂੰ ਕਵਰ ਕਰਦੇ ਹਨ:
ਹਮੇਸ਼ਾ , , ਅਤੇ ਰਜਿਸਟ੍ਰੇਸ਼ਨ 'ਤੇ ਰਿਕਾਰਡ ਕਰੋ ਤਾਂ ਕਿ ਬਾਅਦ ਵਿੱਚ “ਉਹ ਕਿਵੇਂ ਆਏ?” ਸਵਾਲ ਨਾ ਪੇਦਾ ਹੋਵੇ।
Magic links password ਨੂੰ ਘੱਟ ਕਰਦੇ ਹਨ ਅਤੇ friction ਘਟਾਉਂਦੇ ਹਨ, ਪਰ ਤੁਹਾਨੂੰ ਹਜੇ ਵੀ ਚਾਹੀਦਾ ਹੈ:
Passwords ਠੀਕ ਹਨ ਜੇ ਤੁਹਾਡੇ ਗ੍ਰਾਹਕ ਉਨ੍ਹਾਂ ਦੀ ਉਮੀਦ ਕਰਦੇ ਹਨ, ਪਰ ਰੀਸੈੱਟ, ਲੌਕਆਊਟ ਅਤੇ ਸੁਰੱਖਿਆ ਸਖਤੀ ਲਈ ਸਮਾਂ ਰੱਖੋ। ਆਮ ਰਸਤਾ: ਹੁਣ Magic link, ਵੱਡੇ ਗ੍ਰਾਹਕਾਂ ਲਈ ਬਾਅਦ ਵਿੱਚ SSO (SAML/OIDC) ਜੋੜੋ।
“ਅੱਗੇ ਕੀ ਕਰਨਾ ਹੈ” ਸਪਸ਼ਟ ਬਣਾਓ ਅਤੇ ਪੂਰਾ ਕਰਨ ਨੂੰ ਅਨੁਮਾਨਯੋਗ ਰੱਖੋ:
/certificates)ਜੇ ਲਰਨਰ ਸਮਝ ਨਾ ਸਕਣ ਕਿ ਕੀ ਬਾਕੀ ਹੈ, ਉਹ ਰੁਕ ਜਾਂਦੇ ਹਨ—ਭਾਵੇਂ ਤੁਹਾਡਾ ਟਰੈਕਿੰਗ ਠੀਕ ਹੋਵੇ।
ਜੋੜੀ ਟੇਬਲ ਜੋ ਦਿਖਾਉਂਦੀ ਹੈ ਕਿ ਕੌਣ ਅਟਕਿਆ ਹੋਇਆ ਹੈ ਅਤੇ ਕਿਉਂ:
ਫਿਰ ਐਡਮਿਨ ਦੇ ਕੰਮ ਕਰਨ ਯੋਗ ਕਾਰਵਾਈਆਂ ਜੋਨੇ ਉਹ ਵੇਖ ਰਹੇ ਹਨ:
ਇਸ ਤਰ੍ਹਾਂ ਡੈਸ਼ਬੋਰਡ ਦਿਨ-ਪ੍ਰਤੀ-ਦਿਨ ਦਾ ਉਪਕਰਨ ਬਣ ਜਾਂਦਾ ਹੈ, ਨਾ ਕਿ ਸਿਰਫ ਚੌਮਾਸਿਕ ਰਿਪੋਰਟ।
ਅਟੈਂਪਟਾਂ ਨੂੰ ਇੱਕ-ਮੁੱਖ ਡੇਟਾ ਵਜੋਂ ਟਰੈਕ ਕਰੋ ਬਜਾਏ ਫੀਲਡਾਂ ਨੂੰ ਓਵਰਰਾਈਟ ਕਰਨ ਦੇ।
ਪ੍ਰੈਕਟਿਕਲ ਪਹੁੰਚ:
ਇਸ ਨਾਲ ਸੱਚੀ ਰਿਪੋਰਟਿੰਗ (ਉਦਾਹਰਣ: “ਉਹ ਤੀਜੀ ਕੋਸ਼ਿਸ਼ 'ਤੇ ਪਾਸ ਹੋਏ”) ਹੁੰਦੀ ਹੈ ਅਤੇ ਵਿਵਾਦ ਘਟਦੇ ਹਨ।
ਸਮਗਰੀ ਬਦਲਣ ਨੂੰ ਵਰਜ਼ਨਿੰਗ ਸਮੱਸਿਆ ਵਜੋਂ ਦਿਖੋ।
ਵਿਕਲਪ:
Enrollments/completions 'ਤੇ course_version_id ਸਟੋਰ ਕਰੋ ਤਾਂ ਕਿ ਸਮੇਂ ਦੇ ਨਾਲ ਰਿਪੋਰਟ ਪਿੱਛੇ ਨਹੀਂ ਮੁੜਦੇ।
ਪਹਿਲਾਂ ਉਹਨਾਂ ਸਿਸਟਮਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਪਹਿਲਾਂ ਤੋਂ ਗ੍ਰਾਹਕ ਪਹਿਚਾਨ ਅਤੇ ਵਰਕਫਲੋ ਨੂੰ ਨਿਰਧਾਰਿਤ ਕਰਦੇ ਹਨ:
API ਨੂੰ ਛੋਟਾ ਰੱਖੋ:
ਇਸ ਤਰ੍ਹਾਂ ਡਾਟਾ ਲੀਕੇਜ ਰੁਕਦੀ ਹੈ ਅਤੇ ਰਿਪੋਰਟਿੰਗ ਭਰੋਸੇਯੋਗ ਬਣਦੀ ਹੈ।
enrolled_byenrolled_atorganization_idPOST /api/usersPOST /api/enrollmentsPOST /api/completionsGET /api/coursesਇੱਕ webhook ਜਿਵੇਂ course.completed ਦਿਓ ਜੋ ਸਾਈਨ ਕੀਤੇ ਹੋਏ ਰਿਕਵੇਸਟ, ਰੀਟ੍ਰਾਈਜ਼ ਅਤੇ idempotency ਦੀ ਪਾਲਣਾ ਕਰਦਾ ਹੋਵੇ ਤਾਂ ਕਿ ਡਾਊਨਸਟ੍ਰੀਮ ਸਿਸਟਮ ਸਹੀ ਰਹਿੰਦੇ ਹਨ।