18 ਸਤੰ 2025·8 ਮਿੰਟ
ਉਮੀਦਵਾਰਾਂ ਨੂੰ ਮੈਚ ਕਰਨ ਵਾਲੀ ਭਰਤੀ ਵੈੱਬ ਐਪ ਕਿਵੇਂ ਬਣਾਈਏ
ਉਮੀਦਵਾਰਾਂ ਨੂੰ ਨੌਕਰੀਆਂ ਨਾਲ ਮੈਚ ਕਰਨ ਵਾਲੀ ਭਰਤੀ ਵੈੱਬ ਐਪ ਕਿਵੇਂ ਬਣਾਈਏ: ਕੋਰ ਫੀਚਰ, ਡੇਟਾ ਮਾਡਲ, ਮੈਚਿੰਗ ਲਾਜਿਕ, UX, ਇਕਤੀਕਰਨ ਅਤੇ ਲਾਂਚ ਨੂੰ ਕਵਰ ਕਰਦਾ ਹੈ।
ਉਮੀਦਵਾਰਾਂ ਨੂੰ ਨੌਕਰੀਆਂ ਨਾਲ ਮੈਚ ਕਰਨ ਵਾਲੀ ਭਰਤੀ ਵੈੱਬ ਐਪ ਕਿਵੇਂ ਬਣਾਈਏ: ਕੋਰ ਫੀਚਰ, ਡੇਟਾ ਮਾਡਲ, ਮੈਚਿੰਗ ਲਾਜਿਕ, UX, ਇਕਤੀਕਰਨ ਅਤੇ ਲਾਂਚ ਨੂੰ ਕਵਰ ਕਰਦਾ ਹੈ।
ਸਕੈਚ ਸਕ੍ਰੀਨਾਂ ਜਾਂ ਟੈਕ ਸਟੈਕ ਚੁਣਨ ਤੋਂ ਪਹਿਲਾਂ, ਇਹ ਪੱਕਾ ਕਰੋ ਕਿ ਤੁਹਾਡੀ ਭਰਤੀ ਵੈੱਬ ਐਪ ਕਿਹੜੀ ਸਮੱਸਿਆ ਹੱਲ ਕਰਦੀ ਹੈ—ਅਤੇ ਕਿਸ ਲਈ। “ਉਮੀਦਵਾਰ-ਨੌਕਰੀ ਮੈਚਿੰਗ” ਇੱਕ ਸਧਾਰਨ ਕੀਵਰਡ ਫਿਲਟਰ ਤੋਂ ਲੈ ਕੇ ਇੱਕ ਮਾਰਗਦਰਸ਼ਿਤ ਵਰਕਫਲੋ ਤੱਕ ਹੋ ਸਕਦੀ ਹੈ ਜੋ ਰਿਕ੍ਰੂਟਰ ਨੂੰ ਇਨਟੇਕ ਤੋਂ ਪਲੇਸਮੈਂਟ ਤੱਕ ਰੋਲ ਲੈ ਕੇ ਜਾਣ ਵਿੱਚ ਮਦਦ ਕਰਦੀ ਹੈ.
ਉਹਨਾਂ ਲੋਕਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਹਰ ਰੋਜ਼ ਲੌਗ ਇਨ ਕਰਨਗੇ। ਇੱਕ ਏਜੰਸੀ ਲਈ ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਹਨ:
ਇੱਕ ਮਦਦਗਾਰ ਕਸਰਤ 2–3 “ਟੌਪ ਟਾਸਕ” ਲਿਖਣਾ ਹੈ ਹਰ ਯੂਜ਼ਰ ਲਈ। ਜੇ ਕੋਈ ਟਾਸਕ ਉਹਨਾਂ ਨੂੰ ਸਹਾਰਾ ਨਹੀਂ ਦਿੰਦਾ, ਤਾਂ ਸੰਭਵ ਹੈ ਕਿ ਉਹ MVP ਦਾ ਹਿੱਸਾ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ।
“ਬਿਹਤਰ ਮੈਚ” ਵਰਗੇ ਮੁੱਢਲੇ ਲਕੜੀ ਭਰੋਸਾਯੋਗ ਨਤੀਜੇ ਨਹੀਂ ਦਿੰਦੇ। ਉਹ ਮੈਟ੍ਰਿਕਸ ਚੁਣੋ ਜੋ ਕਾਰੋਬਾਰੀ ਨਤੀਜੇ ਦਰਸਾਉਂਦੇ ਹਨ ਅਤੇ ਹੱਥ-ਕੰਮ ਘਟਾਉਂਦੇ ਹਨ:
ਇਹ ਮੈਟ੍ਰਿਕਸ ਬਾਅਦ ਵਿੱਚ ਤੁਹਾਡੇ recruiting analytics ਨੂੰ ਸੂਚਿਤ ਕਰਨਗੇ ਅਤੇ ਇਹ ਦੱਸਣਗੇ ਕਿ ਤੁਸੀਂ ਮੈਚਿੰਗ ਐਲਗੋਰਿਦਮ ਨਾਲ ਅਸਲ ਨਤੀਜੇ ਸੁਧਾਰ ਰਹੇ ਹੋ ਜਾਂ ਨਹੀਂ।
ਭਰਤੀ ਵਰਕਫਲੋ ਮੈਚਿੰਗ ਤੋਂ ਵੱਧ ਹੈ। ਹਰ ਪੜਾਅ ਨੂੰ ਦਰਸਤ ਕਰੋ ਅਤੇ ਹਰ ਕਦਮ 'ਤੇ ਕਿਹੜਾ ਡੇਟਾ ਬਣਦਾ ਹੈ:
Sourcing → Screening → Submitting → Interviewing → Offer → Placement
ਹਰ ਪੜਾਅ ਲਈ, ‘ਆਬਜੈਕਟ’ ਨੋਟ ਕਰੋ (candidate, job, submission, interview), ਮੁੱਖ ਕਾਰਵਾਈਆਂ (ਕਾਲ ਲਾਗ, ਈਮੇਲ ਭੇਜੋ, ਇੰਟਰਵਿਊ ਤੈਅ ਕਰੋ) ਅਤੇ ਫੈਸਲੇ ਦੇ ਬਿੰਦੂ (reject, move forward, hold). ਇੱਥੇ ATS ਅਤੇ CRM ਫੀਚਰ ਅਕਸਰ ਅਡੇ ਦਿੰਦੇ ਹਨ—ਇਸ ਲਈ ਸੰਕਲਪਤ ਹੋਵੋ ਕਿ ਤੁਸੀਂ ਕੀ ਟਰੈਕ ਕਰ ਰਹੇ ਹੋ।
ਤੁਹਾਡਾ MVP ਇੱਕ ਵਰਤਣਯੋਗ ਲੂਪ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ: ਨੌਕਰੀ ਰਿਕੁਇਜ਼ੀਸ਼ਨ ਬਣਾਓ → ਉਮੀਦਵਾਰ ਜੋੜੋ (ਮੈਨੂਅਲ ਜਾਂ ਬੇਸਿਕ ਰੇਜ਼ਿਊਮ ਪਾਰਸਿੰਗ) → ਮੈਚ → ਸਮੀਖਿਆ → ਸਬਮਿਟ।
ਅਮੂਮਨ v1 ਸ਼ਾਮਿਲ ਹੋਣ ਵਾਲੀਆਂ ਚੀਜ਼ਾਂ:
ਆਮ ਤੌਰ 'ਤੇ ਬਾਅਦ ਦੀਆਂ ਸੁਵਿਧਾਵਾਂ (ਪਹਿਲਾਂ "nice-to-have"):
ਯੂਜ਼ਰ, ਮੈਟ੍ਰਿਕਸ, ਵਰਕਫਲੋ ਅਤੇ ਸਕੋਪ ਨੂੰ ਪਹਿਲਾਂ ਤੋਂ ਪਰਿਭਾਸ਼ਿਤ ਕਰਕੇ, ਤੁਸੀਂ ਪ੍ਰੋਜੈਕਟ ਨੂੰ “ਹਰ ਚੀਜ਼ ATS” ਬਣਨ ਤੋਂ ਬਚਾਉਂਦੇ ਹੋ ਅਤੇ ਬਿਲਡ ਨੂੰ ਤੇਜ਼, ਜ਼ਿਆਦਾ ਭਰੋਸੇਯੋਗ shortlists 'ਤੇ ਕੇਂਦ੍ਰਿਤ ਰੱਖਦੇ ਹੋ।
ਇੱਕ ਭਰਤੀ ਵੈੱਬ ਐਪ ਦੀ ਕਾਮਯਾਬੀ ਉਸਦੇ ਡੇਟਾ ਮਾਡਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ। ਜੇ candidates, jobs ਅਤੇ ਉਹਨਾਂ ਦੀਆਂ ਇੰਟਰੈਕਸ਼ਨਾਂ ਸਾਫ਼ ਢੰਗ ਨਾਲ ਸਟ੍ਰਕਚਰਡ ਨਹੀਂ ਹਨ, ਤਾਂ ਮੈਚਿੰਗ ਸ਼ੋਰਭਰਪੂਰ ਹੋ ਜਾਵੇਗੀ, ਰਿਪੋਰਟਿੰਗ ਅਣਵਿਸ਼ਵਾਸਨੀਯ ਹੋ ਜਾਵੇਗੀ, ਅਤੇ ਟੀਮ ਟੂਲ ਨਾਲ ਲੜੇਗੀ ਨਾ ਕਿ ਉਸਦਾ ਉਪਯੋਗ।
ਇੱਕ Candidate ਐਂਟੀਟੀ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਦਸਤਾਵੇਜ਼ ਸਟੋਰੇਜ ਅਤੇ searchable ਖੇਤਰ ਦੋਹਾਂ ਨੂੰ ਸਪੋਰਟ ਕਰੇ। ਮੂਲ ਰੇਜ਼ਿਊਮ/CV ਰੱਖੋ (ਫਾਇਲ + ਨਿਕਲਿਆ ਗਿਆ ਟੈਕਸਟ), ਪਰ ਉਹ ਅਹਮ ਗੁਣ ਜੋ ਤੁਹਾਨੂੰ candidate-job ਮੈਚਿੰਗ ਲਈ ਚਾਹੀਦੇ ਹਨ ਉਹਨਾਂ ਨੂੰ ਨਾਰਮਲਾਈਜ਼ ਕਰੋ:
ਸੰਕੇਤ: “ਰਾ” ਡੇਟਾ (parsed text) ਨੂੰ “ਕਿਊਰੇਟਡ” ਖੇਤਰਾਂ ਤੋਂ ਵੱਖ ਰੱਖੋ ਜੋ ਰਿਕ੍ਰੂਟਰ ਸੋਧ ਸਕਦੇ ਹਨ। ਇਹ parsing ਗਲਤੀਆਂ ਨੂੰ ਪ੍ਰੋਫਾਈਲ ਨੂੰ ਗੜਬੜ ਕਰਨ ਤੋਂ ਰੋਕਦਾ ਹੈ।
ਇੱਕ Job (requisition) ਐਂਟੀਟੀ ਬਣਾਓ ਜਿਸ ਵਿੱਚ ਸੰਗਠਿਤ ਖੇਤਰ ਹੋਣ: title, seniority, required vs nice-to-have skills, location/remote ਨੀਤੀ, salary range, status (draft/open/on hold/closed), ਅਤੇ hiring manager ਵੇਰਵਾ। ਜ਼ਰੂਰਤਾਂ ਨੂੰ ਸਕੋਰ ਕਰਨ ਯੋਗ ਇਤਨਾ ਢਾਂਚਾਬੱਧ ਕਰੋ, ਪਰ ਅਸਲੀ ਨੌਕਰੀ ਵਰਣਨ ਲਈ ਲਚਕੀਲਾ ਵੀ ਰੱਖੋ।
ਬਹੁਤ ਸਾਰਾ ਕਾਰਜ candidates ਅਤੇ jobs ਦੇ ਦਰਮਿਆਨ ਹੁੰਦਾ ਹੈ, ਇਸ ਲਈ ਰਿਸ਼ਤੇ ਨੂੰ ਖੁੱਲ ਕੇ ਮਾਡਲ ਕਰੋ:
ਸ਼ੁਰੂ ਵਿੱਚ ਹੀ ਅਕਸੈਸ ਨਿਰਧਾਰਤ ਕਰੋ: ਏਜੰਸੀ-ਵਿਆਪਕ vs ਟੀਮ-ਕੇਵਲ candidates, ਕਲਾਇਟ-ਖਾਸ ਦ੍ਰਿਸ਼ਟੀ, ਅਤੇ ਰੋਲ ਅਨੁਸਾਰ ਸੋਧ ਅਧਿਕਾਰ (recruiter, manager, admin). ਪਰਮਿਸ਼ਨ ਨੂੰ ਹਰ read/write ਰਸਤੇ ਨਾਲ ਜੋੜੋ ਤਾਂ ਕਿ ਨਿੱਜੀ candidates ਜਾਂ ਗੁਪਤ ਨੌਕਰੀਆਂ search ਜਾਂ matching ਨਤੀਜਿਆਂ ਰਾਹੀਂ ਲੀਕ ਨਾ ਹੋਣ।
ਰਿਕ੍ਰੂਟਰ ਤੇਜ਼ੀ ਨਾਲ ਕੰਮ ਕਰਦੇ ਹਨ: ਉਹ ਸਕੈਨ, ਫਿਲਟਰ, ਤੁਲਨਾ ਅਤੇ follow-up ਕਰਦੇ ਹਨ—ਅਕਸਰ ਕਾਲਾਂ ਦੇ ਦਰਮਿਆਨ। ਤੁਹਾਡੀ UX ਉਹ “ਨੈਕਸਟ ਕਲਿਕਸ” ਸਪਸ਼ਟ ਅਤੇ ਸਸਤੇ ਬਣਾਉਣੀ ਚਾਹੀਦੀ ਹੈ।
ਚਾਰ ਮੁੱਖ ਪੰਨੇ ਅਤੇ ਇੱਕ ਮੈਚਿੰਗ ਵਿਊ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ:
ਰਿਕ੍ਰੂਟਰ ਫੈਸਲਾ ਕਰਦੇ ਹਨ ਕਿ search ਇੱਕ command bar ਵਾਂਗ ਵਰਤੇ। ਗਲੋਬਲ search ਦੇ ਨਾਲ-ਨਾਲ ਫਿਲਟਰ ਦਿਓ: skills, location, years of experience, salary, status, ਅਤੇ availability. multi-select ਅਤੇ saved filters (ਜੈਸੇ “London Java 5+ years under £80k”) ਦੀ ਆਗਿਆ ਦਿਓ। ਫਿਲਟਰ ਦਿਸਣਯੋਗ ਰੱਖੋ ਅਤੇ ਕਿਰਦਾਰਾਂ ਨੂੰ ਸਾਫ਼ ਚਿੱਪਸ ਵਿੱਚ ਦਿਖਾਓ।
ਲੰਬੇ ਸੂਚੀਆਂ ਦੇ ਨਾਲ ਡੇਰਾਂ ਘਟਾਉਂਦੇ ਹਨ। candidate list ਜਾਂ match view ਤੋਂ, ਸਹਾਇਤਾ ਕਰੋ: tagging, status ਬਦਲਣਾ, job shortlist ਵਿੱਚ ਜੋੜਨਾ, ਅਤੇ ਈਮੇਲ ਐਕਸਪੋਰਟ. ਇੱਕ “undo” ਟੋਾਸਟ ਸ਼ਾਮਿਲ ਕਰੋ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਦਿਖਾਓ ਕਿ ਕਿੰਨੇ ਰਿਕਾਰਡ ਬਦਲਾਏ ਜਾਣਗੇ।
UI ਨੂੰ ਕੀ-ਬੋਰਡ-ਫ੍ਰੈਂਡਲੀ ਬਣਾਓ (focus states, ਤਰਕਸੰਗਤ tab order) ਅਤੇ ਪੜ੍ਹਨਯੋਗ (ਚੰਗਾ ਕਾਨਟਰਾਸਟ, ਵੱਡੇ ਟੈਪ ਟਾਰਗੇਟ). ਮੋਬਾਈਲ 'ਤੇ, list → detail ਫਲੋ ਨੂੰ ਪ੍ਰਾਥਮਿਕਤਾ ਦਿਓ, ਫਿਲਟਰ slide-over ਪੈਨਲ ਵਿੱਚ ਰੱਖੋ, ਅਤੇ ਕੁੰਜੀ ਕਾਰਵਾਈਆਂ (shortlist, email, status) ਨੂੰ ਇੱਕ ਅੰਗੂਠੇ ਨਾਲ ਪਹੁੰਚਯੋਗ ਬਣਾਓ।
ਮੈਚਿੰਗ ਭਰਤੀ ਵੈੱਬ ਐਪ ਦੀ ਇੰਜਣ ਹੈ: ਇਹ ਨਿਰਧਾਰਤ ਕਰਦੀ ਹੈ ਕਿ ਕੌਣ ਪਹਿਲਾਂ ਨਜ਼ਰ ਆਉਂਦਾ ਹੈ, ਕੌਣ ਲੁਕਿਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਰਿਕ੍ਰੂਟਰ ਕਿਸੇ ਚੀਜ਼ 'ਤੇ ਭਰੋਸਾ ਕਰਦੇ ਹਨ। ਇੱਕ ਚੰਗੇ MVP ਲਈ ਸਧਾਰਨ ਸ਼ੁਰੂ ਕਰੋ—ਸਪਸ਼ਟ ਨਿਯਮ ਪਹਿਲਾਂ, ਸਕੋਰਿੰਗ ਬਾਅਦ—ਫਿਰ ਅਸਲ ਭਰਤੀ ਨਤੀਜਿਆਂ ਤੋਂ ਸਿੱਖ ਕੇ ਜਟਿਲਤਾ ਜੋੜੋ।
ਉਹ ਨਿਯਮ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਲਾਜ਼ਮੀ ਹਨ ਕਿ ਉਮੀਦਵਾਰ ਵਿਚ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ। ਇਹ ਨਤੀਜੇ ਸਬੰਧਤ ਰੱਖਦੇ ਹਨ ਅਤੇ “ਉੱਚ-ਸਕੋਰ ਪਰ অসমਭਵ” ਮੈਚਾਂ ਨੂੰ ਰੋਕਦੇ ਹਨ।
ਆਮ gates ਵਿੱਚ ਸ਼ਾਮਿਲ ਹਨ required skills/certifications, ਸਥਾਨਕਤਾ ਜਾਂ ਵਰਕ-ਅਧਿਕਾਰ ਸ਼ਰਤਾਂ, ਅਤੇ ਤਨਖਾਹ ਦੀ ਓਵਰਲੈਪ (ਉਦਾਹਰਨ: ਉਮੀਦਵਾਰ ਦੀਆਂ ਉਮੀਦਾਂ ਨੌਕਰੀ ਦੇ ਬਜਟ ਨਾਲ ਕੱਟੀ ਪਾਉਂਦੀਆਂ ਹਨ)।
ਜਦੋਂ ਉਮੀਦਵਾਰ gates ਨੂੰ ਪਾਰ ਕਰ ਲੈਂਦੇ ਹਨ, ਤਾਂ ਇੱਕ ਸਕੋਰ ਦੀ ਗਣਨਾ ਕਰੋ ਤਾਂ ਜੋ ਮੈਚਾਂ ਨੂੰ ਰੈਂਕ ਕੀਤਾ ਜਾ ਸਕੇ। ਪਹਿਲੀ ਵਰਜਨ ਨੂੰ ਪਾਰਦਰਸ਼ੀ ਅਤੇ ਬਦਲਣਯੋਗ ਰੱਖੋ।
ਇੱਕ ਵਿਹੰਗਮ ਸਕੋਰਿੰਗ ਮਿਕਸ:
ਤੁਸੀਂ ਇਸਨੂੰ ਬਰੋਜ਼-ਬਦਲਦੇ ਵਜ਼ਨਾਂ ਦੇ ਰੂਪ ਵਿੱਚ ਪ੍ਰਗਟ ਕਰ ਸਕਦੇ ਹੋ:
score = 0.45*skill_match + 0.20*recency + 0.20*seniority_fit + 0.15*keyword_similarity
ਜਾਬ ਜ਼ਰੂਰਤਾਂ ਨੂੰ ਦੋ ਕੇਟੇਗਰੀਜ਼ ਵਿੱਚ ਮਾਡਲ ਕਰੋ:
ਇਸ ਨਾਲ ਮਜ਼ਬੂਤ ਉਮੀਦਵਾਰਾਂ ਨੂੰ ਪਸੰਦਾਂ ਕਰਕੇ ਬਾਹਰ ਕੱਢਿਆ ਨਹੀਂ ਜਾਂਦਾ, ਪਰ ਚੰਗੇ ਫਿਟਾਂ ਨੂੰ ਇਨਾਮ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ।
ਰਿਕ੍ਰੂਟਰਾਂ ਨੂੰ ਪਤਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਕਿਉਂ ਇੱਕ ਉਮੀਦਵਾਰ ਮੈਚ ਹੋਇਆ—ਅਤੇ ਕਿਸੇ ਨੇ ਕਿਉਂ ਨਹੀਂ। ਮੈਚ ਕਾਰਡ 'ਤੇ ਛੋਟਾ ਬ੍ਰੇਕਡਾਊਨ ਦਿਖਾਓ:
ਚੰਗੀ ਸਮਝਣਯੋਗਤਾ ਮੈਚਿੰਗ ਨੂੰ ਇੱਕ ਬਲੈਕ ਬਾਕਸ ਦੀ ਥਾਂ ਇੱਕ ਉਪਕਰਣ ਬਣਾਉਂਦੀ ਹੈ ਜਿਸ 'ਤੇ ਰਿਕ੍ਰੂਟਰ ਭਰੋਸਾ ਕਰ ਸਕਦੇ ਹਨ, ਟਿਊਨ ਕਰ ਸਕਦੇ ਹਨ ਅਤੇ hiring managers ਨੂੰ ਬਚਾ ਸਕਦੇ ਹਨ।
ਉਮੀਦਵਾਰ ਡੇਟਾ ਕੁਆਲਿਟੀ "ਮੈਚ ਕਰਨਾ" ਅਤੇ "ਅਨੁਮਾਨ ਲਗਾਉਣਾ" ਵਿੱਚ ਫਰਕ ਬਣਾਉਂਦੀ ਹੈ। ਜੇ ਪ੍ਰੋਫਾਈਲ ਅਨੁਸ੍ਤ ਹੋਰ-ਹੋਰ ਫਾਰਮੈਟਾਂ ਵਿੱਚ ਆਉਣ, ਤਾਂ ਸੱਭ ਤੋਂ ਵਧੀਆ ਐਲਗੋਰਿਦਮ ਵੀ ਸ਼ੋਰਭਰਪੂਰ ਨਤੀਜੇ ਦੇਵੇਗਾ। ਪਹਿਲਾਂ intake ਰਸਤੇ ਡਿਜ਼ਾਈਨ ਕਰੋ ਜੋ ਰਿਕ੍ਰੂਟਰਾਂ ਅਤੇ ਉਮੀਦਵਾਰਾਂ ਲਈ ਆਸਾਨ ਹੋਣ, ਫਿਰ ਪਾਰਸਿੰਗ ਅਤੇ ਨਾਰਮਲਾਈਜੇਸ਼ਨ ਨੂੰ ਪ੍ਰਗਟਾਵੀ ਤੌਰ 'ਤੇ ਸੁਧਾਰੋ।
ਅਨੇਕ ਰਾਹ ਦਿਓ ਤਾਂ ਟੀਮਾਂ ਰੁਕਾਂਟ ਵਿੱਚ ਨਾ ਆਉਣ:
ਖੇਤਰਾਂ 'ਤੇ ਇੱਕ ਸਪਸ਼ਟ “confidence” ਸੰਕੇਤਕ ਰੱਖੋ (ਜੈਸੇ “parsed,” “user-entered,” “verified by recruiter”) ਤਾਂ ਕਿ ਰਿਕ੍ਰੂਟਰ ਜਾਣ ਸਕਣ ਕਿ ਕਿਸ 'ਤੇ ਭਰੋਸਾ ਕਰਨਾ ਹੈ।
MVP ਵਿੱਚ, ਪੂਰੀ ਸੰਰਚਨਾ ਤੋਂ ਬਖ਼ਰ ਰਹੋ ਅਤੇ ਭਰੋਸੇ ਨੂੰ ਤਰਜੀਹ ਦਿਓ:
ਹਮੇਸ਼ਾ ਰਿਕ੍ਰੂਟਰਾਂ ਨੂੰ parsed ਫੀਲਡ ਸੋਧਣ ਦੀ ਆਗਿਆ ਦਿਓ ਅਤੇ ਬਦਲਾਅ ਦਾ ਆਡਿਟ ਟ੍ਰੇਲ ਰੱਖੋ।
“JS,” “JavaScript,” ਅਤੇ “Javascript” ਨੂੰ ਇੱਕੋ ਹੁਨਰ ਮੰਨਣਾ ਮੈਚਿੰਗ ਨੂੰ ਬਿਹਤਰ ਬਣਾਉਂਦਾ ਹੈ। ਇੱਕ controlled vocabulary ਨਾਲ:
ਸੇਵ-ਟਾਈਮ ਤੇ ਨਾਰਮਲਾਈਜ਼ੇਸ਼ਨ ਲਾਗੂ ਕਰੋ (ਅਤੇ ਜਦ vocabulary ਅਪਡੇਟ ਹੋਵੇ ਤਾਂ ਦੁਬਾਰਾ ਚਲਾਓ) ਤਾਂ ਕਿ search ਅਤੇ ਮੈਚਿੰਗ ਸਥਿਰ ਰਹੇ।
ਡੁਪਲਿਕੇਟ ਬਿਨ੍ਹਾਂ ਸ਼ੋਰ ਬਣ ਜਾਂਦੇ ਹਨ। email ਅਤੇ phone (ਅਤੇ ਵਿਕਲਪਿਕ fuzzy checks name + company) ਵਰਤ ਕੇ সম্ভਾਵੀ duplicates ਪਛਾਣੋ। ਜਦ ਟਕਰਾਅ ਮਿਲੇ, ਇੱਕ ਗਾਈਡ ਕੀਤੀ merger ਸਕ੍ਰੀਨ ਦਿਖਾਓ ਜੋ:
ਇਹ ਡੇਟਾਬੇਸ ਨੂੰ ਸਾਫ਼ ਰੱਖਦਾ ਹੈ ਬਿਨਾਂ ਅਕਸਮਾਤਿਕ ਡੇਟਾ ਨੁਕਸਾਨ ਦੇ।
ਇੱਕ ਮੈਚਿੰਗ ਐਪ ਉਨ੍ਹਾਂ ਨੌਕਰੀਆਂ ਦੇ ਬਗੈਰ ਚੰਗਾ ਨਹੀਂ ਰਹਿੰਦਾ ਜੋ ਉਸ ਵਿੱਚ ਹਨ। ਜੇ requisitions ਅਸੰਗਠਿਤ, ਲਾਪਤਾ ਜਾਂ ਅਪਡੇਟ ਕਰਨ ਵਿੱਚ ਔਖੇ ਹਨ, ਤਾਂ ਰਿਕ੍ਰੂਟਰ ਨਤੀਜਿਆਂ 'ਤੇ ਭਰੋਸਾ ਖੋ ਦੇਣਗੇ। ਤੁਹਾਡਾ ਟੀਚਾ ਜਾਵੇਗਾ ਕਿ ਜਾਬ ਇੰਟੇਕ ਤੇਜ਼, ਢਾਂਚਾ-ਪੂਰਨ ਅਤੇ ਦੁਹਰਾਏ ਜਾ ਸਕਣ—ਪਰ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਲੰਮੇ ਫਾਰਮਾਂ ਵਿੱਚ ਫਸਾਉਣ ਤੋਂ ਬਚਾਓ।
ਰਿਕ੍ਰੂਟਰ ਆਮ ਤੌਰ 'ਤੇ ਤਿੰਨ ਤਰੀਕਿਆਂ ਨਾਲ ਨੌਕਰੀਆਂ ਸ਼ੁਰੂ ਕਰਦੇ ਹਨ:
UI ਵਿੱਚ, “Duplicate job” ਨੂੰ jobs list 'ਤੇ ਇੱਕ ਪਹਿਲੇ ਦਰਜੇ ਦੀ ਕਰਵਾਈ ਬਣਾਓ, ਨਾ ਕਿ ਇੱਕ ਛੁਪਿਆ ਹੋਇਆ ਵਿਕਲਪ।
Free-text job descriptions ਮਨੁੱਖਾਂ ਲਈ ਉਪਯੋਗੀ ਹੁੰਦੇ ਹਨ, ਪਰ ਮੈਚਿੰਗ ਨੂੰ ਬਣਤਰ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਲਗਾਤਾਰ ਖੇਤਰਾਂ ਵਿੱਚ ਜ਼ਰੂਰਤਾਂ ਕੈਪਚਰ ਕਰੋ:
ਇਸਨੂੰ ਹਲਕਾ ਰੱਖੋ: ਇੱਕ ਰਿਕ੍ਰੂਟਰ ਨੂੰ ਸਕਿੱਲਜ਼ ਸਕਿੰਨ ਵਿੱਚ ਸਕਿੰਕੇ ਵਿੱਚ ਜੋੜਨ ਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਫਿਰ ਬਾਅਦ ਵਿੱਚ ਸੁਧਾਰ ਕੀਤਾ ਜਾ ਸਕੇ। ਜੇ ਤੁਸੀਂ parsing ਕਦਮ ਰੱਖਦੇ ਹੋ, ਤਾਂ ਉਨ੍ਹਾਂ ਨੂੰ ਕੇਵਲ ਸੁਝਾਅ ਦੇਣ ਲਈ ਵਰਤੋ—ਆਪੋ-ਆਪ ਨੋਟ ਆਟੋ-ਸੇਵ ਨਾ ਕਰੋ۔
ਹਾਇਰਿੰਗ ਪਾਈਪਲਾਈਨ ਨੂੰ ਇੱਕਸਾਰ ਅਤੇ ਜਾਬ-ਵਿਸ਼ੇਸ਼ ਰੱਖੋ। ਇਕ ਸਾਦਾ ਡਿਫਾਲਟ ਚੰਗਾ ਕੰਮ ਕਰਦਾ ਹੈ:
New → Shortlisted → Submitted → Interview → Offer → Placed
ਹਰ candidate-job ਰਿਸ਼ਤੇ ਨੂੰ ਵਰਤਮਾਨ ਸਟੇਜ, ਸਟੇਜ ਇਤਿਹਾਸ, ਮਾਲਿਕ ਅਤੇ ਨੋਟਸ ਸਟੋਰ ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ। ਇਹ ਰਿਕ੍ਰੂਟਰਾਂ ਲਈ ਇੱਕ ਸਾਂਝਾ ਸਰੋਤ ਦੀ ਸੱਚਾਈ ਦਿੰਦਾ ਹੈ ਅਤੇ ਤੁਹਾਡੇ analytics ਨੂੰ ਮਾਇਨੇਦਾਰ ਬਣਾਉਂਦਾ ਹੈ।
ਟੈਮਪਲੇਟਾਂ ਏਜੰਸੀ ਨੂੰ ਆਮ ਰੋਲਾਂ ਲਈ ਇੰਟੇਕ ਸਟੈੰਡਰਡਾਈਜ਼ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ (ਜੈਸੇ “Sales Development Rep” ਜਾਂ “Warehouse Picker”). ਇੱਕ ਟੈਮਪਲੇਟ ਸਟੇਜ, screening questions, ਅਤੇ ਆਮ must-have skills ਨੂੰ ਪੂਰ-ਫਿਲ ਕਰੇ—ਪਰ ਹਰ ਕਲਾਇੰਟ ਲਈ ਤੇਜ਼ ਸੋਧ ਦੀ ਆਗਿਆ ਦਿਓ।
ਜੇ ਤੁਸੀਂ ਇੱਕ ਸਥਿਰ ਫਲੋ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਜਾਬ ਬਣਾਉਣ ਨੂੰ ਸਿੱਧਾ ਮੈਚਿੰਗ ਅਤੇ shortlisting 'ਚ ਰੂਟ ਕਰੋ, ਫਿਰ ਪਾਈਪਲਾਈਨ ਵਿੱਚ, ਨਾ ਕਿ ਇਨ੍ਹਾਂ ਕਦਮਾਂ ਨੂੰ ਵੱਖ-ਵੱਖ ਸਕ੍ਰੀਨਾਂ 'ਤੇ ਛਿੜਕੋ।
ਸੁਰੱਖਿਆ ਉਸਦੀ ਪਹਿਲੀ ਵਰਜਨ ਵਿੱਚ ਬਣਾਉਣਾ ਅਸਾਨ ਹੁੰਦਾ ਹੈ। ਇੱਕ ਭਰਤੀ ਵੈੱਬ ਐਪ ਲਈ ਲਕੜੀ ਸਧਾਰਨ ਹੈ: ਸਿਰਫ ਸਹੀ ਲੋਕ ਹੀ ਉਮੀਦਵਾਰ ਡੇਟਾ ਨੂੰ ਪਹੁੰਚ ਸਕਣ ਅਤੇ ਹਰ ਮਹੱਤਵਪੂਰਨ ਬਦਲਾਅ ਟ੍ਰੇਸਏਬਲ ਹੋਵੇ।
Email + password authentication ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, ਨਾਲ password reset ਅਤੇ email verification। MVP ਲਈ ਵੀ ਕੁਝ ਪ੍ਰਯੋਗ-ਯੋਗ ਸੁਰੱਖਿਆ ਤਦਬੀਰਾਂ ਜੋੜੋ:
ਵੱਡੀਆਂ ਏਜੰਸੀਆਂ ਲਈ ਭਵਿੱਖ ਵਿੱਚ SSO (SAML/OIDC) ਲਈ ਰਸਤਾ ਯੋਜਨਾਬੱਧ ਕਰੋ ਤਾਂ ਜੋ ਉਹ Google Workspace ਜਾਂ Microsoft Entra ID ਵਰਤ ਸਕਣ। SSO ਨੂੰ ਦਿਨ 1 'ਤੇ ਨਿਰਮਾਣ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਨਹੀਂ ਹੈ, ਪਰ ਐਸੇ ਫੈਸਲਿਆਂ ਤੋਂ بچੋ ਜੋ ਬਾਅਦ ਵਿੱਚ ਇਸਨੂੰ ਜੋੜਨਾ ਮੁਸ਼ਕਿਲ ਬਣਾਉਂਦੇ ਹਨ।
ਘੱਟੋ-ਘੱਟ, ਦੋ ਰੋਲ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ:
ਜੇ ਤੁਹਾਡੇ ਉਤਪਾਦ ਵਿੱਚ ਇਕ ਵਿਕਲਪਿਕ client/hiring manager portal ਹੈ, ਤਾਂ ਇਸਨੂੰ ਵੱਖ-ਵੱਖ ਪਰਮਿਸ਼ਨ ਸੈੱਟ ਵਜੋਂ ਦਿਖਾਓ। ਕਲਾਇੰਟਾਂ ਨੂੰ ਆਮ ਤੌਰ 'ਤੇ ਸੀਮਤ ਪਹੁੰਚ ਚਾਹੀਦੀ ਹੈ (ਉਦਾਹਰਨ: ਕੇਵਲ ਉਹ ਉਮੀਦਵਾਰ ਜਿਨ੍ਹਾਂ ਨੂੰ ਉਨ੍ਹਾਂ ਦੀਆਂ ਨੌਕਰੀਆਂ ਲਈ ਸਬਮਿਟ ਕੀਤਾ ਗਿਆ ਹੈ, ਅਤੇ ਪ੍ਰਾਈਵੇਟ ਵੇਰਵੇ ਸਥਿਤੀ ਅਨੁਸਾਰ ਰੋਕੇ ਹੋ ਸਕਦੇ ਹਨ)।
ਚੰਗਾ ਨਿਯਮ: ਲੋੜੀਂਦੇ ਸਭ ਤੋਂ ਘੱਟ ਪਹੁੰਚ ਨੂੰ ਡਿਫਾਲਟ ਰੱਖੋ, ਅਤੇ ਖਾਸ ਤੌਰ 'ਤੇ ਸਕੱਤੀ ਜੋੜੋ (ਉਦਾਹਰਨ: “ਕੈਨ ਐਕਸਪੋਰਟ candidates”, “ਕੈਨ ਵੀਊ compensation fields”, “ਕੈਨ ਡਿਲੀਟ records”)।
ਭਰਤੀ ਵਿੱਚ ਬਹੁਤ ਸਾਰੇ ਹੱਥ-ਹਵਾਲੇ ਹੁੰਦੇ ਹਨ, ਇਸ ਲਈ ਇੱਕ ਹਲਕੀ ਆਡਿਟ ਟਰੇਲ ਘਲਤਫਹਮੀ ਨੂੰ ਰੋਕਦਾ ਹੈ ਅਤੇ ਅੰਦਰੂਨੀ ਭਰੋਸਾ ਬਣਾਉਂਦਾ ਹੈ। ਮੁੱਖ ਕਾਰਵਾਈਆਂ ਲਾਗ ਕਰੋ ਜਿਵੇਂ:
ਇਹ ਲਾਗਸ ਐਪ ਵਿੱਚ searchable ਰੱਖੋ ਅਤੇ ਇਨ੍ਹਾਂ ਨੂੰ ਸੋਧਣ ਤੋਂ ਬਚਾਓ।
ਰੇਜ਼ਿਊਮੇਆਂ ਬਹੁਤ ਸੰਵੇਦਨਸ਼ੀਲ ਹੁੰਦੀਆਂ ਹਨ। ਉਹਨਾਂ ਨੂੰ ਨਿੱਜੀ object storage ਵਿੱਚ ਸਟੋਰ ਕਰੋ (ਸਾਰਜਨਿਕ URLs ਨਹੀਂ), signed/expiring download links ਦੀ ਲੋੜ ਰੱਖੋ, ਅਤੇ uploads ਨੂੰ malware ਲਈ ਸਕੈਨ ਕਰੋ। ਰੋਲ ਅਨੁਸਾਰ ਪਹੁੰਚ ਸੀਮਤ ਕਰੋ, ਅਤੇ ਜਦ ਸੁਰੱਖਿਅਤ in-app ਲিঙ্ক ਕਾਫੀ ਹੋਵੇ ਤਾਂ attachments ਈਮੇਲ ਰਾਹੀਂ ਨਹੀਂ ਭੇਜੋ।
ਅੰਤ ਵਿੱਚ, ਡੇਟਾ ਟ੍ਰਾਂਜ਼ਿਟ ਅਤੇ ਸੰਭਵ ਹੋਵੇ ਤਾਂ at restਇੰਕ੍ਰਿਪਟ ਕਰੋ, ਅਤੇ ਨਵੀਆਂ ਵਰਕਸਪੇਸ ਲਈ ਸੁਰੱਖਿਆ ਸਮਰੱਥ ਡਿਫਾਲਟ ਬਣਾਓ।
ਭਰਤੀ ਐਪ ਸੰਵੇਦਨਸ਼ੀਲ ਡੇਟਾ ਸੰਭਾਲਦੇ ਹਨ—CVs, ਸੰਪਰਕ ਵੇਰਵੇ, ਤਨਖਾਹ, ਇੰਟਰਵਿਊ ਨੋਟ। ਜੇ ਉਮੀਦਵਾਰ ਇਹ ਨਹੀਂ ਭਰੋਸਾ ਕਰਦੇ ਕਿ ਤੁਸੀਂ ਇਸਨੂੰ ਕਿਵੇਂ ਸਟੋਰ ਅਤੇ ਸਾਂਝਾ ਕਰਦੇ ਹੋ, ਤਾਂ ਉਹ ਸਵੈ-ਭਾਗੀਦਾਰੀ ਨਹੀਂ ਕਰਨਗੇ, ਅਤੇ ਏਜੰਸੀਆਂ ਨੂੰ ਕਾਨੂੰਨੀ ਖ਼ਤਰਾ ਹੋਵੇਗਾ। ਗੁਪਤਤਾ ਅਤੇ ਕੰਪਲਾਇੰਸ ਨੂੰ ਕੋਰ ਪ੍ਰੋਡਕਟ ਫੀਚਰ ਮੰਨੋ, ਬਾਹਰੀ ਤੌਰ ਤੇ ਨਹੀਂ।
ਵੱਖ-ਵੱਖ ਏਜੰਸੀਆਂ ਅਤੇ ਖੇਤਰ ਵੱਖ-ਵੱਖ lawful bases (consent, legitimate interest, contract) ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ। ਹਰ candidate ਰਿਕਾਰਡ 'ਤੇ ਇੱਕ ਕਨਫ਼ਿਗਰਏਬਲ ਟਰੈਕਰ ਬਣਾਓ ਜੋ ਦਿਖਾਉਂਦਾ:
ਕਨਸੈਂਟ ਨੂੰ ਦਿਖਣ ਅਤੇ ਅਪਡੇਟ ਕਰਨ ਨੂੰ ਆਸਾਨ ਬਣਾਓ, ਅਤੇ ਸਾਂਝੇ ਕਰਨ ਵਾਲੀਆਂ ਕਾਰਵਾਈਆਂ (ਪ੍ਰੋਫਾਈਲ ਭੇਜਣਾ, ਐਕਸਪੋਰਟ, ਕੇਂਪੇਨ ਵਿੱਚ ਜੋੜਨਾ) ਉਹਨਾਂ ਸੈਟਿੰਗਾਂ ਦੀ ਜਾਂਚ ਕਰਨ।
ਏਜੰਸੀ ਲੈਵਲ 'ਤੇ ਰਿਟੈਨਸ਼ਨ ਸੈਟਿੰਗਸ ਜੋੜੋ: ਕਿਦਰਾਂ inactive candidates, rejected applicants, ਅਤੇ interview notes ਨੂੰ ਕਿੰਨੀ ਦੇਰ ਰੱਖਣਾ ਹੈ। ਫਿਰ ਸਪਸ਼ਟ ਫਲੋਜ਼ ਲਾਗੂ ਕਰੋ:
ਇਹ ਇਕਸ਼ਕਰੀ ਕਾਰਵਾਈਆਂ auditable ਅਤੇ ਜ਼ਰੂਰਤ ਤੇ ਹੀ reversible ਰੱਖੋ।
ਜਿੱਥੇ ਲਾਜ਼ਮੀ ਹੋਵੇ, ਇੱਕ candidate ਦਾ record ਐਕਸਪੋਰਟ ਕਰਨ ਦੀ ਸਹਾਇਤਾ ਕਰੋ। ਸਧਾਰਣ ਰੂਪ: structured JSON ਐਕਸਪੋਰਟ ਨਾਲ ਇੱਕ human-readable PDF/HTML ਸਾਰ ਸੰਭਵ ਤੌਰ 'ਤੇ ਜ਼ਿਆਦਾ ਲੋੜੀਂਦਾ ਹੁੰਦਾ ਹੈ।
ਟ੍ਰਾਂਜ਼ਿਟ ਅਤੇ at rest ਇੰਕ੍ਰਿਪਸ਼ਨ, ਵੱਖਰੇ ਪਰਿਵੇਸ਼, ਅਤੇ ਮਜ਼ਬੂਤ session management ਵਰਤੋ। ਡਿਫੋਲਟ ਰੋਲ least privilege 'ਤੇ ਰੱਖੋ: recruiters ਨੂੰ by default compensation, private notes, ਜਾਂ ਹਰ client submission ਨਹੀਂ ਵੇਖਣੀ ਚਾਹੀਦੀ।
ਏਕਸਪੋਰਟ/ਦਿੱਖ/ਸਾਂਝੇ ਕਰਨ ਲਈ ਆਡਿਟ ਲਾਗ ਜੋੜੋ ਅਤੇ ਨੀਤੀ ਵਿਵਰਣ /privacy ਤੋਂ ਲਿੰਕ ਕਰੋ ਤਾਂ ਏਜੰਸੀ ਉਮੀਦਵਾਰਾਂ ਨੂੰ ਤੁਹਾਡੇ ਸੁਰੱਖਿਆ ਉਪਾਇਆਂ ਦੇ ਸਕੇ।
ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਤੈਅ ਕਰਦੇ ਹਨ ਕਿ ਤੁਹਾਡੀ ਭਰਤੀ ਐਪ ਰਿਕ੍ਰੂਟਰਾਂ ਦਿਨਚਰਿਆ ਵਿੱਚ ਕੁਦਰਤੀ ਤਰੀਕੇ ਨਾਲ ਫਿੱਟ ਹੁੰਦੀ ਹੈ ਜਾਂ "ਇਕ ਹੋਰ ਟੈਬ" ਬਣ ਜਾਂਦੀ ਹੈ। ਪਹਿਲਾਂ ਛੋਟਾ ਪਰ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਸੈੱਟ ਟੀਚਾ ਬਣਾਉ ਅਤੇ ਬਾਕੀ ਸਾਰਾ ਕੁਝ ਇੱਕ ਸਾਫ਼ API ਪਰਤ ਦੇ ਪਿੱਛੋਂ ਰੱਖੋ ਤਾਂ ਕਿ ਬਾਅਦ ਵਿੱਚ ਹور ਜੋੜਨਾ ਆਸਾਨ ਰਹੇ।
ਈਮੇਲ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਕਿਉਂਕਿ ਇਹ outreach ਨੂੰ ਸਿੱਧੇ ਸਹਾਰਾ ਦਿੰਦੀ ਹੈ ਅਤੇ ਕੀਮਤੀ ਗਤੀਵਿਧੀ ਇਤਿਹਾਸ ਬਣਾਉਂਦੀ ਹੈ।
Gmail ਅਤੇ Microsoft 365 ਨਾਲ ਜੁੜਨ ਲਈ:
ਸਧਾਰਨ ਰੱਖੋ: message metadata (subject, timestamp, participants) ਅਤੇ body ਦੀ ਸੁਰੱਖਿਅਤ ਨਕਲ ਸਟੋਰ ਕਰੋ ਤਾਂ ਕਿ search ਲਈ ਉਪਲਬਧ ਹੋਵੇ। logging ਨੂੰ explicit ਰੱਖੋ ਤਾਂ ਕਿ ਰਿਕ੍ਰੂਟਰ ਚੁਣ ਸਕਣ ਕਿ ਕਿਹੜੇ thread ਸਿਸਟਮ ਵਿੱਚ ਜਾਣ।
Calendar ਜੇਕਰ timeline ਬਚਾਵੇ ਤਾਂ ਬਾਅਦ ਵਿੱਚ ਜੋੜੋ, ਪਰ ਜੇ ਇਹ ਤੁਹਾਡੇ ਸਮਾਂ-ਰੇਖਾ ਨੂੰ ਖ਼ਤਰੇ ਵਿੱਚ ਪਾਉਂਦਾ ਹੈ ਤਾਂ ਇਸਨੂੰ ਸਿਖਰ ਨ ਕਰੋ। Google Calendar / Outlook Calendar ਨਾਲ ਤੁਸੀਂ interview events ਬਣਾਉ, ਸਮੇਂ ਪ੍ਰਸਤਾਵਿਤ ਕਰੋ, ਅਤੇ outcome ਲਿਖ ਸਕਦੇ ਹੋ।
ਸ਼ੁਰੂਆਤੀ ਵਰਜਨਾਂ ਲਈ, events ਬਣਾਉਣਾ + attendees ਜੋੜਨਾ + ਇੰਟਰਵਿਊ ਵੇਰਵੇ candidate pipeline stage 'ਤੇ ਵਾਪਸ ਲਿਖਣਾ ਤੇ ਧਿਆਨ ਕੇਂਦਰਿਤ ਕਰੋ।
ਬਹੁਤ ਸਾਰੀਆਂ ਏਜੰਸੀਆਂ ਪਹਿਲਾਂ ਹੀ ATS/CRM ਵਰਤਦੀਆਂ ਹਨ। ਮੁੱਖ events (candidate created/updated, stage changed, interview scheduled) ਲਈ webhooks ਦਿਓ ਅਤੇ ਆਪਣੇ REST endpoints ਸਪੱਠ ਦਸਤਾਵੇਜ਼ ਕਰੋ ਤਾਂ ਕਿ ਭਾਗੀਦਾਰ ਤੇਜ਼ੀ ਨਾਲ ਕਨੈਕਟ ਹੋ ਸਕਣ। /docs/api ਵਰਗਾ ਇੱਕ ਸਧਾਰਣ ਪੇਜ ਸੋਚੋ ਅਤੇ ਇੱਕ ਹਲਕਾ “integration settings” ਸਕ੍ਰੀਨ।
Job board posting ਅਤੇ inbound applicants ਸ਼ਕਤੀਸ਼ਾਲੀ ਹਨ, ਪਰ ਇਹ complexity ਲਿਆਉਂਦੇ ਹਨ (ad ਨੀਤੀਆਂ, duplicate applicants, source tracking)। ਇਨ੍ਹਾਂ ਨੂੰ ਫੇਜ਼ 2 ਵਜੋਂ ਲਓ:
ਹੁਣ ਆਪਣੀ ਡੇਟਾ ਮਾਡਲ ਨੂੰ ਐਸਾ ਡਿਜ਼ਾਈਨ ਕਰੋ ਕਿ “source” ਅਤੇ “application channel” ਆਉਣ ਵਾਲੇ ਸਮੇਂ ਪਹਿਲੀ-ਕ੍ਲਾਸ ਖੇਤਰ ਹੋਣ।
ਤੁਹਾਡਾ ਟੈਕ ਸਟੈਕ MVP ਤੇਜ਼ੀ ਨਾਲ ਭੇਜਣ ਲਈOptimize ਕਰੇ, ਜਦਕਿ ਭਵਿੱਖ ਵਿੱਚ ਚੰਗੀ search ਅਤੇ integration ਲਈ ਥਾਂ ਛੱਡੇ। ਭਰਤੀ ਐਪ ਦੀਆਂ ਦੋ ਵੱਖ-ਵੱਖ ਲੋੜਾਂ ਹਨ: transactional workflows (ਪਾਈਪਲਾਈਨ, ਪਰਮਿਸ਼ਨ, ਆਡਿਟ ਲਾਗ) ਅਤੇ ਤੇਜ਼ search/ranking (candidate-to-job matching)।
ਆਧੁਨਿਕ JavaScript ਸਟੈਕ ਲਈ, React + Node.js (NestJS/Express) ਆਮ ਚੋਣ ਹੈ: frontend ਅਤੇ backend ਲਈ ਇੱਕੋ ਭਾਸ਼ਾ, ਬਹੁਤ ਸਾਰੀਆਂ ਲਾਇਬਰੇਰੀਆਂ, ਅਤੇ ਸਿੱਧਾ ਇਕਤੀਕਰਨ ਕੰਮ।
ਜੇ ਤੁਸੀਂ ਤੇਜ਼ CRUD ਅਤੇ ਮਜ਼ਬੂਤ ਰਵਾਇਤਾਂ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ Rails ਜਾਂ Django ਮੂਲ ATS/CRM ਵਰਕਫਲੋਜ਼ ਬਣਾਉਣ ਲਈ ਸ਼ਾਨਦਾਰ ਹਨ। ਦੋਹਾਂ ਨੂੰ ਇੱਕ ਹਲਕੀ frontend (Rails views, Django templates) ਜਾਂ React ਨਾਲ ਜੋੜ ਸਕਦੇ ਹੋ ਜੇ ਤੁਹਾਨੂੰ ਰਿਚਰ UI ਚਾਹੀਦਾ ਹੋਵੇ।
ਜੇ ਤੁਹਾਡਾ ਮੁੱਖ ਰੁਕਾਵਟ ਪ੍ਰੋਟੋਟਾਈਪ ਤੱਕ ਤੇਜ਼ੀ ਹੈ (ਖ਼ਾਸ ਕਰਕੇ internal tools ਜਾਂ ਸ਼ੁਰੂਆਤੀ ਪਰਖ ਲਈ), ਤਾਂ Koder.ai ਵਰਗਾ ਇੱਕ vibe-coding ਪਲੇਟਫਾਰਮ ਤੁਹਾਨੂੰ ਇੱਕ ਸੰਰਚਿਤ chat spec ਤੋਂ end-to-end MVP ਬਣਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ: ਕੋਰ ਸਕ੍ਰੀਨ, ਵਰਕਫਲੋ, ਅਤੇ ਬੇਲਿਨ ਡੇਟਾ ਮਾਡਲ। ਟੀਮਾਂ ਅਕਸਰ ਇਸਨੂੰ planning mode ਵਿੱਚ ਤੇਜ਼ iteration ਲਈ ਵਰਤਦੀਆਂ ਹਨ, ਫਿਰ ਜਦ ਤਿਆਰ ਹੋਣ, source code export ਕਰ ਲੈਂਦੀਆਂ ਹਨ। Snapshots ਅਤੇ rollback ਵੀ matching ਬਦਲਾਅ ਆਜ਼ਮਾਉਣ ਸਮੇਂ ਐਪ ਨੂੰ ਟੁਟਣ ਤੋਂ ਬਚਾਉਂਦੇ ਹਨ।
PostgreSQL ਵਰਗਾ ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸ ਆਪਣਾ ਸਰੋਤ-ਅਫ-ਸੱਚਾਈ ਬਣਾਓ। ਭਰਤੀ ਡੇਟਾ workflow-heavy ਹੈ: candidates, jobs, stages, notes, tasks, emails, ਅਤੇ permissions ਸਭ transactions ਅਤੇ constraints ਨਾਲ ਲਾਭ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਨ।
“Documents” (ਰੇਜ਼ਿਊਮੇ, attachments) ਨੂੰ object storage (S3-compatible) ਵਿੱਚ ਸਟੋਰ ਕਰੋ ਅਤੇ metadata Postgres ਵਿੱਚ ਰੱਖੋ।
Postgres full-text search ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ keyword queries ਅਤੇ filters ਲਈ। ਇਹ MVP ਲਈ ਬਹੁਤ ਵਾਰ ਕਾਫੀ ਹੁੰਦਾ ਹੈ ਅਤੇ ਇੱਕ ਵੱਖਰੇ ਸਿਸਟਮ ਨੂੰ ਚਲਾਉਣ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ।
ਜਦ ਮੈਚਿੰਗ ਅਤੇ search ਬਣਦੇ ਬੋਤਲਨੇਕ (ਜਟਿਲ ਰੈਂਕਿੰਗ, synonyms, fuzzy queries, high volume), ਤਾਂ Elasticsearch/OpenSearch ਜਿਵੇਂ dedicated index ਜੋੜੋ—Postgres ਤੋਂ asynchronous طور ਤੇ ਫੀਡ ਕੀਤਾ।
staging ਅਤੇ production ਵੱਖਰੇ ماحول ਰੱਖੋ ਤਾਂ ਕਿ ਤੁਸੀਂ parsing, matching, ਅਤੇ integrations ਨੂੰ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਟੈਸਟ ਕਰ ਸਕੋ।
ਆਪੋ-ਆਪ ਬੈਕਅਪ, ਮੁਢਲਾ ਮਾਨਿਟਰਿੰਗ (errors, latency, queue depth), ਅਤੇ ਲਾਗਤ-ਨਿਯੰਤਰ (log retention, right-sized instances) ਸੈੱਟ ਕਰੋ। ਇਹ ਸਿਸਟਮ ਨੂੰ ਅਨੁਮਾਨਯੋਗ ਰੱਖਦਾ ਹੈ ਜਦ ਤੁਸੀਂ ਹੋਰ recruiters ਅਤੇ ਹੋਰ ਡੇਟਾ ਜੋੜਦੇ ਹੋ।
ਮੈਚਿੰਗ ਤਦ ਹੀ ਬਿਹਤਰ ਹੁੰਦੀ ਹੈ ਜਦ ਤੁਸੀਂ ਨਤੀਜਿਆਂ ਨੂੰ ਮਾਪਦੇ ਹੋ ਅਤੇ ਰਿਕ੍ਰੂਟਰ ਫੈਸਲਿਆਂ ਦੇ “ਕਿਉਂ” ਨੂੰ ਕੈਪਚਰ ਕਰਦੇ ਹੋ। ਟੀਚਾ vanity metrics ਨਹੀਂ—ਇੱਕ ਤਿੱਘਾ ਲੂਪ ਹੈ ਜਿਸ 'ਚ ਹਰ shortlist, interview, ਅਤੇ placement ਤੁਹਾਡੀਆਂ ਸਿਫਾਰਿਸ਼ਾਂ ਨੂੰ ਜ਼ਿਆਦਾ ਸਹੀ ਬਣਾਂਦੇ ਹਨ।
ਛੋਟੇ KPIs ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਏਜੰਸੀ ਪ੍ਰਦਰਸ਼ਨ ਨਾਲ ਜੁੜੇ ਹੋਣ:
KPIs ਨੂੰ client, role type, seniority, ਅਤੇ recruiter ਨਾਲ ਫਿਲਟਰ ਕਰਨਯੋਗ ਰੱਖੋ ਤਾਂ ਜੋ ਨੰਬਰ ਕਾਰਗਰ ਬਣਨ।
ਫੈਸਲੇ ਜਿੱਥੇ ਹੁੰਦੇ ਹਨ ਉਥੇ ਹਲਕੇ ਫੀਡਬੈਕ ਜੋੜੋ (match list ਅਤੇ ਪ੍ਰੋਫਾਈਲ): ਥੰਬਸ ਅੱਪ/ਡਾਊਨ, ਨਾਲ ਵਿਕਲਪਿਕ ਕਾਰਨ (ਜੈਸੇ “salary mismatch,” “missing certification,” “location/visa,” “industry experience,” “poor response rate”).
ਫੀਡਬੈਕ ਨੂੰ outcomes ਨਾਲ ਜੋੜੋ:
ਇਸ ਨਾਲ ਤੁਸੀਂ ਆਪਣੀ ਸਕੋਰਿੰਗ ਨੂੰ ਹਕੀਕਤ ਨਾਲ ਤੁਲਨਾ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਵਜ਼ਨਾਂ ਜਾਂ ਨਿਯਮਾਂ ਨੂੰ ਸਬੂਤ ਦੇ ਨਾਲ ਟਿਊਨ ਕਰ ਸਕਦੇ ਹੋ।
ਕੁਝ ਡਿਫੌਲਟ ਰਿਪੋਰਟ ਬਣਾਓ:
ਡੈਸ਼ਬੋਰਡ ਨੂੰ ਇੱਕ ਸਕੀਨ 'ਤੇ “ਇਸ ਹਫ਼ਤੇ ਕੀ ਬਦਲਿਆ?” ਦਾ ਜਵਾਬ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ, ਫਿਰ ਡ੍ਰਿੱਲ-ਡਾਊਨ ਦੀ ਆਗਿਆ ਦਿੰਦੇ ਹੋਏ। ਹਰ ਸਾਰਣੀ ਨੂੰ CSV/PDF ਲਈ ਐਕਸਪੋਰਟੇਬਲ ਬਣਾਓ ਤਾਂ ਕਿ ਕਲਾਇਟ ਅਪਡੇਟਾਂ ਅਤੇ ਅੰਦਰੂਨੀ ਸਮੀਖਿਆ ਲਈ ਵਰਤੀ ਜਾ ਸਕੇ, ਅਤੇ ਪਰਿਭਾਸ਼ਾਵਾਂ ਦਿੱਖ ਨੋਟ/ਸਹਾਇਤਾ (tooltip ਜਾਂ /help) 'ਤੇ ਰੱਖੋ ਤਾਂ ਹਰ ਕੋਈ ਇਕੋ ਹੀ ਢੰਗ ਨਾਲ ਮੈਟ੍ਰਿਕਸ ਸਮਝੇ।
ਇੱਕ ਭਰਤੀ ਐਪ ਅਸਲ ਰੋਲਾਂ, ਅਸਲ ਉਮੀਦਵਾਰਾਂ ਅਤੇ ਅਸਲ ਸਮਿਆਂ 'ਤੇ ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਕੰਮ ਕਰਨ ਤੇ ਸਫਲ ਹੁੰਦੀ ਹੈ। ਲਾਂਚ ਨੂੰ ਸਿੱਖਣ ਦੀ ਸ਼ੁਰੂਆਤ ਮੰਨੋ—ਅੰਤ ਨਹੀਂ।
ਪਹਿਲੇ ਯੂਜ਼ਰਾਂ ਨੂੰ ਬੁਲਾਉਣ ਤੋਂ ਪਹਿਲਾਂ, ਇਹ ਪੱਕਾ ਕਰੋ ਕਿ ਮੁੱਢਲੇ ਚੀਜ਼ਾਂ ਸਿਰਫ਼ ਬਣੀਆਂ ਨਹੀਂ, ਬਲਕਿ end-to-end ਵਰਤਣਯੋਗ ਹਨ:
ਤੁਹਾਨੂੰ ਵੱਡੀ ਟੈਸਟ ਸੂਟ ਦੀ ਲੋੜ ਨਹੀਂ, ਪਰ ਸਹੀ ਟੈਸਟਾਂ ਦੀ ਲੋੜ ਹੈ:
1–3 ਏਜੰਸੀਆਂ (ਜਾਂ ਅੰਦਰੂਨੀ ਟੀਮਾਂ) ਨਾਲ pilot ਕਰੋ ਜੋ ਹਫ਼ਤਾਵਾਰ ਫੀਡਬੈਕ ਦੇਣਗੀਆਂ। ਪਹਿਲਾਂ ਤੋਂ ਸਫਲਤਾ ਦੇ ਮੈਟ੍ਰਿਕਸ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ: time-to-shortlist, ਈਮੇਲ ਘਟਾਉਣਾ, ਅਤੇ ਰਿਕ੍ਰੂਟਰ ਭਰੋਸਾ match explanations ਵਿੱਚ।
ਦੋ-ਹਫ਼ਤਾਵਾਰ cadence ਚਲਾਉ: ਮੁੱਦੇ ਇਕੱਠੇ ਕਰੋ, ਸਿਖਰ-ਰੋਕਡ ਕਾਰਜ ਠੀਕ ਕਰੋ, ਅਤੇ ਸੁਧਾਰ ਰਿਲੀਜ਼ ਕਰੋ। ਬਦਲਾਅਆਂ ਨੂੰ ਇੱਕ ਹਲਕੀ ਚੇਂਜਲੌਗ ਵਿੱਚ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰੋ (ਉਦਾਹਰਨ: /blog)।
ਜਦ ਕੋਰ ਵਰਕਫਲੋ ਸਥਿਰ ਹੋ ਜਾਵੇ, ਤਰਜੀਹ ਦਿਓ:
ਜਦ ਤੁਸੀਂ tiers ਜੋੜਦੇ ਹੋ (ਉਦਾਹਰਨ: portal access, integrations, advanced analytics), ਤਾਂ /pricing 'ਤੇ ਪੈਕੇਜਿੰਗ ਸਪਸ਼ਟ ਰੱਖੋ।
ਇੱਕ ਬੰਦ-ਲੂਪ ਵਰਕਫਲੋ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਇਕ ਰਿਕ੍ਰੂਟਰ ਦਿਨਾਨੁਸਾਰ ਪੂਰਾ ਕਰ ਸਕੇ:
ਜੇ ਕੋਈ ਫੀਚਰ ਸਿੱਧਾ ਇਸ ਲੂਪ ਨੂੰ ਸਹਾਰਾ ਨਹੀਂ ਦਿੰਦਾ (ਜੈਸੇ ਨੌਕਰੀ ਬੋਰਡ ਪੋਸਟਿੰਗ, ਜਟਿਲ ਆਟੋਮੇਸ਼ਨ, hiring manager ਪੋਰਟਲ), ਉਸਨੂੰ ਫੇਜ਼ 2 ਲਈ ਮੁੜ ਦਿਓ।
ਹਰ ਪ੍ਰਮੁੱਖ ਯੂਜ਼ਰ ਲਈ 2–3 “ਟੌਪ ਟਾਸਕ” ਚੁਣੋ ਤੇ ਉਹਨਾਂ ਦੇ ਆਧਾਰ 'ਤੇ ਡਿਜ਼ਾਈਨ ਕਰੋ।
ਜੇ ਤੁਸੀਂ hiring managers ਨੂੰ v1 ਵਿੱਚ ਸ਼ਾਮਿਲ ਕਰਦੇ ਹੋ, ਤਾਂ ਪਰਮਿਸ਼ਨ ਮਾਡਲ ਅਤੇ ਨੋਟੀਫਿਕੇਸ਼ਨ ਨਿਯਮ ਪਹਿਲਾਂ ਹੀ ਯੋਜਨਾ ਵਿੱਚ ਰੱਖੋ।
“ਬਿਹਤਰ ਮੈਚ” ਵਰਗੀਆਂ ਧੁੰਦਲੀ ਲਕੜੀਆਂ ਦੀ ਥਾਂ ਮਾਪੇ ਜਾ ਸਕਣ ਵਾਲੇ, ਵਰਕਫਲੋ ਨਾਲ ਜੁੜੇ ਮੈਟ੍ਰਿਕਸ ਚੁਣੋ। ਸ਼ੁਰੂਆਤੀ ਲਈ ਚੰਗੇ ਨਾਪ:
ਇਹ ਮੈਟ੍ਰਿਕਸ ਤੁਹਾਨੂੰ ਇਹ ਪਤਾ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ ਕਿ ਸਕੋਰਿੰਗ ਬਦਲਾਅ ਅਸਲ ਨਤੀਜਿਆਂ ਨੂੰ ਸਧਾਰਨ ਕਰ ਰਹੇ ਹਨ ਜਾਂ ਨਹੀਂ।
ਮੂਲ ਇੰਟਿਟੀਜ਼ ਨੂੰ ਸਧਾਰਨ ਰੱਖੋ ਅਤੇ ਵਰਕਫਲੋ ਨੂੰ ਰਿਲੇਸ਼ਨਸ਼ਿਪ ਵਜੋਂ ਮਾਡਲ ਕਰੋ:
ਇਹ ਰਚਨਾ ਮੈਚਿੰਗ, ਰਿਪੋਰਟਿੰਗ ਅਤੇ ਆਡਿਟ ਟਰੇਲਾਂ ਨੂੰ ਵਿਸਥਾਰ ਹੋਣ ਤੇ ਵੀ ਸਥਿਰ ਰੱਖਦੀ ਹੈ।
ਜੋ ਤੁਸੀਂ ਸਟੋਰ ਕਰਦੇ ਹੋ ਅਤੇ ਜੋ ਤੁਸੀਂ ਖੋਜਦੇ ਹੋ, ਉਹਨੂੰ ਵੱਖਰੇ ਰੱਖੋ:
ਇਸ ਨਾਲ parsing ਗਲਤੀਆਂ ਰਿਕ੍ਰੂਟਰ-ਮੰਨਿਆ ਡੇਟਾ ਨੂੰ ਗਲਤ ਤਰੀਕੇ ਨਾਲ ਓਵਰਰਾਈਟ ਕਰਨ ਤੋਂ ਰੋਕਦਾ ਹੈ ਅਤੇ ਸਮੇਂ ਨਾਲ ਮੈਚ ਕੁਆਲਿਟੀ ਨੂੰ ਬਿਹਤਰ ਬਣਾਉਂਦਾ ਹੈ।
ਸਪਸ਼ਟ ਨਿਯਮਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, ਫਿਰ ਸਕੋਰਿੰਗ ਜੋੜੋ:
ਵਜਨ ਸਮੇਂ-ਸਮੇਂ 'ਤੇ ਅਨੁਕੂਲ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ ਅਤੇ ਹਰ ਨਤੀਜੇ 'ਤੇ “ਸੂਝਣ ਦਾ ਕਾਰਨ” ਦਿਖਾਓ।
ਸਪਸ਼ਟਤਾ ਹੀ ਉਸ ਚੀਜ਼ ਨੂੰ ਬਣਾਉਂਦੀ ਹੈ ਜਿਸ 'ਤੇ ਰਿਕ੍ਰੂਟਰ ਭਰੋਸਾ ਕਰਦੇ ਹਨ (ਅਤੇ ਜਿਸਨੂੰ ਠੀਕ ਕਰ ਸਕਦੇ ਹਨ)।
ਜਾਬ ਜ਼ਰੂਰਤਾਂ ਨੂੰ ਦੋ ਬੱਕੇਟਾਂ ਵਿੱਚ ਦਰਸਾਓ:
ਇਸ ਨਾਲ ਤਾਕਤਵਰ ਉਮੀਦਵਾਰਾਂ ਨੂੰ ਪਸੰਦਰੁਕੀ ਕਾਰਨਾਂ ਕਰਕੇ ਖਾਰਜ ਹੋਣ ਤੋਂ ਰੋਕਿਆ ਜਾਂਦਾ ਹੈ, ਫਿਰ ਵੀ ਚੰਗੇ ਫਿਟ ਨੂੰ ਇਨਾਮ ਮਿਲਦਾ ਹੈ।
ਹਰ ਪੜਚੋਲ ਅਤੇ ਲੇਖਨ-ਪਾਠ ਰਸਤੇ 'ਤੇ ਪਰਮਿਸ਼ਨ ਬਣਾਉ। ਮੁੱਢਲੇ ਤੌਰ 'ਤੇ ਘੱਟੋ-ਘੱਟ ਇਹ ਰੋਲ ਹੋਣ ਚਾਹੀਦੇ ਹਨ:
ਹੇਸਾਬੀ ਰਿਕਾਰਡਾਂ ਲਈ ਆਡਿਟ ਟਰੇਲ ਜੋੜੋ: ਸੋਧਾਂ, submission, ਸਟੇਜ ਬਦਲਾਅ ਆਦਿ।
ਡਿਫੋਲਟ least privilege ਰੱਖੋ ਅਤੇ ਖਾਸ ਅਧਿਕਾਰ ਸੰਭਵ ਤੌਰ 'ਤੇ ਜੋੜੋ (ਉਦਾਹਰਨ: “ਕੈਨ ਐਕਸਪੋਰਟ candidates”)।
ਕੰਪਲਾਇੰਸ ਨੂੰ ਇੱਕ ਪ੍ਰੋਡਕਟ ਵਿਵਹਾਰ ਸਮਝੋ, ਦਸਤਾਵੇਜ਼ ਨਹੀਂ:
ਇਹ ਸਭ sensitive actions auditable ਰੱਖੋ ਅਤੇ ਨੀਤੀਆਂ ਨੂੰ /privacy ਤੋਂ ਜੋੜੋ ਤਾਂ ਜੋ ਏਜੰਸੀਆਂ ਉਮੀਦਵਾਰਾਂ ਨੂੰ ਸੁਰੱਖਿਆ ਵਿਆਖਿਆ ਕਰ ਸਕਣ।
ਭਰੋਸੇਯੋਗੀ ਅਤੇ ਸਿੱਖਣ ਲਈ ਲਾਂਚ ਕਰੋ:
ਛੋਟੇ ਬਦਲਾਅ ਤੇਜ਼ੀ ਨਾਲ ਰਿਲੀਜ਼ ਕਰੋ ਅਤੇ ਇੱਕ ਹਲਕੀ ਚੇਂਜਲੌਗ ਰੱਖੋ (ਉਦਾਹਰਨ: /blog)।