You can spot an AI-written opener in about three words. "I hope this email finds you well." "I noticed that your company." "Congratulations on the exciting news."
The model is not bad at writing. It is bad at being specific unless you force it to be. Here are the rules I put in the prompts for the tables I built this month, and the one thing that went wrong anyway.
Give it facts, not a vibe
The model can only be specific about what you hand it. If the only inputs are a company name and a job title, the output will be generic, because there is nothing else to say.
In my tables the inputs were real columns: the funding amount, the company description, the job title being hired for, the angle from an earlier AI step. The prompt told it to use those and nothing else.
The rules I use
- Hard word limit. Under 25 words for an opener. Short lines give the model less room to fill.
- Ban the common openers. "I noticed", "Congrats", "I hope you are well", "I came across". Name them in the prompt.
- No exclamation marks. Nothing marks an AI email faster.
- Casual, plain words. No buzzwords and no "leverage" or "unlock".
- Only use the data provided. If a fact is not in the table, it cannot appear in the line.
- One idea per line. Not a compliment, a pitch and a question stacked together.
That list is short on purpose. Long prompts full of conditions tend to produce worse writing than a few clear rules.
What came out
Here is a real opener from my hiring-signal table, with the first name removed:
Saw HubStar is hiring for a Business Development Representative (BDR) this week. Focused lists, messaging, and sequences for workplace and facilities leaders could get meetings and pipeline moving before the new hire ramps.
And the funding table's lines opened in this shape, stating the round straight away: "Your $25M round is backing..." and "Saw your $1M round...".
They are not poetry. They state a real fact and connect it to one thing. That is the standard.
The failure I caught
The first version of the hiring opener printed the raw posting timestamp: "posted on 2026-10-13T12:49:18Z". That would have gone straight into an email if I had not read the outputs.
The fix was one line in the prompt: never print a raw date, describe it as "this week" or "a few days ago". After that the same rows came out as "posted a few days ago".
The lesson is not the specific fix. It is that you only find this kind of problem by reading real outputs.
The checks I run before sending
- Read at least ten outputs from the batch, not one
- Search the column for forbidden phrases
- Look for raw data leaking in: dates, IDs, JSON, "null"
- Check the name field is not blank or wrong
- Spot-check three facts against the source
- Read every line for high-value prospects
If anything fails, fix the prompt and re-run a small batch. Do not send and hope.
Keep the cost low
A small model is enough for short openers. In my tables the AI columns cost about a tenth of a credit per row, which makes it easy to re-run a batch while you fix the prompt. I go through the cost side in how to stop burning Clay credits.
Where AI lines fit
They work best when they are built on a real signal, like a job posting or a funding round. A personalised line about a fact the company cares about beats a clever line about nothing. I walk through two of those in job postings as a buying signal and funding announcements as an outbound signal.
The short version
Specific facts in, a few clear rules, a hard length limit, and a human reading the output before it ships. The prompt gets you most of the way. The reading catches the rest.