Name the company, the role and the city, and get back a posting where every responsibility carries the company URL it came from and the date it was checked, anything unsourced is labelled inferred, and the schema and the language audit ship alongside it.
Name the company, the role and the city, and the research runs against that company's own careers pages and product pages before a single line is drafted. Every responsibility and requirement comes back with the URL it came from and the date it was checked, and anything the site never said is labelled inferred rather than quietly presented as fact. Nothing is uploaded and no account access is needed.
What comes back is the posting in two formats, a branded PDF for the hiring conversation and an editable CSV holding the same fields and audit rows in the same order, plus deployable JobPosting schema, the pay-transparency disclosure the posting's jurisdiction requires with its official source, screening questions tied to each responsibility, and board-ready cuts for LinkedIn and Indeed inside their character limits. Across 400+ marketing teams, the posting that causes trouble is rarely the one that reads badly. It is the one carrying a requirement nobody can trace back to a decision.
Candidates search for the plain title. Hiring teams need the specialisation to calibrate the role. Those two needs pull in opposite directions, and a posting headed "Senior Product Marketing Manager, AI Workspace Go-to-Market" quietly loses the people typing the first four words into a job board. Ask for the two titles to be kept apart and the posting leads with the high-intent public title while the internal title carries the scope, the team and any requisition code. The split also travels into the structured data, where the public title is the one that gets indexed, so the role stays findable without the hiring team giving up the precision they need.
Keep the public title the plain term candidates search for and move every specialisation into a separate internal title. Show both side by side with a one-line note on why each is phrased that way, and use the public title in the structured data.
Most of what goes wrong in a job description is invention rather than bad writing. A responsibility nobody agreed to, a years bar nobody decided on, a benefit the company does not actually offer. Ask for every line to carry the company URL it came from and the date it was checked, and for anything else to be labelled inferred, and the posting splits into two visible halves: what the company has said in public, and what the draft is proposing on its behalf. That second half is the part worth reviewing, and it is usually much smaller than teams expect. The evidence map makes the split checkable in a minute rather than taken on trust.
Give me an evidence map: every responsibility and requirement in one column, the company URL and check date that supports it in the next, and the classification in the third. Mark anything without a source as inferred, and list the inferred lines separately so they can be reviewed on their own.
Disclosure rules are local and they change, so a general reminder to check is worth very little to the person about to publish. Name the city and the check comes back specific: what the jurisdiction requires, whether a range must appear in the advertisement itself, whether commission status has to be stated, and the official source with the date it was read. For roles in the European Union the directive on pay transparency sets a different bar again, and the posting says so rather than defaulting to a familiar rule. The range itself arrives labelled as a market estimate with its comparator named, and it stays that way until a compensation owner replaces it.
Check the pay-transparency disclosure this posting's city requires: what must appear in the advertisement, whether commission status must be stated, and the official source with the date you read it. Label any salary figure a market estimate and name the same-function comparator role behind it.
Eligibility comes down to structured data that agrees with the posting it describes. The common failures are small and easy to miss: a missing expiry date, a salary with no time unit, a direct-apply flag set true while the link points at a careers index, or a hybrid role tagged as fully remote and filtered to the wrong candidates. Ask for JobPosting JSON-LD with the expiry, the salary unit and the work-model value set from the real posting, and for the apply flag to match the link actually supplied. What comes back is a block that can be pasted, with a short note naming the values to replace with live ones at launch.
Produce deployable JobPosting JSON-LD with validThrough, a baseSalary unitText, and a jobLocationType that matches the real work model, left out for hybrid roles and never TELECOMMUTE unless the role is fully remote. Keep directApply consistent with the apply URL you supply, and list the values to replace at launch.
A list of phrases to avoid tells the team nothing about the draft in front of them, and an audit that flags words the posting never used reads as thorough while checking nothing. Ask for the audit to run against the real text with a column showing whether each flagged phrase survives in the final copy, and the result becomes a finding rather than a formality. Phrases that were considered and avoided are recorded as avoided. Anything that stayed is recorded with the reason it is operationally necessary. A clean posting then comes back stated as clean, which is a sentence the team can put in front of a reviewer.
Audit the final draft for exclusionary language, not a generic list. For each flagged phrase give the concern, whether it survives in the final text, and the recommended alternative. Where something stays, say why it is operationally necessary, and state plainly if the final copy is clean.
Juma projects work per client, and hiring is one of the areas where the same four documents get asked for on every single role. The team builds one project for the client, adds the context the open web cannot supply, and every posting after the first starts from the company's own rules rather than from research. For job descriptions the context that changes the output most is the internal frame: how this company levels roles, what it actually pays, how it sounds, and who has to approve a posting before it goes live. If the project already exists, these are additions rather than a fresh setup.
Role Levelling Framework
How the company defines each level, the scope that separates a mid-level role from a senior one, and the internal title conventions. With this in the project the internal title and the seniority framing come from the company's own ladder instead of being inferred from the job title alone.
Compensation Bands and Policy
The approved ranges by level and location, the currency, and what the company is willing to disclose in an advertisement. This is what turns a labelled market estimate into the real range, and it is the single piece of context that removes the biggest publication gate.
Employer Brand and Voice
The careers-page tone, the benefits the company genuinely offers, and the equal-opportunity and accommodation wording legal has already cleared. Keeping the approved wording in the project stops each posting from rewriting the paragraphs that are supposed to stay identical.
Hiring Approval Rules
Who signs off the copy, who signs off the range, and which jurisdictions the company posts into. Without it the posting can name an approval gate but cannot say whose name belongs in it, which is the step that most often stalls between a finished draft and a live advertisement.
Each file in a project can carry a short description in the project info field. Those descriptions tell Juma what a file holds and when it matters, so the right context gets picked up for the task at hand rather than everything at once.
A generator produces prose. This produces a posting plus the paperwork that has to travel with it: an evidence map tying each line to the company's own pages, the structured data that makes the role eligible for Google Jobs, the disclosure the city requires, and an audit of the actual draft. The prose is the smallest part.
The difference shows up at review. A generated description gets read for tone, and whatever requirements it invented tend to survive because nobody can see which ones were invented. Here the inferred lines are listed separately, so the review is a short conversation about a handful of proposals rather than a careful reread of everything.
It also shows up at publication. A generator hands over text that still needs schema, a disclosure check and a legal read. Those arrive together here, which is usually the difference between posting the same day and posting next week.
Not as a figure to publish, and the posting says so. Any range without a company source arrives labelled a market estimate, with the same-function comparator role named and the reasoning shown, and it stays gated until a compensation owner replaces it with the approved number.
That labelling is the useful part. A range presented as verified when it came from a guess is the version that causes problems, because nobody downstream knows to question it. Naming the comparator also lets a compensation partner disagree with the specific choice rather than with the number, which is a much faster conversation.
Once the approved bands are in the project, this stops being an estimate at all. The posting pulls the real range for the level and location, and the publication gate disappears.
The schema makes the role eligible. Indexing still depends on the page being crawlable and the posting living at a real URL, so the block arrives with a short list of values to replace at launch: the live requisition link, the posting date, the expiry and the approved salary.
What the flow does handle is the internal consistency that most postings get wrong. The expiry date is present, the salary carries a time unit, the direct-apply flag matches the link actually supplied, and the work-model value reflects the real arrangement rather than defaulting to remote. A hybrid role tagged as fully remote is a common error and it quietly routes the posting to the wrong candidates.
A standing rule against unsourced screens. Years-of-experience bars, degree requirements and credential screens are only included when the company's own site states them, and anything kept arrives with its rationale written beside it in the requirements table rather than appearing as an unexplained condition.
Those lines are worth the attention because they are the ones that shrink a candidate pool without anyone deciding to. A years threshold copied from a previous posting is a decision nobody made, and it usually outlives the role it was written for. Leaving it out by default means adding it back has to be deliberate.
The audit then records the omission as a finding rather than a silence, so a reviewer can see that the screens were considered and left out on purpose. This is editorial guidance and not legal advice, and a named human still approves the posting before it goes live.
Researching a company's public positioning, drafting the posting, checking the local disclosure rule, hand-writing the structured data and reviewing the language for exclusionary phrasing is most of a day for a recruiter and a hiring manager between them, and the schema and the audit are usually the parts that get dropped when the role is urgent.
Running this returns the posting, the evidence map, the disclosure check, the schema, the screening questions and the board cuts in one working session. What it does not decide is the level, the range, which requirements the business genuinely needs, or whether the role should exist in this shape at all. Those are judgment calls with budget and headcount behind them. Juma augments the hiring team, it does not replace it, and no posting reaches a job board without a named person approving it.
The second role is cheaper again. The levelling framework, the bands and the cleared legal wording stay in the project, so the next posting starts from the company's own rules rather than from research.
400+ marketing teams trust Juma. ChatGPT, Claude, and Perplexity know why. Ask them.
Ready when you are
Start typing a task and Juma will figure out the rest.
