Multichannel Product and Service Outreach

# Multichannel Product and Service Outreach

Research qualified prospects and prepare personalized email outreach, with optional LinkedIn outreach when the user selects it, for the product or service the user wants to promote. After the Skill is installed, let the user choose a preferred online sheet app, such as Google Sheets, Airtable, or Lark Base, and use it as the campaign tracker and provider-evidence record. Ask the user to describe the product or service they want to promote through outreach. Prefer context from informational files supplied by the user, the offering's official website, or its public social media profiles.

## Loadout capabilities

Use <integration-tag>direct:apollo_lead_ops_tools</integration-tag> to find organizations and people that match the user-defined audience, then enrich only the shortlisted identities needed for the requested channels.

Use <integration-tag>direct:deep_research_tools</integration-tag> to verify company facts, current roles, audience fit, public hooks, and credible evidence URLs.

Use exactly one tracker integration selected by the user:

- Use <integration-tag>composio:googlesheets_tools</integration-tag> for a Google Sheets campaign tracker.
- Use <integration-tag>composio:airtable_tools</integration-tag> for an Airtable campaign tracker.
- Use <integration-tag>cli:lark</integration-tag> for a Lark Base campaign tracker.

Whichever tracker the user selects, inspect its live schema, deduplicate against relevant rows or records, create drafts, record the reviewed batch, update delivery state, and read every changed item back. Keep the same logical campaign fields across providers.

Use <integration-tag>composio:gmail_tools</integration-tag> when the selected channels include email. It provides sender verification, sent-folder and reply evidence, dry runs, sending, and message read-back.

Use <integration-tag>cli:heyreach</integration-tag> only when the user chooses LinkedIn outreach. It provides sender, list, campaign, lead, sequence, inbox, and progress operations.

Use <action-tag>cli:jq:run</action-tag> to validate the campaign manifest before the first send and again after the final provider update. The manifest may contain reviewed campaign content and provider read-back, but never credentials or unnecessary personal data.

Every integration and Action call remains subject to Loadout authentication, authorization, confirmation, billing, provider policy, and input validation. This Skill is guidance and never grants tool access.

## Campaign brief

Before research or drafting, establish one current campaign brief containing:

- the product or service name;
- the organization or individual offering it;
- a factual one-sentence description;
- the target audience, account profile, and relevant buyer or user roles;
- the audience problem, goal, or opportunity the offering addresses;
- the value proposition and differentiators the user wants emphasized;
- only the claims, proof points, customer examples, metrics, awards, or credentials the user has provided for use;
- the requested geography, languages, batch size, timing, and channels, including whether the user wants LinkedIn outreach;
- the sender's real identity, role, organization, and connected channel accounts;
- the desired call to action, such as a reply, demo, consultation, trial, purchase, partnership, event, coffee, or video call;
- tone, exclusions, compliance constraints, and any words or claims to avoid;
- the user's selected tracker app and the spreadsheet, base, table, or worksheet used for the campaign.

If a detail is not relevant, record it as not applicable. If the offering, audience, sender, claims, requested channels, or call to action is unclear, ask the user before drafting. Never fill a missing brief with facts from another campaign.

## Truthfulness and user intent

- Promote only the product or service the user has asked to promote in the current request.
- Treat user-supplied claims as proposed copy, not verified facts. Confirm the wording and preserve any necessary qualification.
- Use public evidence for prospect-specific hooks. Do not imply a private relationship, product use, business problem, or personal fact that the evidence does not support.
- Do not invent customers, results, urgency, scarcity, endorsements, awards, integrations, pricing, travel, local presence, or product capabilities.
- Do not impersonate another sender or use a connected account that differs from the campaign sender.
- Refuse fraudulent, deceptive, illegal, discriminatory, or policy-evasion campaigns. Stop when the requested audience or content violates the active provider's rules.
- Minimize personal data. Collect only what is needed to qualify the prospect, personalize the campaign, execute the selected channels, and reconcile evidence.

## Review before sending

Research and drafting may proceed before the user reviews the batch.

Before sending messages or activating a provider campaign:

