LinkedIn Recruiter Utilization Analysis — finding the leak without guessing
The problem: A large LinkedIn Recruiter footprint was being treated like a fixed cost. Seats and job slots were available, but the real question was sharper: which capacity was actually supporting hiring, and which capacity was just sitting in the stack?
What I built: A month-by-month utilization model using reporting from the tool itself. I read recruiter-level activity, seat usage, job-slot use, and workflow demand together instead of treating one export as the answer.
Approach: I separated three questions that usually get blurred together: who is using the tool, where capacity is idle, and whether low usage points to training, redistribution, ownership, or reduction. The goal was not to punish low adoption. It was to understand what the tool was actually doing for the hiring process.
Outcome: Created a defensible path to resize or redeploy underused capacity while preserving the parts recruiters actually relied on. The recommendation was not "cut the tool." It was: recover the spend or recover the capability.
Lesson learned: Spend leaks do not show up in totals. They show up when seat capacity, job-slot demand, and workflow reality are read together.
CRM Implementation — making the workflow testable
The problem: The tool was being configured before the recruiting process was fully settled. Teams did similar work in different ways, and some of the people who would use the system every day were not close enough to the early design conversations. That matters because a CRM does not just store activity. It shapes how recruiters communicate, campaign, track, and report.
What I built: I turned open-ended workflow questions into things the project could test. I wrote and refined 124 test scripts, set up a way for global testers to submit issues, reviewed the feedback, documented defects, and built recruiter training around the places where the system would change day-to-day work.
Approach: I kept bringing the work back to ordinary recruiter behavior. If a recruiter sends a campaign, follows up by SMS, runs an event, checks analytics, or fixes a candidate record, what should happen next? What should the system capture? What would confuse the user? What would break reporting later? Those questions were more useful than asking whether the screen technically worked.
Outcome: The implementation had a clearer testing path before go-live. Issues moved from scattered tester reactions into documented findings, defects, and training needs. It also made the risk visible: if the real workflow is not written down, the tool will enforce whatever version of the process happens to make it into configuration.
Lesson learned: Before a recruiting CRM can work, the team has to define the process it is supposed to make easier.
Compliance Audit Automation — the audit machine, demonstrated
The problem: Manual compliance reviews couldn't keep up with posting volume. Non-compliant postings were reaching candidates before anyone caught them, and leadership had no visibility into the pattern.
What I built: A working MVP of the same machine my audits run on: extraction, rules engine, dashboard, receipts. Python scripts pull the data, a JSON rules engine flags violations by category, and an HTML dashboard gives leadership a live read with correction guidance for recruiters.
Approach: Built as a demo / MVP in a morning. In a regulated security environment, production builds are handed to engineering by design, and I know why.
Outcome: Projected to replace 10+ hours of weekly manual spot-checking. Gave leadership compliance visibility they didn't have.
Lesson learned: Sometimes the best solution isn't elegant. It's the one you can ship same-day and hand off without a developer.
AI Adoption Framework
The problem: Job descriptions were inconsistent across headers, tone, benefits language, and role detail. Recruiters often gave candidates a list of requirements, but not enough about the day-to-day work.
What I built: Using an internal LLM platform, I built recruiting personas for job descriptions, sourcing plans, screening questionnaires, and manager interview questions. Each one used conversational discovery instead of a blank prompt.
Approach: The job description persona helped recruiters draft in the right format, with clearer role context and company information. The sourcing persona built sourcing plans through discovery. The screening persona used the job description and intake notes to develop screening questionnaires. The manager interview persona used the job description, recruiter notes, and screening questions so managers could build interview questions without duplicating the recruiter screen.
Trained in smaller groups so the examples could match the roles each team worked on. Recruiting nuance matters. A customer service role, a technical role, and a leadership role do not need the same prompt.
Outcome: The output moved closer to the format and level of detail recruiters were supposed to use.
What made it work: The tool fit the workflow recruiters already had. It gave structure without asking them to become prompt engineers.