1 · When to use it

You have a target account list and no time to research it. Use this when the list is already qualified at company level and the missing work is person-level research and first-draft writing.

Do not use this for cold list building from nothing. Feed it a list someone has already decided is worth pursuing.

2 · Required inputs and access

Inputs

• The target list, named explicitly (a CRM view, a saved report, or a file in /workspace)
• Your ICP definition and disqualifiers
• Two or three examples of outreach you actually sent and were happy with
• Maximum number of accounts per run

Access

• CRM (connector preferred, browser sign-in acceptable)
• LinkedIn or equivalent, signed in
• Web search
• Any internal data source you use for intent or usage signals

3 · Sequence of work

1. Pull the named list. Record the exact view and the timestamp.
2. Remove anyone already in an active sequence, anyone with an open opportunity, and anyone marked do-not-contact. Log how many were removed and why.
3. For each remaining account, gather: what they do, recent public changes (funding, leadership, product, hiring), and any signal that connects to what you sell.
4. Identify two to four contacts per account. Capture role, tenure, and the reason this person rather than their colleague.
5. Score each contact against the ICP. Use a stated scale and show the reasoning in one line.
6. Draft one email and one connection note per contact, in the voice of the supplied examples.
7. Assemble everything into a single review list. Do not send anything.

4 · How to validate the result

• Every factual claim about an account carries a source link and a date
• No draft references a fact older than 90 days without labelling it as such
• No two drafts in the batch share an opening line
• Suppression worked: spot-check three names against the CRM to confirm none are already in sequence
• Scores are defensible — if you cannot state why a contact scored 8 rather than 5, the score is noise

5 · What to return

A single table: Account | Contact | Role | Score | Signal | Source + date | Draft ready?

Below it, the drafts in full, grouped by account. At the top, three numbers: accounts processed, contacts found, contacts suppressed.

6 · What requires approval

• Sending any email
• Sending any connection request or direct message
• Writing to the CRM, including logging activity or changing status
• Adding anyone to a sequence

7 · No-data and stale-data policy

If the CRM view is unreachable, report the failure and stop. Do not fall back to a previous export.

If a company signal is older than 90 days, include it but mark it [stale]. If every signal for an account is stale, drop the account from the batch and say so.

Save it

Save this as a skill called “OVERNIGHT-PIPELINE”. Include the suppression rules, the scoring scale, the voice examples, the requirement that every claim carries a source and date, and the rule that all sending and all CRM writes require my approval.

Run it as a routine

Every weekday at 05:00 Europe/Paris, run OVERNIGHT-PIPELINE against the Tier 1 Prospects view, maximum 10 accounts. Post the review list in this conversation by 07:00. Draft only — send nothing and write nothing to the CRM. If the view is unavailable, report the failure instead of using an old export.

1 · When to use it

Inbound volume is high enough that you are reading unqualified enquiries. Use this when you can articulate what a good lead looks like and what a time-waster looks like.

Not for low volume. If you get four enquiries a week, read them yourself.

2 · Required inputs and access

Inputs

• Where inbound arrives (inbox, form, shared address, CRM queue)
• Your qualification criteria, written as rules not vibes
• Routing map: which category goes to whom
• Your standard response templates, if any exist

Access

• Email or form connector, signed in
• CRM, to check whether the sender is already known
• Company enrichment source

3 · Sequence of work

1. Pull new inbound since the last run. Note the exact time window.
2. For each enquiry, check the CRM. Existing customer, existing opportunity, previously disqualified, or genuinely new.
3. Enrich the sender: company, size, sector, apparent role.
4. Apply the qualification rules. Assign one category and state the rule that triggered it.
5. For anything that fails qualification, draft a short polite decline. For anything that passes, draft a first response.
6. Flag anything the rules do not cleanly cover as NEEDS-JUDGEMENT rather than guessing.
7. Assemble the queue in priority order.

4 · How to validate the result

• Every categorisation names the specific rule that produced it
• Existing customers are never categorised as new leads — check this every run
• The NEEDS-JUDGEMENT pile is not empty and not enormous. Consistently empty means the rules are being over-applied; consistently huge means they are too narrow
• No draft response commits to pricing, timelines or scope

5 · What to return

A priority-ordered queue: Priority | Sender | Company | Category | Rule triggered | Existing relationship? | Draft

Three counts at the top: qualified, declined, needs judgement.

6 · What requires approval

• Sending any response, including declines
• Creating or updating CRM records
• Assigning an enquiry to a named colleague

7 · No-data and stale-data policy

If the inbox or form source is unreachable, report it immediately rather than at the end of the run. A silent triage failure means enquiries sit unread while you assume they are handled.

If enrichment data is unavailable for a sender, categorise on the message content alone and mark the row [unenriched].

Save it

Save this as a skill called “INBOUND-TRIAGE”. Include the qualification rules, the routing map, the requirement to check the CRM for existing relationships before categorising, the NEEDS-JUDGEMENT escape hatch, and the rule that nothing is sent without my approval.

Run it as a routine