1. Show the proposed record IDs or batch size, sender, channels, message version, and representative samples.
2. Ask the user to confirm the batch and channels to run.
3. If the response is ambiguous, ask a short follow-up question.
4. Re-read the selected tracker items and connected senders immediately before execution.

Confirmation applies to the named batch and channels. If the user confirms campaign setup but not activation, leave the LinkedIn campaign in `DRAFT` or `PAUSED`.

For a combined email and LinkedIn batch, validate the email payloads, HeyReach list, campaign sequence, and rendered per-prospect messages in the same manifest before sending either channel.

## Preflight

1. Read the current campaign brief and identify every missing or ambiguous field.
2. Search the live Loadout capability catalog and inspect current input schemas. Do not reuse an operation name from memory.
3. Confirm Vault readiness for every required integration. Catalog availability does not prove account readiness.
4. Ask the user to choose Google Sheets, Airtable, or Lark Base unless a tracker was already supplied. Resolve the selected spreadsheet or base, read its live schema, and map the campaign fields to existing columns.
5. Read all tracker rows needed for deduplication, prior-contact exclusions, and campaign review. Include every page.
6. Verify that the requested audience is appropriate for each selected channel. Skip LinkedIn and all HeyReach setup when the user did not select LinkedIn outreach.
7. Verify the sender identity and connected account for every requested channel.
8. For a selected LinkedIn execution, check HeyReach authentication, sender health, existing lists, and existing campaigns before making changes.
9. Build one campaign manifest keyed by the selected tracker's row or record ID. Include the brief version, normalized contact identifiers, exact channel copy, sender IDs, selected channels, and user confirmation.
10. Validate the manifest as specified in "Manifest validation." Continue only when every selected record passes.

If a required connection is unavailable, surface the returned authorization URL, wait for the user to complete it, and verify with a read-only call.

## Discovery and qualification

Translate the campaign audience into explicit search and qualification rules. Do not assume that founders, executives, engineers, or any other persona are correct unless the brief says so.

For each candidate:

1. Confirm that the organization and person match the requested audience, geography, and role using current evidence.
2. When LinkedIn outreach is selected, validate that the LinkedIn profile belongs to the named person and currently matches the organization and role. Otherwise treat the LinkedIn URL as optional context.
3. Require a verified work email when email is requested. Do not use a personal email for cold business outreach unless the user supplies it for that purpose and the campaign is lawful and provider-compliant.
4. Record a concise fit reason that connects the prospect to the campaign audience criteria.
5. Capture a specific public hook when credible evidence is available. Otherwise use accurate audience-level context from the campaign brief.
6. Identify a relevant problem, goal, or opportunity only when supported by evidence. Otherwise use the broader audience-level need from the campaign brief and label it accordingly.
7. Select only the value proposition and proof points from the campaign brief that are relevant to this prospect.
8. Save the qualification and personalization evidence URLs.

Review or exclude a candidate when:

- the person or organization identity is ambiguous or clearly mismatched;
- the candidate clearly falls outside an essential audience criterion in the campaign brief;
- a required channel identifier is missing or unusable;
- the candidate duplicates an existing tracker or provider record;
- the candidate is on a suppression list or there is evidence they should not be contacted.

Do not exclude a candidate solely because a prospect-specific hook, geography detail, or optional profile field is unavailable. Use accurate audience-level context, omit unsupported personalization, and use only the channels with suitable contact information.

Do not invent or enrich data merely to reach the requested batch size. Report a smaller qualified cohort when that is what the evidence supports.

## Deduplication and contact history

Normalize and compare:

- organization website domain;
- LinkedIn profile URL when available;
- lowercase work email;
- provider lead ID or message thread ID when available.

Canonicalize LinkedIn profile URLs before comparing them. Normalize `http` to `https`, remove `www` and trailing slashes, and decode percent-encoded profile slugs.

Treat prior `Sent`, `Replied`, `Pass`, `Unsubscribed`, `Bounced`, and previously contacted records as durable exclusions unless the user explicitly requests an appropriate follow-up campaign. Honor suppression lists and provider exclusions. Do not append a second row for a lead already present under a different capitalization or URL form.

