How to score leads by job title - with a prompt you can run today

Job title is one of the most predictive fields in your CRM. It may also be the most underused - because “VP of Sales Operations, EMEA” and “Sr. Mgr. Growth & Analytics” share almost no characters, so most scoring either ignores title or reduces it to a crude “is this a VP” flag.

There is real signal in that field. This guide hands you a prompt that pulls it out - run it on your own data in ChatGPT or Claude - then shows you how to read the result, how to take it further, and what doing this properly actually takes.

TL;DR

• Job title carries conversion signal, but only after you normalize seniority, tokenize the words, and rank by lift. The prompt below does all three on your data.
• Read the output by lift and count: a high lift on 4 records is a coincidence; a modest lift on 800 is an edge.
• A prompt is a one-shot read on a sample. Doing it for every field, retrained as your data shifts and tied to a calibrated score, is the job - and the part ax1om automates.

Run it yourself: the prompt

You need a sample export from your CRM, two columns: the job title (exactly as it sits, messy is fine) and a conversion flag (1 if that contact reached your win outcome, 0 if not). A few hundred to a few thousand rows is plenty.

One caveat on the sample: only include contacts old enough to have had a fair shot at converting. A lead that arrived last week hasn’t had time to close - mark it a 0 and you understate every pattern, because you’re counting “too soon to tell” as “didn’t convert.” If your sales cycle runs 90 days, pull contacts created more than 90 days ago. That way a 0 actually means it didn’t convert, and the lifts you read are real.

Set the variables at the top, attach the file (or paste the rows), and run it.

# ── SET THESE FIRST ──────────────────────────────────────────────
# Attach your CSV in this chat, or paste rows under DATA at the bottom.
SOURCE         = attach CSV in this chat   # most tools read an attached file
TITLE_COLUMN   = title                     # column holding the job title
OUTCOME_COLUMN = converted                 # 1 = won/converted, 0 = not
WIN_MEANS      = closed-won within 90 days  # what a 1 means, in your words
TOP_N          = 15                        # how many features to return
MIN_COUNT      = 10                        # ignore tokens rarer than this
# ─────────────────────────────────────────────────────────────────

You are a RevOps data scientist. Using ONLY the data I provide (the attached file,
or the rows under DATA), analyze how {TITLE_COLUMN} predicts {OUTCOME_COLUMN}, where
{OUTCOME_COLUMN} = 1 means a conversion ({WIN_MEANS}) and 0 means not.

Show your work at each step:

1. BASE RATE. Compute and state the overall conversion rate across all rows.

2. TIERS. Normalize each {TITLE_COLUMN} to a seniority tier - C-suite, VP, Director,
   Manager, IC, or Unknown. List the matching rules you used so I can audit them.

3. TOKENS. Lowercase each title, strip punctuation, drop stop words, and extract both
   single words (unigrams) and adjacent two-word phrases (bigrams).

4. SCORE every tier and token appearing at least {MIN_COUNT} times:
   - count     = rows whose title contains it
   - conv_rate = conversion rate among those rows
   - lift      = conv_rate / base rate
   - weighted  = lift * ln(count)   # so a rare token that got lucky does not win

5. RETURN the top {TOP_N} features by `weighted`, as a table:
   feature | type (tier/unigram/bigram) | count | conv_rate | lift | weighted

6. READ. In plain English: which titles to prioritize, which to deprioritize, and any
   feature you would NOT trust yet (low count, likely noise). Flag anything that looks
   like a data-quality artifact rather than a real signal.

Use only my data. Invent nothing. Surface any step you cannot complete with the data I
gave, and relay the caveat plus a suggested workaround instead of guessing.

DATA (only if you are not attaching a file):
<paste your title,converted rows here>

How to read what it gives you

The prompt returns a ranked table. Reading it well is the difference between a real signal and a coincidence you act on.

• Lift is the headline. Lift above 1 means that title pattern converts better than your average; below 1, worse. Lift of 2.0 means contacts with that pattern convert at twice your base rate. But lift alone lies on small numbers.
• Count is the trust check. A token with lift 5.0 and a count of 4 is noise - four contacts, a couple happened to convert. A token with lift 1.6 and a count of 800 is a genuine edge. That is why the table ranks by weighted (lift × ln count), not raw lift. Read down the weighted column, then sanity-check each row’s count before you believe it.
• Tiers are blunt, tokens are sharp. “VP” tells you seniority. The tokens - “revenue,” “operations,” “growth,” “founder” - are where the differentiation hides. “VP” plus “revenue” is a very different contact than “VP” plus “engineering,” and your data will usually say so.
• What to do with it. The top features are a defensible, data-backed view of which titles to prioritize - and often a couple of titles you have been under-working. Use them to pressure-test your ICP and brief your reps. Do not hard-code them as permanent rules; they decay (see below).
• The traps. Lift is relative to your base rate, so a low-baseline business shows dramatic lifts - compare within your own data, not against someone else’s numbers. And the signal shifts: a token that was strong last year cools as your market moves, which is why this is a recurring chore, not a one-time setup.

