Claude Skill: Triage Leads Without Sending a Reply
One bad automated reply can cost a small team a real client. If inbound leads land in your inbox and someone still has to read every message, check what is missing, update the CRM, and write the next reply, this is for you. I’ll show you how to record the safe part of that workflow as a Claude skill: review the lead, choose one of three outcomes, and prepare a draft. Most demos skip the risky part. They automate sending. By the end, you’ll have a lead-triage SOP with a human approval point. I’m Lazar, and I build these systems daily for clients. Let’s start with what not to record.
The dangerous version of this automation looks impressive for about five minutes. A lead arrives, Claude reads it, changes a CRM field, and sends a reply automatically. Then it misreads a vague request, promises something your team does not offer, or sends a follow-up to someone who was clearly not a fit. That is not a productivity win. It is a trust problem.
The first Claude skill should not be your biggest workflow. It should be a repeatable SOP with a clear point where a human takes responsibility. Lead triage is a strong example because the repetitive work is real, but the final message can affect revenue and reputation.
Before recording anything, make the decision rules visible. On screen, I have a simple lead record with six fields: contact name, company, website, source, what they asked for, and budget or timeline if they provided it. If the lead came through a form, I also include the form answers. Claude cannot reliably qualify information that never made it into the record.
Next, define only three allowed outcomes. Qualified means the request fits your offer and has enough context for a useful next conversation. Needs-info means the lead might fit, but key context is missing: perhaps their company size, current process, timeline, or the system they need connected. Not-a-fit means their request is outside your offer, clearly spam, or not something your team can responsibly deliver.
Notice what is missing from this SOP: there is no fourth status called maybe. If your team cannot explain the decision in one sentence, the rule is not ready to record. Write a short checklist under each status before you start. For qualified, confirm the problem is real, the request matches your service, and there is a viable next step. For needs-info, list the exact missing details. For not-a-fit, define what qualifies as outside scope.
Now record the skill. I start from an inbound lead and let Claude follow the same safe sequence every time. First, inspect the lead details without inventing facts. Second, list any missing information that blocks a decision. Third, assign exactly one of the three statuses. Fourth, write a short internal rationale that an operator can audit. Finally, prepare a tailored follow-up draft.
The output format matters more than fancy prompting. I want the skill to produce a clean result an operator can scan in seconds: status, evidence, missing information, recommended next step, and draft reply. The skill is doing decision support and draft preparation. It is not sending email, overwriting a CRM record, or claiming the lead has been contacted.
This is the guardrail most feature demos leave out. Stop the recorded workflow before any external action. The operator reviews the status, checks whether Claude used the actual lead details, edits the draft if needed, then manually sends it and updates the CRM. If your CRM supports an approval queue, create a pending-review state instead of allowing the skill to write directly to the live record.
Let’s run an incomplete lead through it. The lead says, “We need help connecting our inbox to our CRM. Can you send pricing?” We have a name and email, but no company website, no team size, no current CRM, and no timeline.
The skill returns needs-info. Its rationale is straightforward: inbox-to-CRM integration may be a fit, but there is not enough detail to scope the workflow or recommend the right next step. It identifies the missing context: which CRM they use, approximate email volume, what should happen after an email arrives, and their target timeline.
The draft asks those questions without pretending we already have a solution. On screen, the operator checks three things before approving it: did Claude choose the correct status, are the questions specific to this lead, and does the message make a promise we cannot keep? In this example, the operator might soften one sentence, approve the draft, and then send it manually.
That is a working boundary: Claude handles the repetitive inspection, classification, and first-draft work. Your team retains control over client communication and permanent data changes. Do not claim a time-saving number until you measure baseline and post-skill runs on your exact workflow. Track the number of leads reviewed, how often the suggested status is changed, and how often the draft needs meaningful edits. Those are the numbers that tell you whether the skill is ready for wider use.
Want more like this?
I publish practical AI automation, GenAI engineering, and faceless content workflows on YouTube every week.
Subscribe to bizflowai.io on YouTube — never miss a new tutorial.
Planning an AI automation project or need a second opinion on your architecture?
Connect with me on LinkedIn — Lazar Milicevic, GenAI Engineer & bizflowai.io Founder.
Visit bizflowai.io for our services, case studies, and AI consulting.