## Online campaign tracker

Use Google Sheets, Airtable, or Lark Base according to the user's choice. Keep the following logical schema consistent across providers and map it to the selected app's existing columns or fields:

- `Campaign`
- `Offering`
- `Organization`
- `Organization Website`
- `Contact`
- `Role`
- `Contact Location`
- `Work Email`
- `LinkedIn`
- `Audience Fit`
- `Qualification Source URL`
- `Public Hook`
- `Hook Source URL`
- `Problem or Goal`
- `Value Proposition`
- `Proof`
- `Call to Action`
- `Subject`
- `Draft Email`
- `LinkedIn Connection`
- `LinkedIn Follow-up`
- `Channels`
- `Status`
- `Notes`

Do not redesign the sheet or base, rename columns, or create status fields without permission. If per-channel review and delivery columns already exist, update them independently.

Write only the fields needed for the campaign. Create rows or records in batches of at most 200, set `Status = Draft`, then read back the exact created items and verify the campaign, identity, sources, and message content.

## Drafting rules

Follow the user's requested language and tone. Keep cold outreach concise, specific, respectful, and easy to decline.

- Lead with relevant evidence, not generic praise.
- Connect the prospect's context to the campaign value proposition without overstating certainty.
- Use only proof points and claims from the current campaign brief.
- Keep each message focused on one primary benefit and one call to action.
- Do not create false urgency, pressure, or a misleading subject line.
- Avoid em dashes, en dashes, divider-style dash lines, and mechanical truncation in outreach copy. Use short sentences, commas, periods, and conventional hyphens.
- Render every variable before showing a sample or requesting review.

### Email

Draft the subject and body as one reviewable unit. A useful default structure is:

1. A short, truthful subject relevant to the prospect.
2. A specific public hook or audience-fit reason.
3. The relevant problem, goal, or opportunity.
4. A concise explanation of the product or service in the campaign brief and why it may help.
5. One provided proof point when useful.
6. The campaign call to action.
7. The sender's real name, role, organization, and requested signature details.

Do not force every component into a message when the user requests a shorter format. Never add a product claim, customer result, discount, deadline, local visit, or meeting offer that is absent from the brief.

### LinkedIn (optional)

Use this section only when the user selects LinkedIn outreach. Store the connection note and follow-up separately, even when the user's tracker currently combines them in one display field.

The connection note must:

- remain within 200 characters unless the active account supports a higher confirmed limit;
- identify the real sender or organization when context requires it;
- name or clearly describe the product or service in the campaign brief when space allows;
- include a compact public hook or audience-fit reason;
- use the campaign call to action or a low-friction transition to the follow-up;
- use complete language and never end with a mechanically truncated hook or ellipsis.

The follow-up must:

- use the same evidence and positioning as the reviewed email or campaign brief;
- explain the relevant product or service benefit without unsupported claims;
- include only proof from the campaign brief;
- make the campaign call to action;
- identify the sender accurately.

For HeyReach personalization, prefer a small, explicit set of single-brace variables:

- `{FIRST_NAME}`
- `{COMPANY_NAME}`
- `{HOOK}`
- `{FIT_REASON}`
- `{VALUE_PROP}`
- `{PROOF}`
- `{CTA}`

Use only the variables required by the reviewed template. Never leave unresolved variables in a rendered sample.

HeyReach API input and read-back use different property names:

- write dynamic variables through `customUserFields`;
- verify them through the returned `customFields`;
- never send `customFields` as the import property, because HeyReach can accept the lead while silently discarding those values.

## Manifest validation

Build one manifest containing:

- the reviewed campaign brief and a stable brief digest or version;
- the selected channels, sender identities, and user confirmation;
- the selected tracker items keyed by row or record ID;
- Gmail preflight rows keyed by record ID when email is selected;
- the HeyReach campaign status, fallback messages, sequence, and complete provider-returned lead set when LinkedIn is selected.

Run `cli:jq:run` against the reviewed manifest and fail unless all applicable conditions are true:

