Extract contact details

Structured contact fields from a signature block, with the standing rule that a blank field beats a guessed one.

When to use it

Parsing contact fields out of free-form text — a signature, a business card scan, a directory dump — where the output feeds a CRM or a database.

What it prevents

The inferred company. A model that sees an email domain will happily fill the company field from it, inventing structured data that looks exactly as trustworthy as the fields that were actually present. The explicit no-inference rule is what keeps a guess out of your records.

The prompt

Extract the contact details from the email signature block below.

### Output format
Return JSON and nothing else: {"name": "string", "title": "string or null", "company": "string or null", "email": "string or null", "phone": "string or null"}

### Requirements
- Use null for any field not present. Do not guess a company from the email domain.
- Normalise the phone number to E.164 only when the country is unambiguous; otherwise keep it verbatim.
- If two email addresses appear, take the one on the same line as the name.

### Example
{"name": "Dana Lee", "title": "Head of Ops", "company": "Acme", "email": "dana@acme.com", "phone": null}

### Signature
"""
Dana Lee | Head of Ops
Acme — dana@acme.com
"""

Why each part is there

Every section of that prompt exists because a specific failure happens without it. These are the checks it passes, and what each one is protecting you from:

• States a concrete task — why this matters
• Avoids vague language — why this matters
• Specifies an output format — why this matters
• Avoids dangling references — why this matters
• Includes an example — why this matters
• Separates data from instructions — why this matters
• Avoids over-aggressive phrasing — why this matters

How to adapt this one

Change the fields to match your schema and keep the null-for-absent rule verbatim — in an extraction that populates a database, a blank is honest and a guess is a landmine. The phone-normalisation rule shows the pattern for any normalise-only-when-safe field: transform when the input is unambiguous, keep it verbatim when it is not, and never invent the missing piece.

The mistake this prompt avoids

Rewarding the model for being helpful. Extraction is one of the few tasks where inference is a bug, not a feature — a plausible company or title guessed from context is indistinguishable from a real one downstream. Forbid it explicitly; the fields that were clearly present were never the hard part.

A variation

Extracting at volume where the same person appears in different formats? Add a normalisation pass — map job titles and company names to a controlled list, null for anything that does not fit — so “Head of Ops”, “Ops Lead”, and “Operations Manager” do not fragment into three records. Extract verbatim when a human reads it; normalise when a database has to match on it.

Check your version

Once you have adapted it, run it through the checker. The same nine checks that graded this page will grade yours, free and in your browser — paste it in, or build one from scratch by answering a few questions.