Another warehouse team leader
A client asks for a job description for a new warehouse team leader. Your consultant has written dozens of team leader descriptions across clients over the years, but they are scattered across client folders, each slightly different. So they start with a search, find one from a logistics client three years ago, and rework it. They email the client for details: who does the role report to, how many direct reports, what shift pattern, any licences needed.
Meanwhile, the client's existing team leaders have a job description written five years ago that says something quite different, and nobody has noticed.
Why the same work is repeated
- Previous job descriptions are stored by client, not by role type.
- There is no agreed set of building blocks for common responsibilities and skills.
- The information needed from the client is gathered by email, piece by piece.
- Job descriptions are not linked to the client's grading or pay structure.
- Old versions stay in use because nobody tracks which is current.
What that costs
Consultant time on drafting that could be spent on advice. Inconsistent descriptions within one client, which cause problems in pay discussions, recruitment and performance reviews. Descriptions that no longer match the job, which make difficult conversations harder. And for clients that ask for a full set of job descriptions, a project that becomes large and hard to price.
| Question | Without a library | With a library |
|---|---|---|
| Have we written this role before? | Search client folders | Search by role type |
| What does the client need to tell us? | Email back and forth | Guided questionnaire |
| Which pay band does it sit in? | Checked separately, if at all | Linked to the client's structure |
| Is this the current version? | Filename guesswork | Version history and approval |
How we build the job description library
- We gather your existing job descriptions, strip client details and organise them by role family and level, such as operations, finance, care or sales, from entry level to senior manager.
- Common responsibilities, skills and requirements become reusable blocks your senior consultants approve.
- When a client needs a new description, they receive a short questionnaire that asks about purpose, reporting line, direct reports, working pattern, key tasks and requirements.
- A draft is assembled from the library blocks and the answers, with a model such as Anthropic Claude used to smooth the wording into your house style. The consultant edits and approves it.
- Each description is linked to the client's grading or pay bands, if they have them, so inconsistencies with similar roles are visible.
- Clients approve the final version online. The library keeps the version history, and the description is filed to the client's documents.
- A client view lists every role and its current description, so outdated ones are easy to spot and review.
Grading decisions and pay bands belong to the client and your consultants. The library keeps descriptions consistent and current. It does not evaluate jobs.
After the library exists
Consultants start from an approved draft rather than a blank page or an old file. Clients answer one questionnaire instead of a chain of emails. Descriptions within a client become consistent and linked to their structure. And a request for a full set of job descriptions becomes a manageable, priceable project.
Over time the library also becomes a useful asset in its own right, reflecting the kinds of roles your clients actually employ.
Recognise this?
- Job descriptions start from an old one found in a client folder.
- Clients provide role details over several emails.
- Descriptions within one client are inconsistent.
- Some clients' descriptions are years out of date.
- Full job description projects are hard to price.