Going further: follow-up prompts

Once the first table looks right, these keep the same chat going.

Turn it into a scoring rule. “From the top features above, write a single scoring rule I can apply to a new contact’s title - points per matched tier and token - and show it scoring these five example titles: [paste 5].”

Extend it to another field. “Run the same analysis on {OTHER_COLUMN} (for example, Industry) - unigrams and bigrams only, skip the seniority step - and return the same table.”

Guard against overfitting. “Split my data 70/30 at random. Recompute the top features on the 70, then show which ones hold up on the 30 percent holdout and which collapse. Drop anything that does not survive.”

Find what I am missing. “List the highest-lift titles with a count between 5 and {MIN_COUNT} - the ones too rare to rank but promising enough that I might be under-prioritizing them.”

What the prompt can’t do

You just ran four or five prompts to handle one field. Notice what that bought you, and what it did not.

It is a one-shot read on the rows you pasted. It will not score new contacts as they arrive, will not retrain as your pipeline shifts, will not tie to a calibrated 0-100, and will not write anything back to your CRM. Run it again next quarter and the LLM will normalize titles a little differently - it is not deterministic, so two runs on the same data rarely match exactly. And if you try to escape the one-shot limit by looping the model over every record to score them as they land, the token bill climbs fast - LLMs are priced per token, and per-record scoring at any real volume is the wrong tool for the job. Now multiply that by every text field you have, every quarter, reconciled by hand. That is the part-time analyst job, rebuilt - now with prompts to babysit.

Where vendor scoring tech falls short

Buy a predictive scoring tool, the thinking goes, and skip all of that. Some tools do. But most fail in one of two directions - and they are opposite failures.

The black box. One class of “predictive” platform hands you a 0-100 and nothing else - no factors, no reasons, no way to see what the model learned. When a rep asks why an account is a 73, the only honest answer is “the model decided.” A score you cannot interrogate is a score you cannot defend, so it gets quietly ignored - which is the exact cost the rest of this guide is about.

The spreadsheet in disguise. The other class hands you the same manual work behind a nicer interface: you still author each feature by hand - a library of IF/THEN computations, a “Persona” rule that fires when role contains “HR” and seniority is director-or-above, a behavioral rollup per time window, a fit grade you tune by dragging thresholds. Mature deployments carry hundreds of these hand-built computations and a decision tree an analyst grows and prunes. The labor did not disappear. It moved into their workbench - and now it needs an analyst who knows their workbench, on a seat you pay for.

One hides the reasoning; the other makes you build it by hand. The next section is about being neither - the automation of the black box, with the transparency of the spreadsheet.

How ax1om does it

Here is the same pipeline, the way ax1om runs it: automatically, on every text field, every time it trains - deterministically, on your full closed-won history, not a pasted sample. The techniques are levels, unigrams, and bigrams, and every resulting feature stays readable.

1. Levels. Each title is checked against a seniority taxonomy with seven tiers: c_suite, vp, director, manager, senior_ic, ic, and intern. The match is rule-based and deliberately transparent. “VP of Sales Operations” maps to vp. “Senior Director” maps to director. “Sr. Mgr.” maps to manager. Each level becomes a one-hot feature: title_level_vp, title_level_director, and so on. In the SHAP output, a rep sees “Title level · VP” contributing a specific amount, which is immediately meaningful.

2. Unigrams. The title is lowercased, stripped of punctuation, and split on whitespace. Stop words (of, and, the, for, in, at, to) are removed. Each remaining single word is a candidate feature. “VP of Sales Operations, EMEA” produces unigrams: vp, sales, operations, emea.

3. Bigrams. Every adjacent pair of tokens is captured as a two-word feature. The same title produces bigrams: vp_sales, sales_operations, operations_emea. Bigrams preserve context that unigrams lose - “sales operations” and “sales enablement” share a unigram but carry very different meaning. The bigram captures the difference.

Not every token becomes a feature. Each candidate is scored on two dimensions: lift (how much more likely conversion is when the token appears) and log-frequency (how often the token appears in the dataset). Tokens are ranked by lift × log(frequency), and the top-scoring ones become features up to a configurable cap - default 100 tokens per field, minimum frequency 10. A token that appears twice in ten thousand records does not make the cut, even if both of those records converted. A token that appears often with a strong lift does.

