Hiring, from Excel and paper
to one system.
JindalX was a legacy BPO company. Hiring ran on Excel sheets, hand-made offer letters and printed, signed papers. I wrote six linked specs and built each one, so a hire could move from requisition to onboarding in a single system.
The short
version.
At a glance
| Role | On the digital transformation team. I owned automating hiring end to end. I wrote each PRD and built each system. |
| Scope | About six linked sub-projects over 5 to 6 months. |
| What shipped | A requisition form, a candidate sourcing site, screening and interview rounds, a feedback and rating form, an automatic offer letter and onboarding forms, all in one system. |
| Result | Hiring time fell 50%, measured on the talent acquisition team scorecard. |
| Limit | The AI was one basic OpenAI call at screening. I have no exact accuracy figure, and other changes in that period may also have helped the 50%. |
Project overview
OverviewThis was not one PRD. It was a chain of six linked specs. Each one fed the next, and I wrote and built every link. The goal from day one was data accuracy: the new tool had to match the accuracy of the old manual process, and then remove the chasing.
Hiring ran on
Excel, paper and follow-ups.
01 · Problem
Hiring at JindalX was fully manual. Excel sheets tracked the process. Offer letters were made by hand. Onboarding meant printed papers that people signed and returned.
Teams often started a requisition, sourcing or an interview round with half the information. The talent acquisition (TA) team then chased hiring managers many times for round feedback. The cost was not only time. It was wrong data in a process that ends in a signed salary.
Six specs.
One chain.
02 · The chain
1 · Manpower requisition form
Captures salary band, department, years of experience and city. Every field is mandatory.
2 · Candidate sourcing site
Part of the same chain, on the same strict data structure.
3 · Screening and interview rounds
The only AI step lives here: a skill match against the requisition.
4 · Feedback and rating form
Managers file round feedback through an automated form sent by email.
5 · Automatic offer letter
The hiring team picks band, salary structure, department and role. The system builds the letter and emails it.
6 · Onboarding forms
On acceptance, forms go out by email. The hiring team is told when they are complete.
One product, two views
For executives
Function and flow. How the solution works and how the user moves through it. For the requisition form: what it captures at a high level.
For engineers
The minute detail. The exact database tables with a data type for each field, every automation, every rule and check, and who gets what level of access.
The offer letter.
Where a wrong rule costs money.
03 · Deep dive
I chose the offer letter for the deep dive. A wrong letter is a wrong salary in a signed document. It had the most rules and the most edge cases of the six.
| Rule | What it did |
|---|---|
| Band sets the default | Band comes from role and hierarchy, and it sets the default salary structure. |
| Low pay adds components | Government minimum pay rules added salary components for low BPO pay. |
| City changes the structure | JindalX hired in many cities. A component added for one city had to be removed for another. Leave policy also differed by city. |
| Client pay beats the band | If the client approved Rs 20,000 for an agent and the band said Rs 25,000, the 20,000 won. |
| Manager override, by design | Some cases were too tricky to write as rules. Only manager-level users could pick a different band. Individual TAs could not. |
The governance choice. I built a controlled exception instead of forcing a rule for every case. The precedence held in most cases. Minor client and city exceptions existed, and the manager override covered the rest.
Audit trail. Every action was tied to the user’s login and stored in a table. At month end, the department head could see who did what.
The new tool had to
match the old process.
04 · Testing and acceptance
I set the acceptance bar from our own history. We loaded real candidate details and real requisition forms, then tested the whole tool end to end on that data, including the AI step. The bar: the new tool must give the accuracy the old manual process gave.
I then broke that bar down into criteria for each component, using the same logic. The scale was about 40 to 50 historical records for each database table, then a few full processes run by hand from start to finish.
What I do not have. I do not have exact accuracy figures from that testing, so I do not quote one.
What the AI did, exactly
One basic OpenAI call, only at screening. It pulled a skill list from the candidate’s document and matched it to the requisition’s skill list. A formula turned the match into a percent.
The pass benchmark was set per role. It was lower for agents, where communication matters more than client knowledge, and higher for technical roles. The offer letters, forms and routing were rules and workflow, not AI.
Five levels
of review.
05 · Review chain
1 · Author
Me.
2 · My boss
The AGM of the digital transformation team.
3 · Business head
The head of the talent acquisition department.
4 · People team
The C-suite head of the HR function.
In parallel · Growth
The Chief Growth Officer, who sat level with the CEO and COO and led the digital transformation team directly.
Accuracy against speed.
I held the line.
06 · The hardest tradeoff
I made fields mandatory on every input form and defined a strict data structure. Before, teams started with half the information. Now they had to gather it first.
That added work for the TA team, and they pushed back. It also caused friction at launch, because users did not have full information ready when they tried to start a requisition. I held the line, because accuracy was the goal from day one.
The adoption drive
About one month
Separate training sessions for hiring managers, TA team members and TA managers.
A guide per user type
TA team: long and end to end. Hiring managers: raising a requisition, giving round feedback and approving flows.
Q&A on demand
Sessions whenever questions built up.
The lesson. A rule that protects data quality moves work onto the user. Plan the adoption, not just the rule.
A 50% drop in hiring time.
And how I know.
07 · Result
The source is the TA team scorecard, where hiring time is a main KRA. The department baseline existed before launch. I measured the new baseline after launch and adoption.
I will be exact rather than round up: other changes in that period may also have helped. The scorecard is the evidence, and it is a before-and-after, not a controlled test.
Other gains were better data accuracy and fewer follow-ups. Before, TA chased hiring managers many times for round feedback. After, managers filed it through an automated form sent by email.