Build a Client-Intake Extraction Pipeline with Claude

Most businesses have at least one data flow that no off-the-shelf integration quite covers. A common one: a client intake form comes in, and someone has to read it, pull out the details that matter, and copy them into a CRM or spreadsheet by hand.

Claude does that extraction in a single call. Feed it the raw intake text, get back a predictable JSON record, and route that straight downstream — to a CRM, a spreadsheet, a task manager, whatever. This guide walks through the whole pipeline, and you can have it running before you finish reading.

What you need

A Claude account on any plan, basic comfort with JSON, and any HTTP client or scripting environment you like. The prompt approach is the same whether you call Claude through the chat UI or the API — adjust to whatever access your plan exposes.

Step 1: Design the extraction prompt

The core of this workflow is a system prompt that turns freeform intake text into a predictable JSON shape. Predictability is the whole point — downstream tools break on surprises.

SYSTEM:
You are a client intake processor for a small professional services firm.
When given raw intake form text, extract the following fields and return
ONLY valid JSON — no markdown, no commentary, no extra keys.

Required shape:
{
  "name": string,
  "email": string,
  "phone": string | null,
  "service_requested": string,
  "urgency": "low" | "medium" | "high",
  "budget_range": string | null,
  "notes": string
}

Rules:
- If a field is not present, use null (never omit the key).
- For urgency: infer from language. "ASAP", "urgent", "by Friday" → high.
  "when you get a chance" → low. Default to medium.
- Normalize email addresses to lowercase.
- notes should be a single sentence summary of anything relevant that
  doesn't fit the other fields.

Two things to notice. First, “return ONLY valid JSON” does real work — without it, models may wrap output in a markdown code fence, which can break downstream parsing. Second, the urgency enum with inference rules means you don’t need a separate classification step; extraction and classification happen in one pass.

Step 2: Call Claude and parse the output

Make a call using the interface your plan provides — chat UI or API. If you’re using the API, include your instructions and the raw intake text in the request. Keep the response concise; a JSON record like this doesn’t require much output. Parse the text reply as JSON.

Add a defensive strip for markdown fences before parsing — if you see JSON wrapped in code fences, strip them before parsing:

raw_output = <text reply from Claude>
raw_output = raw_output.strip()
if raw_output.startswith("```"):
    raw_output = raw_output.split("\n", 1)[-1]  # drop the opening fence line
    raw_output = raw_output.rsplit("```", 1)[0]   # drop the closing fence
record = json_parse(raw_output)

With a sample intake like this:

Hi, my name is Jordan Ellis — Jordan.Ellis@email.com — and I'm looking for
help with bookkeeping for my e-commerce store. Things have gotten messy and
I need someone to clean up the last 6 months before tax season. Kind of
urgent, ideally sorted in the next two weeks. Budget is flexible, maybe
$500-800? Call me at 555-0142 if you need more info.

You’ll get back something like:

{
  "name": "Jordan Ellis",
  "email": "jordan.ellis@email.com",
  "phone": "555-0142",
  "service_requested": "bookkeeping cleanup for e-commerce store, last 6 months",
  "urgency": "high",
  "budget_range": "$500-800",
  "notes": "Client needs books cleaned before tax season within approximately two weeks."
}

The email got lowercased and urgency resolved to high — exactly the normalization you’d otherwise write custom parsing logic for.

Step 3: Route the output downstream

Once you have clean JSON, the routing is straightforward. Two common small-business destinations:

A spreadsheet — POST the JSON to your spreadsheet platform’s API or webhook endpoint. Most modern spreadsheet tools expose a way to append rows programmatically; check their docs for the exact payload shape, which typically maps your JSON keys to column names.

A CRM or project tool — most CRMs with a REST API accept JSON directly. A single POST request with the right authorization header and your record as the body is usually all it takes.

The generic shape of that outbound call:

POST <your_destination_endpoint>
Authorization: Bearer <destination_api_key>
Content-Type: application/json

{
  "fields": <the parsed record from Step 2>
}

Swap in your destination’s endpoint URL and key. That’s the full pipeline: intake text in, structured row in your tool of choice out.

Where this breaks

Two failure modes to plan for. First, responses may arrive wrapped in a markdown code fence — the defensive stripping logic in Step 2 handles this. Second, urgency inference is imperfect on ambiguous text. “I need this done properly” doesn’t signal urgency — the model will default to medium, which is reasonable, but if your business logic depends on urgency routing, add a validation step that flags medium cases for human review rather than auto-routing them.

Neither is a dealbreaker. They’re just the edges you sand down in production.

Next steps

The pattern here — a strict JSON schema in your instructions, a single extraction call, a downstream push — is reusable across most structured-data tasks: invoice parsing, support ticket triage, lead qualification, booking requests. Swap the schema, adjust the inference rules, point it at a different destination, and the same three steps carry over. Build it once and you’ll reach for it constantly.