Claire Vo: Write Triage Rules That Leave Room for Uncertainty
How can I sort requests without treating an uncertain label as a decision?
Choose, practice, reflectA practical learning exercise
The Lesson
An assistant sorts a message into “business opportunity.” That label may feel useful until you notice that it rests on a job title and a friendly greeting. The message does not actually explain what the sender wants. A tidy category has concealed an unanswered question.
In her written account of triaging LinkedIn requests, Claire Vo describes providing connection criteria, examples and guidance about which commitments needed her input. Unclear invitations stayed pending. Her official about page identifies her work building ChatPRD, hosting How I AI and helping teams use AI.
The transferable idea is to define the sorting rules before asking an assistant to organize a queue. Here we apply that idea to fictional business messages. A category should explain what the supplied evidence supports. It should not quietly decide whether you will accept work, arrange a meeting or trust the sender.
Begin with the question your categories are meant to answer. “Important” is hard to test because it could mean urgent, useful or personally interesting. “A request about our stated service” is narrower. You can look for an actual request and compare it with a description of the service. If either is missing, an unresolved category is more informative than a confident guess.
Give each label a short rule and a clear example. Also include a case that almost fits. Suppose your fictional service edits wording and layout for event flyers. “Can you revise the time on my flyer?” names work within that description. “We should collaborate sometime” does not yet identify a task. Both might deserve attention, but they do not establish the same next step.
Keep classification separate from action. “Matches the described service” can lead to reviewing scope and availability; it does not mean “accepted.” “Unclear request” can lead to asking what work is wanted; it does not mean “ignore.” This separation makes it possible to inspect the assistant’s judgment before any commitment is made.
Current Anthropic guidance on explicit instructions supports specifying the output and constraints. For this task, request a label, the supporting words and any unanswered question. The three fields make a proposed classification easier to review than a label alone.
Reflection
- What question should your categories help you answer?
- Which label in your current list hides several different meanings?
- What information must be present before a request fits a category?
- Which ambiguous message should remain unresolved?
- What decision still belongs to you after sorting?
Practice
Original SelfGrowthVideos exercise: test a three-label request sorter. This is our exercise, not Vo’s LinkedIn workflow or an endorsed method. Use fictional messages on paper or in an assistant you already have; no account access or message sending is needed.
- State the service. The fictional editor revises event-flyer wording and layout. Printing, delivery and other services are not part of this example.
- Define three labels. Use “request about the stated service,” “different stated request” and “needs clarification.” Require an explicit task to use either of the first two labels.
- Write examples. A: “Can you revise the start time on my event flyer?” B: “Can you print and deliver fifty flyers?” C: “I organize events. Let’s work together.” Your expected labels are A: stated service; B: different request; C: needs clarification. C names a possible connection but no task.
- Request evidence. For each message, record the label, the words supporting it and one unresolved detail. If using AI, ask it to use only the supplied service description and messages, and to make no reply or commitment.
- Try a mixed case. Add: “Can you edit my flyer and get copies to the venue?” A single yes-or-no label would hide the second request. Record the editing part separately and flag printing or delivery for clarification; do not expand the service definition.
- Review before changing rules. Compare the result with your expected labels. If a guess was presented as evidence, revise the rule that allowed it and try a fresh message. Keep the old rule so that you can explain what changed.
Review
At your next trial, have another person explain why a message received its label. Can they find the supporting text? Do they understand what remains undecided? If not, improve the rule or the example. A useful prototype preserves uncertainty while making the next human decision clearer; it does not establish a production-ready classifier or customer demand.