Here is the problem with a lead score. Your ideal customer might be a 40-person logistics company that just hired its first ops lead and mentions manual reconciliation on its careers page. No scoring model ships with that. What ships is company size, industry, job title, maybe funding, a reasonable guess at what matters, made in the abstract, before anyone knew what you sell.
So you get a 82 out of 100, and no way to ask why, and no way to change what the 82 was measuring.
A fixed field gives you the vendor's opinion of your business. A transform gives you yours.
The primitive
A transform node takes everything already known about a record, enrichment data, research, existing CRM fields, whatever the form captured, and runs one operation you describe in plain language. It runs on every record, at whatever volume you push through it, and it writes its answer to a field you name.
The reason it matters is that four things people usually treat as separate features turn out to be the same operation with a different instruction:
- A lead score, out of 100, from a model you cannot inspect
- An industry field, from a taxonomy that has one bucket called “Software”
- A notes field, filled in by whoever remembered
- Anything else: an export, a spreadsheet, and someone's Thursday
- Score, rate this record against the ICP as you actually define it
- Classify, sort it into the categories your team uses, not a generic list
- Summarise, two lines a rep can read before a call
- Extract, pull the one specific signal you care about out of unstructured text
Why the definition has to be yours
Every company's qualification logic contains something idiosyncratic and disqualifying that no vendor could have anticipated. A competitor's customer is not a prospect. A company in a market you cannot support yet is not a prospect regardless of how well it scores. A title that means seniority at one company size means something else at another.
These are not edge cases; they are most of what separates a useful queue from a noisy one. And they cannot be expressed as a weighting on a firmographic field. They have to be expressed as a sentence, because that is the only format that holds them.
What it is not
It is not a rule engine. If your logic is genuinely deterministic, company size over 200, in these three countries, not an existing customer, write it as a rule. Rules are faster, cheaper, and easier to debug, and a transform is the wrong tool for them. The transform earns its place where the judgement is not expressible as a comparison: reading a careers page, weighing a title against a company's size, deciding whether a paragraph of free text signals urgency.
It is also not a replacement for good input. A transform reasons over what it is given. Run one on a record with nothing but an email address and it will produce a confident answer built on almost nothing, which is worse than no answer, because it looks the same as a good one.
This is the practical order that matters: enrich first, research second, transform third. Every one of those steps makes the next one better, and inverting them is the most common way teams end up distrusting their own scoring.
What changes downstream
Once the operation is yours, everything after it inherits the improvement. Routing rules can branch on a category you defined rather than an industry code. A rep opens a record and reads two lines written for them rather than scrolling a raw enrichment dump. Sequences can reference the specific signal that made someone interesting instead of merging a company name into a template.
None of that is a separate feature. It is the same operation, pointed at a different question.