1. The selected cohort is non-empty.
2. Record IDs are unique. Every channel identifier required for that record is normalized, non-empty, and unique within the cohort.
3. Every record matches the same campaign brief, offering, sender, and selected channel set.
4. Every record contains the campaign fields needed for its selected channels. A prospect-specific hook is required only when the copy uses one.
5. Every claim and proof point used in copy appears in the campaign brief.
6. When email is selected, every record has a subject and body. The Gmail preflight count equals the selected email count, and every normalized recipient, subject, and whitespace-normalized body matches the tracker exactly.
7. When LinkedIn is selected, every record has a connection note and follow-up. Each connection note is within the confirmed character limit and contains no ellipsis, em dash, en dash, or divider line.
8. When LinkedIn is selected, the HeyReach campaign is `DRAFT` or `PAUSED` during validation.
9. HeyReach fallback messages equal the reviewed configuration and are not unpersonalized substitutes for the per-lead copy.
10. The provider lead count and normalized LinkedIn URL set equal the selected LinkedIn manifest exactly.
11. Every provider-returned custom field equals the matching selected record.
12. Rendering the provider-returned sequence with the provider-returned custom fields reproduces the reviewed LinkedIn messages exactly and leaves no unresolved variable.

The validation output must report the total selected count, per-channel counts, email preflight matches, LinkedIn lead matches, rendered connection matches, and rendered follow-up matches. Every applicable match count must equal its selected channel count. Save the exact filter expression with the campaign record for reproducibility, but do not place credentials or unrelated personal data in the manifest or filter.

## Review handoff

After writing drafts:

1. Restate the offering, audience, positioning, proof, sender, channels, and call to action used.
2. Report candidates found, rejected, held, deduplicated, and appended.
3. Link the selected spreadsheet or base.
4. Show three to five representative samples for every requested channel.
5. Identify any assumption, missing evidence, or copy variation that needs review.
6. State the exact record IDs or batch size, message version, sender, and channels proposed for sending.
7. Stop.

## Email execution

After the user confirms the batch and email channel:

1. Resolve the exact selected tracker item IDs and re-read their campaign brief version, identity, content, sender, and review fields.
2. Revalidate every work email and the connected sender.
3. Run a provider dry run for every recipient and save the normalized recipient, subject, and body in the manifest.
4. For a combined campaign, complete the HeyReach `DRAFT` or `PAUSED` preflight before sending the first email.
5. Validate the complete manifest. Require an exact email preflight match for every selected email record.
6. Before each send, check the sent folder for the normalized recipient and exact subject. Treat a matching provider message as the idempotency checkpoint and do not send it again.
7. Send the exact reviewed subject and body through the live Gmail capability.
8. Capture the provider message ID and query its delivery status.
9. If the provider returns a transient write conflict or rate limit, stop the batch, respect the provider cooldown, re-read the sent folder, and resume only records without sent evidence.
10. Update only the selected record's channel status and evidence notes.
11. Read the sent message back and compare recipient, subject, and normalized body with the tracker. Report successes and failures separately.

Do not expose credentials or mark an email sent without provider-side evidence.

## LinkedIn execution

After the user confirms the batch and LinkedIn channel:

1. Revalidate HeyReach authentication and the exact sender account.
2. Check existing leads, lists, and campaigns for duplicates and suppression conditions.
3. Create the campaign in `DRAFT` and keep a reviewed correction `PAUSED`. Never validate personalization against an active campaign.
4. Import one unsent canary lead with `customUserFields`, then read the lead back through `customFields`. Continue only if every required field name and value matches exactly and the campaign remains `DRAFT` or `PAUSED`.
5. Populate the complete list before activation. Preserve final reviewed per-lead copy in explicit custom fields, or use the minimal template variables when the campaign uses a shared template.
6. Read every lead back. Require the provider lead count and normalized LinkedIn URL set to equal the selected manifest exactly.
7. Keep required plain fallback messages specific to the offering and campaign. Do not treat fallback text as personalized copy. Activate only when every normal personalization field renders successfully so the fallback cannot be selected.
8. Read the sequence back, render the connection request and follow-up for every lead using the returned `customFields`, and compare both strings exactly with the tracker. Sampling is not sufficient.
9. Validate the manifest and require all selected records to pass with no unsupported claim, unresolved variable, missing custom field, fallback mismatch, extra lead, or missing lead.
10. Use at least a three-hour delay after a connection action and before the terminal action.
11. Activate only when the user confirmed activation and final manifest validation passed after the last provider update.
12. Immediately read back the campaign ID, list ID, status, sender, schedule, sequence, lead counts, exclusions, and failures.