The result: every title-derived feature is a specific, nameable thing. “Title level · vp” is a seniority match. “Title contains · revenue” is a unigram. “Title contains · sales_operations” is a bigram. When SHAP surfaces “Title level · vp” as a top driver of a score, the rep and the RevOps leader both know exactly what that means, why the model picked it up, and how to validate it against their own knowledge of the pipeline.

The same approach generalizes to other high-cardinality text fields like Industry, configured per field type - titles get the seniority level extraction on top of the token pipeline, other text fields get unigrams and bigrams only. Every boolean feature in the final model traces back to a specific, auditable text pattern. No embeddings, no opaque vectors, no “the model just knows.”

That is the whole trick. The rigor of the hand-built version, with none of the authoring - and none of the babysitting. You connect the field; the pipeline does what your analyst would have done in a spreadsheet, the same way every time, and hands back features a rep can still read.

What “explainable” actually means

Readable features are the point, because they are what make the score explainable - and a score reps can read is the only kind that gets used. Explainability in ML is two things at different levels.

Global explainability tells you what the model has learned overall - which features matter most across all predictions. It is the audit view, typically expressed as feature importance, a ranked list of which fields contributed most. It is the same lift idea the prompt computes, run rigorously across your whole dataset.

Local explainability tells you why a specific prediction came out the way it did. Why did this account score 73? Which signals pushed it up, which pulled it down? The standard technique for tree-based models is SHAP - SHapley Additive exPlanations (Lundberg & Lee, 2017), rooted in cooperative game theory, which assigns each feature a precise contribution to each prediction.

Reading a per-account score

A lead lands in your pipeline at a conversion likelihood of 73. Behind that number, a SHAP explanation ranks the signals that drove it - how much each one moved the prediction, and in which direction:

Each row is a signal the model weighed, ranked by how strongly it moved the prediction and tagged by direction - the positives pushed the score up, the negatives pulled it back. (Read the numbers as relative influence, not points that total 73 - the contributions live in the model’s internal space, and the 0-100 score is calibrated from the prediction.) The title feature - “Title level · vp” - is the same signal you just built by hand, except it is one of dozens, learned and weighted from your own outcomes.

That ranking is what ax1om writes next to the score, condensed to a single line your rep reads without leaving the CRM:

↑ VP-level title (1.9x) · ↑ 3 meetings last 14d · ↓ free email domain

Direction arrows, the field that fired, and - for job title and other text signals - the empirical lift, so “why is this a 73?” is answered in the same row the rep is already looking at.

What this tells a rep: a referral brought in a VP at a right-size software company, and there have been three meetings in the last two weeks - worth prioritizing, and here is exactly why. The negatives flag the free email domain and that nobody at the account has filled a form in a quarter. They can work a 73 with this context. They cannot work a bare 73 without it.

Explainability is continuous enablement

There is a quieter cost to scores nobody can read. A pattern shows up on nearly every scoring rollout: the team spends weeks building the model, then spends months defending it. Every skeptical rep, every “I think this score is off,” becomes a conversation. The ops team that built the score turns into a permanent help desk for it.

What makes those conversations expensive is not that the team disagrees. It is that they cannot contextualize the disagreement. A rep looks at a number, something feels wrong, and the score gives them nothing to reason with. The doubt is real but unspecified, so it routes back to ops as a ticket instead of resolving at the rep’s desk.

When the score arrives with the factors that drove it, the rep interrogates it in the moment - confirms it or dismisses it, with reasons, without opening a ticket. Explainability is not a trust feature you bolt on for the skeptics. It is continuous enablement: the score teaches the team what it knows every time it appears, instead of the ops team re-teaching it by hand. A score that explains itself scales. A score that does not becomes a second job.

What this means for your next scoring decision

You can get real signal out of job title with an afternoon and a prompt. That is worth doing - it will sharpen your ICP whether or not you ever buy anything. What a prompt cannot do is run that pipeline on every field, retrain as your data moves, calibrate it into a score, attach the reasoning to each record, and write it back where your reps work - deterministically, without an analyst babysitting it.

That is the gap ax1om closes. Every score is trained on your own closed-won outcomes, on features engineered the way this guide describes - levels, unigrams, and bigrams - so the model stays readable instead of a black box. And it does the part a prompt can’t: it ranks the reasons behind each per-record score and writes them back to a field in your CRM, right next to the number, so your reps read the score instead of just receiving it. If that is the shape of what you need, we are opening the beta waitlist now - join here.

If it is not, run the prompt every quarter. The method holds up - it is just a lot of afternoons.