Check Responses

Check Responses - Response Collection

A skill that automatically checks outbound sales responses and records them in the database.

Before starting: Read ${CLAUDE_PLUGIN_ROOT}/references/workspace-conventions.md and follow the cross-cutting conventions there (data storage, MCP error handling, document writes, output discipline).

Steps

1. Setup

• Project ID: $0 (required)

In parallel, call:

• get_document with projectId: "$0" and slug: "sales_strategy"
• get_master_document with slug: "ref_scheduling_services" (canonical service-name → notification-domain mapping)

From the "Response Definition" section of SALES_STRATEGY.md, understand:

• What counts as a "response"
• Scheduling service(s) in use (service names — there may be multiple, e.g. one for global team, one for a regional team)
• Other response signals

Resolve scheduling notification domains: for each scheduling service named in SALES_STRATEGY.md, look up its domain(s) in the ref_scheduling_services reference. If SALES_STRATEGY also has an explicit sender address (legacy format like "Timerex — notifications@timerex.net"), extract just the domain. If the service is not in the reference and SALES_STRATEGY has no sender address, skip the scheduler search for that service and report it in step 7.

2. Retrieve Recent Outreach Information

Retrieve metadata for outreach sent within the last 4 business days:

Call get_recent_outreach with projectId: "$0".

If the tool returns a "Project not found" error, instruct the user to run /leadace first and abort.

The output opens with the sending mailbox's reply-collection status. While it is collecting, replies and bounces to that mailbox are recorded server-side hourly and already counted on the logs (responseCount, latestResponseAt) — the primary reply source, whichever account Gmail MCP is signed into. Report the line as given; only a non-collecting status is a visibility gap. Never re-record a response a log already counts.

Each log carries recipient identifiers — prospectName, contactName (nullable), prospectEmail (nullable), organizationDomain — use these directly for the domain-search step below and for naming prospects in the report; do not infer from message bodies.

Each log also includes inquiry-landing aggregates: inquirySessionCount, inquiryOutcome (opened / inquired / lead / signup_clicked / unsubscribed / null — the most-significant outcome ever recorded for this outreach, so a recipient who converts and later re-visits the link is still reported as the converted outcome), inquiryMeetingSource (button / chat / null — only set when inquiryOutcome === 'lead'), inquiryLastVisitAt. Inquiry-derived lead, signup_clicked, and unsubscribed outcomes are recorded server-side at the moment the recipient acts on the landing page — the skill only surfaces them in the report, it does not re-record them. lead is the human-sales conversion (recipient asked to talk); signup_clicked is the self-serve conversion (recipient opened the project's signup URL — visible only when the project's CTA mode is signup, no human follow-up needed).

3. Check Incoming Emails

Use Gmail MCP for what the server poll does not cover — scheduling notifications, replies landing in the Gmail MCP account instead of the sending mailbox, and everything while the status is not collecting:

3a. Search for Direct Replies

For each outreach-targeted prospect, search by the domain of the email address sent to (to handle replies from different people in the same organization):

1. Search mcp__claude_ai_Gmail__search_threads for from:@<domain> newer_than:4d
2. If found, confirm content with mcp__claude_ai_Gmail__get_thread
3. Determine whether the content is a response to the outreach

3b. Search for Scheduling Notifications

For each scheduling service domain resolved in step 1, search Gmail. Run searches for all configured services in parallel (e.g. one for Calendly, one for SavvyCal if both are in use):

1. Search mcp__claude_ai_Gmail__search_threads for from:<domain> newer_than:4d (e.g. from:calendly.com newer_than:4d). Substring match catches subdomains (@email.calendly.com etc.)
2. If found, read the content and match the name, email address, and organization name in the notification body against the outreach list
3. Domain match alone is insufficient — the body must reference an outreach prospect (the same domain may carry unrelated mail like service marketing emails)

3c. Search for Bounced Emails

Detect sending failures (unknown recipient, non-existent domain, etc.):

1. Search mcp__claude_ai_Gmail__search_threads for from:mailer-daemon OR from:postmaster newer_than:4d
2. If found, confirm content with mcp__claude_ai_Gmail__get_thread
3. Match the bounced email address against the outreach list to identify the corresponding prospect

3d. Matching

Link received emails to outreach prospects. Match in the following priority order:

1. Exact match on sent address: Direct reply from the recipient
2. Domain match: Reply from a different person in the same organization (e.g., sent to contact@example.com -> received from alex@example.com)
3. Organization name match: The prospect's name appears in the email body or sender name (handles replies from group companies or legal secretariats)
4. Scheduling notification: The notification email body contains the prospect's name or email address