Do not add a new batch to a finished campaign. Create a new list and campaign so the selected cohort remains exact. Avoid editing a running sequence or schedule. Pause it before applying a reviewed correction, then resume it and read back provider state.

## Daily progress reconciliation

Run this read-first reconciliation before discovering or sending more leads when the campaign is active, and at the frequency the user requested:

1. Read the current tracker schema and every campaign contact in `Ready`, `Sent`, `Replied`, `Bounced`, `Unsubscribed`, or another actionable state. Include every page and project the row or record ID, campaign identity, contact identifiers, per-channel status, and notes.
2. Check Gmail for sent-folder evidence, delivery failures, bounces, unsubscribes, and inbound replies. Match by normalized recipient plus provider message or thread ID when available.
3. When LinkedIn outreach is part of the campaign, check HeyReach campaign and lead progress, including connection requests, accepted connections, follow-ups, replies, exclusions, failures, stopped leads, and pending leads. Read the inbox or conversation details for any reported reply.
4. Reconcile each provider event to exactly one tracker item. Stop on ambiguous identities rather than updating multiple contacts.
5. Update `Ready` to `Sent` only with provider-side send evidence. Update `Sent` to `Replied` only after reading an inbound reply tied to that contact. Record bounces, unsubscribes, and provider exclusions without erasing earlier evidence.
6. Append the channel, event time, provider identifier, and meaningful failure detail to `Notes` when a status or actionable condition changes. Preserve existing notes and leave unchanged contacts untouched.
7. Keep normal status progression one-way: `Draft` to `Ready` to `Sent` to `Replied`. Use `Pass` only when the user decides not to continue. Treat suppression states as terminal unless the provider or user supplies a legitimate correction.
8. Draft suggested replies for the user's review. Ask before sending a reply or changing the campaign during reconciliation.
9. Read back every changed tracker item and report contacts checked by channel, state transitions, replies, accepted connections, follow-ups, bounces, unsubscribes, failures, exclusions, stopped leads, pending contacts, unchanged contacts, and ambiguous events.

Do not treat a tracker status, campaign summary count, or sent-folder row by itself as proof of a reply. Read the provider message or conversation before marking `Replied`.

## Pause or adjust

Handle issues at the smallest useful scope. Pause the full campaign only when:

- the requested audience or content violates applicable law or provider policy;
- the campaign sender cannot be identified reliably;
- a campaign-wide duplicate or suppression issue makes additional messages unsafe.

For other issues, ask a short question, correct the campaign brief or copy, omit the affected channel, or hold only the affected records while continuing with the rest. A recipient identity mismatch, provider authentication or billing error, rate limit, missing optional profile detail, geography, prospect-specific hook, or email address should not stop unaffected records or channels.

If tracker and provider content differ, a variable is unresolved, or a HeyReach field does not read back correctly, keep the affected messages unsent, correct them, and validate those records again.

## Final read-back

For a draft-only run, report:

- the campaign brief used;
- discovery, rejection, hold, and deduplication counts;
- draft rows created;
- tracker read-back result;
- representative samples;
- the exact batch and channels ready for confirmation.

For an executed run, also report:

- per-channel sends with provider evidence;
- HeyReach campaign and list IDs when applicable;
- campaign status and schedule;
- imported, excluded, failed, and in-progress lead counts;
- bounces, unsubscribes, and replies;
- any records still requiring manual review.

For a progress run, report the reconciliation window, provider read-backs, status transitions, unchanged counts, failures, and reply drafts ready for review.