Every weekday at 08:00 and 14:00 Europe/Paris, run INBOUND-TRIAGE against the shared enquiries inbox. Post the queue in this conversation. Send nothing. If the inbox is unreachable, alert me straight away rather than waiting for the run to finish.

1 · When to use it

Your CRM has drifted and you know it. Use this when reporting has become unreliable because the underlying records are dirty.

Not a substitute for a data governance policy. This finds problems; it does not stop them recurring.

2 · Required inputs and access

Inputs

• Which CRM objects are in scope (contacts, accounts, opportunities)
• Your definition of a duplicate — exact rules, since fuzzy matching will over-fire
• Staleness thresholds per object
• Required-field list per object

Access

• CRM, read access minimum, write access only if you intend to approve fixes
• Email verification source if you want bounce-risk detection

3 · Sequence of work

1. Pull the in-scope records. Record the object counts before any analysis.
2. Duplicate pass: apply the stated matching rules only. For each candidate pair, show both records side by side and the rule that matched them.
3. Completeness pass: find records missing required fields. Group by field, since one missing field across 400 records is a process problem, not 400 problems.
4. Staleness pass: opportunities with no activity beyond the threshold, contacts whose company no longer employs them, accounts with no owner.
5. Ownership pass: records owned by someone who has left, or unowned entirely.
6. Rank everything by impact on reporting rather than by count.
7. Produce the fix list. Change nothing.

4 · How to validate the result

• Every duplicate pair shows both records in full, so you can see why the match fired
• No fuzzy match is presented as certain
• The counts reconcile: records analysed equals records pulled
• Findings are grouped by cause, not listed as a flat 600-row dump

5 · What to return

A findings summary with one section per pass. Each section leads with the count and the reporting impact in one sentence, then the rows. Duplicates as side-by-side pairs with a recommended survivor and the reason. At the end, the three fixes that would most improve reporting accuracy.

6 · What requires approval

• Merging any records
• Deleting anything, ever
• Changing ownership
• Bulk field updates

7 · No-data and stale-data policy

If the CRM is unreachable or a query times out mid-run, report which passes completed and which did not. A partial hygiene report presented as complete is worse than no report.

Never use a cached export. Record counts change daily and stale counts produce false duplicates.

Save it

Save this as a skill called “CRM-HYGIENE”. Include the exact duplicate matching rules, the staleness thresholds, the required-field list, the requirement to show both records for every duplicate pair, and the rule that all merges, deletions and bulk updates require my approval.

Run it as a routine

Every Monday at 06:00 Europe/Paris, run CRM-HYGIENE across contacts, accounts and open opportunities. Post the findings in this conversation. Change nothing in the CRM. If a query fails, report which passes completed rather than presenting a partial report as complete.

1 · When to use it

You have accounts renewing on a cycle and the risk signals live in three different systems that nobody joins up. Use this when renewals are being lost to surprise rather than to price.

2 · Required inputs and access

Inputs

• Renewal calendar with dates and values
• Risk definitions: what counts as a red flag in usage, engagement, support and commercial terms
• The look-ahead window (90 days is a sensible default)
• Named owner per account

Access

• CRM or contract system for renewal dates and values
• Product usage data
• Support ticket system
• Email or calendar, for engagement recency

3 · Sequence of work

1. Pull every account renewing inside the look-ahead window. Record the window boundaries explicitly.
2. For each, gather usage trend against the prior period, support ticket volume and sentiment, last meaningful contact, and any open commercial dispute.
3. Apply the risk definitions. Assign red, amber or green, and state which specific signals produced the rating.
4. Weight by contract value so a small amber does not outrank a large red.
5. For every red and amber, identify the single most useful next action and who owns it.
6. Compare against last run. Flag any account that moved rating, in either direction. Movement is more informative than state.
7. Build the watch list.

4 · How to validate the result

• Every rating names its triggering signals — a rating with no evidence is a guess
• Usage figures carry the period they cover
• Movement since last run is shown, not just current state
• No account renewing in the window is missing from the list. Count against the renewal calendar

5 · What to return

A ranked watch list: Account | Value | Renewal date | Rating | Movement | Triggering signals | Next action | Owner

Above it, the total value at risk in red and in amber, and the number of accounts that moved rating this week.

6 · What requires approval

• Contacting any customer
• Creating tasks or cases in the CRM
• Escalating to a named colleague
• Anything that touches commercial terms

7 · No-data and stale-data policy

If usage data is unavailable, rate on the remaining signals and mark the row [partial]. Do not treat missing usage data as good usage data — that is the failure mode that loses renewals.

If usage data is older than 14 days, mark it stale and say so in the row.

Save it

Save this as a skill called “RENEWAL-WATCH”. Include the risk definitions, the look-ahead window, the value weighting, the requirement to show movement since the previous run, the rule that missing data is never read as good data, and the rule that all customer contact requires my approval.

Run it as a routine

Every Monday at 07:00 Europe/Paris, run RENEWAL-WATCH across the next 90 days of renewals. Post the ranked list in this conversation. Contact no customers. If usage data is unavailable, mark affected rows partial rather than rating them green.

