How to Write a System Prompt for Claude

A support team at a mid-size SaaS company ran the same system prompt for four months before noticing it was quietly costing them tickets. Not because the prompt was badly written — it read fine on the page. The problem showed up only after 15 or 20 messages into a conversation, when Claude started drifting back to a generic, overly formal tone. That's the trap almost everyone falls into when they learn how to write a system prompt for Claude: they optimize for how it reads once, not how it holds up over a full session.

The Problem the Support Team Faced

The company, a project management tool for construction firms, wanted Claude to handle tier-1 support chat: password resets, billing questions, basic troubleshooting. Their support lead, Priya, wrote a system prompt describing the assistant's personality ("friendly, helpful, professional") and listed the topics it could cover. It worked great in testing. Five-message test conversations looked clean.

Then real users started chatting for 20, 30, even 40 turns — asking follow-up questions, going off on tangents, coming back to the original issue after a detour. And Claude's responses got longer, vaguer, and more hedgy the deeper the conversation went. Support tickets tagged "needs human escalation" went up 18% in the first month, mostly on longer conversations.

The Wrong Approach

Here's roughly what the original prompt looked like:

You are a helpful and friendly customer support assistant for BuildTrack. 
Be professional and helpful. Answer questions about billing, account 
settings, and basic troubleshooting. Keep the user happy and try to 
resolve their issue.

What this does: it tells Claude a vibe and a topic area, but gives it no structure for what to do when a conversation gets messy — which is exactly when a system prompt matters most.

This kind of prompt fails for a specific reason: it describes traits ("friendly," "professional") instead of behaviors ("if the user hasn't stated their account email, ask for it before troubleshooting billing"). Traits are vague enough that Claude has to infer what they mean turn by turn, and that inference drifts. Behaviors are concrete enough to hold steady.

⚠️ Common mistake: writing a system prompt as a personality description instead of an operating manual. "Be helpful" tells the model nothing it can act on directly. "If the user reports a bug, ask for their browser and OS before suggesting a fix" does.

The Correct Prompt

Here's what Priya's team rebuilt it into, trimmed down for readability:

You are BuildTrack's tier-1 support assistant. Your job is to resolve 
account, billing, and basic troubleshooting issues in as few turns as 
possible, and to escalate clearly when you can't.

Behavior rules:
1. If the user reports a bug, ask for their OS and browser version 
   before suggesting any fix.
2. Never guess at account-specific details (plan tier, billing date, 
   seat count). If you don't have this from the conversation, ask.
3. If a request involves refunds, cancellations, or anything touching 
   money leaving BuildTrack's account, do not resolve it yourself. 
   Summarize the request and say a human will follow up within 1 
   business day.
4. Keep responses under 120 words unless the user asks for more detail.
5. If the user's message is unrelated to BuildTrack (general chit-chat, 
   unrelated tech questions), redirect politely in one sentence.

Tone: direct and warm, not corporate. Skip phrases like "I understand 
your frustration" — just solve the problem.

What this does: it replaces personality adjectives with numbered behaviors tied to specific triggers, so Claude has a rule to apply rather than a tone to guess at, even 40 messages into a conversation.

⚡ Pro tip: Order your rules by how often they'll actually come up. Claude weighs earlier instructions slightly more heavily in long conversations, so put your most common edge case first, not your rarest one.

Results and What Changed

After switching prompts, BuildTrack's escalation rate on long conversations dropped from 18% back down to roughly 7% over the next month. Average response length also dropped by about 40 words, which sounds small but cut reading time enough that resolution speed improved too. Priya's team didn't touch the model, the channel, or the training data — they changed how to write a system prompt for Claude by shifting from trait-based to rule-based instructions.

One thing that surprised them: response consistency held even in conversations that wandered off-topic and came back. The bug-report rule (ask for OS/browser first) fired correctly even when that question came up on turn 25 instead of turn 2. Honestly, that's the part that convinced the wider team — rule-based prompts don't decay the way vibe-based ones do.

How to Apply This to Your Situation

If you're writing a system prompt for anything more complex than a single Q&A turn, walk through these steps:

1. List the actual decision points, not the vibe. What does the assistant need to do differently based on what the user says? Write those as if/then rules.
2. Cut every adjective that isn't actionable. "Professional" isn't actionable. "Don't use exclamation points" is.
3. Put escalation and refusal rules early, since these matter most when things go wrong, and you don't want them buried under formatting instructions.
4. Test with long conversations, not five-turn demos. A system prompt that works for a quick sanity check might still drift by message 30.

⚡ Pro tip: if you're not sure whether a rule is specific enough, try to imagine Claude asking you "in what situation, exactly?" If you can't answer in one sentence, rewrite it.

This approach scales beyond support bots too — the same logic works whether you're prompting Claude for content review, internal tooling, or a coding assistant. The actual claude-prompts skill here is behavior over personality, every time.

There's a second layer people miss: order of operations matters almost as much as the rules themselves. If your refusal or escalation rules sit at the bottom of a long list, under ten formatting instructions, Claude has to hold more context before it gets there. In practice that means edge cases get handled less reliably the further down the list they sit. Priya's team found this out by accident — they moved the refund-escalation rule from position 8 to position 3, and misrouted refund requests dropped by more than half without any other change to the wording.

I'm not 100% sure why positioning matters as much as it does — it might just be a side effect of how instructions closer to the start of a prompt get referenced more consistently across a long conversation. But the practical fix is simple regardless of the cause: front-load anything with legal, financial, or safety weight, and push tone and formatting preferences toward the end.

It's also worth building in a fallback rule for situations you didn't anticipate. Something like "if a request doesn't fit any rule above, say so plainly and ask what the user needs instead of guessing" gives Claude a default behavior instead of letting it improvise a tone. Teams that skip this step tend to see the same drift problem reappear a few weeks later, just in a different corner of the conversation.

The same behavior-over-personality shift shows up in other roles too. A solo IP attorney using Claude to triage intake emails ran into a near-identical issue: her original prompt said "be thorough and cautious," and Claude kept adding disclaimers to routine scheduling emails. Rewriting it to "only add a legal disclaimer if the email mentions a deadline, dispute, or filing" cut unnecessary disclaimers by most of the batch overnight. A marketing ops manager at a DTC skincare brand had the opposite problem — her prompt said "be concise," and Claude started cutting details users actually needed, like return policy specifics. Swapping "be concise" for "keep responses under 100 words unless the user asks about returns, shipping, or ingredients — those get full detail" fixed it without any loss of length control elsewhere.

What all three examples share is the same underlying fix: vague adjectives get interpreted differently turn to turn, but concrete triggers don't.

Next Steps

Start by pulling three real conversations where Claude's tone or accuracy drifted, and check whether the failure traces back to a vague trait instead of a missing rule. Rewrite just those sections first rather than rebuilding the whole prompt from scratch — most system prompts only need two or three sharper rules to fix the majority of drift.

Once you've got a version that holds up, save it somewhere you'll actually find it again. A tool like PromptABCD is built for exactly this — storing and versioning system prompts so you're not digging through old Slack messages or Google Docs six months from now trying to remember which rule fixed the escalation problem.