If match confidence is low, note "Needs confirmation" in the report and defer to the user's judgment.

4. Check SNS Responses

Prerequisite check: If the recent-outreach result from step 2 has no SNS channel outreach (sns_twitter / sns_linkedin), skip this entire step.

Check for DM replies from prospects contacted via SNS using claude-in-chrome. Supported platforms: X (Twitter) and LinkedIn.

For X (Twitter):

1. Open the X DM screen (https://x.com/messages)
2. Check for replies from outreach targets
3. If there are replies, retrieve the content

For LinkedIn:

1. Open the LinkedIn messaging screen (https://www.linkedin.com/messaging/)
2. Check for replies from outreach targets
3. If there are replies, retrieve the content

If the browser extension is not connected: Skip SNS checking, but count the number of prospects contacted via SNS that remain unconfirmed. In the results report (step 7), always report this as "Unconfirmed SNS DMs: N".

4b. Check Platform Responses

Prerequisite check: If the recent-outreach result from step 2 has no platform channel outreach, skip this entire step.

For each strategy with platform outreach, fetch the project's playbook_<discoveryStrategy> document and follow its Response check section: the platform's messages page (via claude-in-chrome, logged-in profile) and any notification-email sender patterns for step 3's Gmail pass. Match replies to outreach targets the same way as SNS. A playbook the tool reports as not usable yet (awaiting approval) counts as missing — its replies stay unconfirmed.

If the browser extension is not connected (and no notification email surfaced a reply): report "Unconfirmed platform replies: N" in step 7.

5. Update Database

For each response found, call record_response with:

• outreachLogId: the matching outreach log ID from step 2
• channel: the channel the response came through
• content: the response content
• sentiment: positive / neutral / negative
• responseType: reply / auto_reply / bounce / meeting_request / rejection
• markDoNotContact: set true for bounces or explicit opt-out requests
• receivedAt: ISO 8601 timestamp if known
• rejectionFeedback: only when responseType is rejection -- best-effort structured reason inferred from the body. See "Rejection feedback inference" below.

The server automatically determines the prospect status update based on responseType and sentiment:

• Positive reply / meeting_request -> responded
• Rejection -> rejected
• Bounce -> inactive (also auto-marks do-not-contact)
• Auto-reply -> no status change (keeps contacted)

Do-not-contact determination: If the reply content contains opt-out intent such as "no further contact needed", "unsubscribe", "please don't contact me", set markDoNotContact: true. This applies across all projects.

If they simply declined this project's proposal (e.g., "we'll pass this time"), the server sets rejected via the responseType -- do not set markDoNotContact.

Edge case override: If the automatic status is incorrect (e.g., a negative-sentiment reply that's actually a "not now, try again later"), use update_prospect_status to set the correct status.

Rejection feedback inference

When responseType is rejection, also pass rejectionFeedback to capture the structured reason. The server uses this for /check-feedback aggregation (especially feature_gap notes which are PMF signal) and auto-flips do_not_contact for unsubscribe / GDPR / CCPA / "never" recontact intents.

Schema URI: https://leadace.ai/schema/rejection-feedback-v1.json

Pick primary_reason from the body — choose the single best fit:

Optional fields to fill when the body supports them:

• secondary_reasons: up to 5 additional values from the same enum, only if multiple are clearly stated
• free_text: short note (≤ 500 chars). Use the original-language body excerpt (≤ 200 chars). For primary_reason: 'other', always include this so the reason isn't lost
• preferred_recontact_window: one of 'never' / '3_months' / '6_months' / '12_months' / 'unspecified'. Pick 'unspecified' whenever the body signals "later" / "not now" without committing to a concrete date ("come back later", "maybe next year", "we'll reach out when ready"). Only pick a concrete window when the recipient names one. Don't drop the field — leaving it null when the recipient said "later" loses the deferral and the prospect re-enters the pool immediately. The server resolves 'unspecified' to the project's unspecified_recontact_window_months setting (default 3 months)
• decision_maker_pointer: { name?, email?, role? } -- only when the body literally points to another contact ("contact alex@... for this", "speak to our CTO")
• consent: { gdpr_erasure_request, ccpa_opt_out, marketing_opt_out } -- set the relevant boolean to true when the body invokes the corresponding right
• submitted_at: ISO 8601 of received_at (or new Date().toISOString() if unknown)
• version: always 1

When to omit rejectionFeedback: if responseType !== 'rejection', omit it entirely (the server returns 400 if you pass it).

DNC interaction: setting primary_reason: 'unsubscribe_request', preferred_recontact_window: 'never', or any consent.*: true automatically forces do_not_contact = true even if you didn't pass markDoNotContact: true. You can still pass markDoNotContact explicitly for plain "stop emailing me" with no structured form.

6. Create Reply Drafts

If step 5 recorded a positive response (responded) for any prospect, use Gmail MCP to automatically create a reply draft.

Scope: Only replies with positive or neutral sentiment and response_type of reply or meeting_request. Bounces, auto-replies, and rejections are excluded.

Skip inquiry-derived leads and signups. If a prospect's inquiryOutcome is lead or signup_clicked and there is no matching Gmail / SNS reply found in step 5, skip draft creation for that prospect — there is no email thread to reply to. For lead, the project owner has already received a self-notification email; for signup_clicked, the recipient is now in the SaaS product's own signup flow and any follow-up should come from there, not from a sales reply. Surface both in step 7's report instead.

Draft creation steps:

1. Refer to the "Messaging" section of $0/SALES_STRATEGY.md for tone and structure, and the "Sender Information" section for the signature block to append (sender display name and email come from project settings — Gmail MCP creates drafts in the user's own account, so they're not needed as arguments here)
2. Write the draft in the language of the prospect's message (normally the project's targetLanguage). Create an appropriate draft based on the reply content:
   • Positive reply (interested) -> Thank you + scheduling link or 3 time slot options
   • Material request -> Thank you + note that materials will be sent (the user will attach the actual materials after the draft)
   • Question / inquiry -> Draft answer to the question + next step suggestion
   • Scheduling confirmation -> Thank you for confirming + details for the day
3. Create the draft with mcp__claude_ai_Gmail__create_draft. Set subject in reply format (Re: {original subject})
4. Include the number of drafts created in the results report

Note: Do not send automatically. Only create drafts; sending is done manually by the user after reviewing the content. If draft creation fails (Gmail MCP not connected, etc.), skip and report in the report.

7. Results Report

Report the following:

• Number of prospects checked
• Number of prospects with responses and breakdown (positive/neutral/negative)
• Response rate (responses / approaches)
• Response type breakdown (direct reply / scheduling confirmation, etc.)
• List any low-confidence matches as "Needs confirmation"
• Server-side reply collection: the status line from step 2
• Unconfirmed SNS DMs: N (when SNS checking was skipped; report even if 0)
• Reply drafts created: N (number created in step 6; report even if 0. If drafts exist, guide the user to check Gmail drafts)
• Summary of notable replies
• Guide the user to run /evaluate as the next step
• If any rejection responses with PMF-relevant reasons (feature_gap / already_have_solution / competitor_locked) were recorded in step 5, also mention: "/check-feedback surfaces PMF signals from rejection feedback (feature gaps, competitor presence)." Do not mention /check-feedback for any other rejection reasons — non-PMF signals (tactical, unsubscribe, other) will be consumed by /evaluate automatically.

Inquiry landing section (only when at least one log has inquirySessionCount > 0):

• Lead via inquiry landing: N — call out this number first and prominently when ≥ 1, since these are high-signal recipients who explicitly asked to talk. For each lead include prospectName (and contactName when set), prospectEmail if present otherwise organizationDomain, inquiryMeetingSource (button / chat), and inquiryLastVisitAt. The project owner has already been notified by email at the moment of conversion, but surfacing them here keeps the daily report self-contained.
• Signup via inquiry landing: N — call out separately when ≥ 1 (only relevant when the project runs in signup CTA mode). These are recipients who opened the project's signup URL; no human follow-up is expected, but track count for self-serve conversion measurement. For each include prospectName (and contactName when set), prospectEmail if present otherwise organizationDomain, and inquiryLastVisitAt.
• Visits / inquired / unsubscribed via chip — short counts grouped under "Inquiry landing activity":
  • Visits: total prospects with inquirySessionCount > 0
  • Inquired (chat used, no lead/signup): inquiryOutcome === 'inquired'
  • Unsubscribed via chip: inquiryOutcome === 'unsubscribed'
• Do not echo chat message bodies in the report. Surface only the aggregates above. (Chat-content visibility on the sender side is gated on a separate compliance review.)

Append a single low-key dashboard line at the end: Dashboard: https://app.leadace.ai/responses — purely informational, do not push the user to open it.

Report directly to the user (no file output needed -- response data is stored in the DB).