1 · When to use it

You are writing the same proposal for the fourth time with different names in it. Use this when you have an approved content library and a defined structure.

Do not use this where the commercial construct is genuinely novel. Assembly is for known shapes.

2 · Required inputs and access

Inputs

• The brief or requirement document
• Location of the approved content library
• The proposal structure you use
• Approved pricing basis, or an explicit instruction to leave pricing blank
• Any client-specific constraints (format, page limit, mandatory sections)

Access

• Document store holding the content library
• CRM, for account context and history
• Word processor or slide tool, via connector or browser

3 · Sequence of work

1. Read the brief. Extract every explicit requirement and every implied one. List them separately.
2. Map each requirement to the section that should answer it. Flag any requirement with no matching library content — that gap is the most valuable output here.
3. Pull the approved content for each mapped section. Use the library version verbatim as the base; do not paraphrase approved language.
4. Tailor the connective writing only: client name, context, sequencing, emphasis.
5. Leave pricing blank unless an approved basis was supplied. If supplied, apply it and show the calculation.
6. Build the requirement-to-section compliance check.
7. Assemble the draft in the required format and save it to /workspace.

4 · How to validate the result

• Every requirement from the brief maps to a section, or appears in the gap list
• Approved library language is unaltered — diff it if you are unsure
• No invented capability, credential, client name or metric appears anywhere
• Page or slide limits are respected
• Pricing is either derived from the approved basis with a visible calculation, or blank

5 · What to return

The assembled draft as a file in /workspace. In the conversation: the compliance check as a table of requirement against section, the gap list, and a list of every paragraph that was written fresh rather than pulled from the library, so those get read closely.

6 · What requires approval

• Sending or sharing the proposal with anyone outside
• Any pricing not derived from the supplied approved basis
• Adding a client logo, reference or case study
• Committing to a date, volume or service level

7 · No-data and stale-data policy

If a library document is unreachable, name the section it would have filled and leave that section marked [MISSING — library unavailable]. Do not write replacement content from general knowledge and present it as approved.

If library content is older than 12 months, include it but flag it for review.

Save it

Save this as a skill called “PROPOSAL-ASSEMBLY”. Include the proposal structure, the rule that approved library language is used verbatim, the requirement to produce a gap list and a fresh-writing list, the rule that no capability or credential is ever invented, and the rule that all pricing and all external sharing require my approval.

Run it as a routine

Do not schedule this one. Run it on demand against a specific brief.

1 · When to use it

You have conversations going cold because follow-up is manual and you are busy. Use this where the follow-up is genuinely useful to the recipient.

Do not use this to pad a sequence. A cadence that adds nothing on touch three is a cadence that gets you blocked.

2 · Required inputs and access

Inputs

• The cadence: how many touches, spaced how far apart
• Stop conditions, written explicitly
• What each touch should add that the previous one did not
• Voice examples
• Daily volume cap

Access

• Email, signed in
• CRM, for activity history
• Calendar, to detect booked meetings

3 · Sequence of work

1. Pull every conversation currently in cadence. Record the touch number and the days since last contact for each.
2. Run stop conditions first, before drafting anything. Any reply, any meeting booked, any opt-out, any colleague reply on the thread, any out-of-office indicating a long absence, any bounce.
3. Remove everyone who hit a stop condition. Report them separately — the stop list matters more than the send list.
4. For everyone remaining and due, draft the next touch. Each one must add something new: a resource, a relevant development, a different angle. If nothing new can be said, do not draft — recommend exit instead.
5. Apply the volume cap. If more are due than the cap allows, prioritise by opportunity value and say what was deferred.
6. Assemble the send queue for approval.

4 · How to validate the result

• Stop conditions ran before drafting, not after. Verify by checking that no stopped contact has a draft
• Every draft adds something the previous touch did not. Read the prior touch to confirm
• No draft opens with a variation of “just following up” or “circling back”
• The volume cap is respected
• Anyone at final touch is marked for exit, not silently recycled

5 · What to return

Two lists, stop list first.

Stopped: Contact | Touch | Stop reason | Recommended next step

Due: Contact | Touch | Days since last | What this touch adds | Draft

6 · What requires approval

• Sending anything, without exception
• Adding anyone to a cadence
• Restarting a cadence for someone who previously exited
• Logging activity to the CRM

7 · No-data and stale-data policy

If email or CRM activity history is unavailable, do not draft. Drafting without knowing whether someone replied is how a Bot follows up with a person who already said yes.

Report the failure and skip the run entirely rather than running blind.

Save it

Save this as a skill called “FOLLOWUP-CADENCE”. Include the cadence spacing, the full stop-condition list, the rule that stop conditions run before drafting, the rule that a touch with nothing new to say becomes an exit recommendation instead, the daily volume cap, and the rule that nothing is ever sent without my approval.

Run it as a routine

Every weekday at 07:30 Europe/Paris, run FOLLOWUP-CADENCE. Post the stop list and the send queue in this conversation. Send nothing. If email or CRM history is unavailable, skip the run and tell me rather than drafting blind.