objection_to_content_mapping v1.0.0

name: objection_to_content_mapping description: "Turning sales objections into content: collect real objections verbatim from calls, replies, comments, and lost deals, group them by the belief underneath, rank them, and plan posts, videos, and sales assets that answer each belief with documented proof instead of claims. Triggers on 'turn objections into content', 'objection log', 'our buyers keep saying X', 'content from sales calls', 'why do deals stall', or a content plan that needs to answer price, trust, timing, or switching pushback."

Objection to Content Mapping

Purpose

Buyers state their real reasons for not buying, out loud, every week, in sales calls, DMs, comments, support threads, and lost deal notes. Most teams answer those reasons one call at a time and then lose them. This skill turns that stream into a working system: a verbatim objection log, a grouping by underlying belief, a ranked queue, and one content plan per belief that answers with proof the reader can check. The output feeds public content and sales replies from the same source, so the post a prospect reads on Tuesday matches the answer they hear on Thursday.

Workflow

1. Collect verbatim, from every surface

• Pull objections from recorded sales calls and their transcripts, DM and email threads, post comments and replies, support tickets, review sites, win and loss notes, and exit or churn conversations.
• Log the exact words at the moment of capture. Paraphrase at capture destroys the asset: the buyer's own phrasing is what later becomes the hook, and it is the audit trail for whether the grouping was honest.
• Record one row per objection with date, source, segment, stage, and outcome where known. Use python3 scripts/objection_log.py init <log.csv> to start a log and python3 scripts/objection_log.py validate <log.csv> to check it. The template in assets/objection-log-template.csv shows a filled week.
• Strip names and identifying details from the log copy used for content work. Keep a private link back to the source record only where the business already stores it lawfully, and never publish a quote that identifies a person without their permission.
• Aim for coverage across sources, not volume from one loud channel. A belief that shows up in calls, comments, and lost deals outranks one repeated ten times in a single thread. This follows standard voice of customer practice: Harvard Business School Online describes a VoC program as collecting and analysing feedback through surveys, interviews, observation, and market research, rather than relying on one instrument.

2. Separate the line from the belief

• Read the full log before coding anything, then code each row close to its own wording, then build groups. That order comes from thematic analysis (Braun and Clarke): familiarisation, initial codes, candidate themes, review against the raw data, then define and name.
• For each row, ask: what would this person have to believe for that sentence to make sense? Write that belief in one plain sentence. "Too expensive" becomes, for one buyer, "the result is worth less than this price," and for another, "I cannot defend this spend to my partner." Same line, different beliefs, different content.
• Use the test question listed for each family in references/belief-taxonomy-and-proof-ladder.md when a live conversation allows it. On a call, the test question earns more than a rebuttal does, and the answer goes in the log.
• Keep the dissenting rows. An objection that fits no group is a signal about the taxonomy or the segment, so park it in an ungrouped row set and review it at the next cycle instead of forcing it in.

3. Group by belief and rank the queue

• Assign each row to one of seven belief families: value, trust, fit, timing, authority, switching, effort. Definitions, example lines, test questions, and the proof each family needs are in references/belief-taxonomy-and-proof-ladder.md. Published sales taxonomies vary in count and labels, so treat these seven as a working set for planning, and adjust them when the log shows a split that matters.
• Run python3 scripts/objection_log.py report <log.csv> --out plan.md to get the ranked groups with counts, lost outcomes, sources, stages, proof on file, and the top verbatim lines per group. The score is a stated planning formula (occurrences times 3, plus lost outcomes times 2, plus distinct sources), not a research finding. Argue with the weights in the open if they mislead.
• Promote one belief at a time to the top of the queue. A short queue finished well beats a full calendar of thin replies to everything.

4. Hunt proof before drafting anything

• For the top belief, list the proof on file first. Rank it on the proof ladder in the taxonomy reference: demonstration on a real case at the top, then documented customer results with permission, process transparency, third party material, real written risk terms, mechanism explanation, and plain assertion at the bottom.
• If the best available proof sits at the bottom two rungs, the job for this cycle is proof collection: run the demonstration, ask the customer, document the migration, time the comparison. Drafting around missing proof produces claims, and claims are what created the trust belief in the first place.
• Give every proof asset an ID and record it in the log's proof_id column: what it is, whose it is, the date, the permission note, and the baseline and period behind any number in it.
• Check testimonial and result content against the FTC Endorsement Guides (16 CFR Part 255) before it ships: endorsements must reflect the honest experience of the person giving them, a result shown for a key attribute is read as typical unless the generally expected performance is disclosed with substantiation, material connections get disclosed, and "results not typical" does not fix an atypical result. Full notes are in the taxonomy reference.

5. Match the plan to the reader's stage

• Place the belief's audience on the five awareness stages from Eugene Schwartz, Breakthrough Advertising (1966): unaware, problem aware, solution aware, product aware, most aware. The log's stage column is the first evidence, search and comment context is the second.
• Problem aware readers get content that names the situation in their words and shows the cost of the current way, with the product kept late or absent. Solution aware readers get category comparisons and mechanism content. Product aware readers get the proof assets: demonstrations, documented results, switching walkthroughs. Most aware readers get terms, timing, and the forwardable case.
• Expect looping rather than a straight path. Think with Google's Messy Middle research describes buyers moving back and forth between exploration and evaluation across search, social, and review sites before purchase, so publish the proof asset where evaluation happens (the comparison page, the review reply, the sales follow up) as well as where exploration happens (the feed post, the short video).

6. Write the plan: three formats per belief

• Draft one post, one short video, and one durable asset per belief, all built from the same proof. Three full worked plans, structure included, are in references/worked-content-plans.md.
• Open with the verbatim objection, anonymised. A reader who has thought the same sentence stops for it, and the seller earns credit for saying the hard part first.
• Concede what is true in the objection before answering it. The spreadsheet really is free. The migration really does have two manual steps. Concessions are the part of the post a sceptical reader believes, and they carry the rest.
• Answer with the proof asset, shown rather than described: the timed run, the screen recording, the step list with real times, the documented result with its basis stated.
• Close with the next step that fits the belief: a worksheet for value, a reference call for trust, a checklist for switching, a forwardable one pager for authority. A generic "book a demo" close ignores the belief the whole piece just answered.
• Draft the sales reply asset last, from the published piece: one short paragraph and the link, in language a rep can paste without editing. This is how the loop reaches buyers who never see the public content.

7. Publish, tag, and close the loop

• Tag every published piece with the belief ID and the proof IDs it used, in whatever content calendar or tracker the team already keeps.
• Keep logging new objections after publishing. The measure for a belief is the log itself over the following 30 days: new rows for that belief against call and traffic volume, the wording shift inside those rows, and how often sales sends the asset and gets an answer.
• Retire a belief from the active queue when its rows fall and stay down across two cycles, and keep its assets live. Retired beliefs come back when segments or pricing change, and the old proof rarely survives that change, so recheck it before reuse.
• Feed product and pricing signals upward. A fit or effort belief that recurs across segments is often a product fact wearing a content costume. Report it as such instead of writing harder around it.

Output Contract

Given a log or a raw pile of objections, return: (1) the validated log, or the rows extracted into the log format with verbatim quotes preserved, (2) the ranked belief groups with counts, sources, and the priority score shown, (3) for the top belief, the proof inventory with IDs and any proof gaps stated plainly, (4) the content plan for the top one to three beliefs, each with a post, a short video, and a durable asset, plus the sales reply paragraph, (5) the measure to read in the log after 30 days. If proof for a belief does not exist yet, the plan for that belief is a proof collection plan, and it says so.

Operating Rules

1. Verbatim or it did not happen. No invented objections, no cleaned up quotes presented as quotes, no composite buyers presented as real people.
2. Every number in a published piece traces to a proof asset ID. No asset, no number.
3. Never publish a quote, screenshot, or result that identifies a person or company without permission recorded next to the asset.
4. Concede the true part of every objection in print. Content that argues with buyers loses to content that answers them.
5. One belief, one plan. A piece that tries to answer price, trust, and timing at once answers none of them.
6. No manufactured deadlines, fake scarcity, or pressure closes in objection content. It converts a timing belief into a trust belief and poisons the log for months.
7. Testimonial and endorsement content follows the FTC guides in the reference file, including typicality and material connection disclosure. Quoting a happy customer is advertising, and it is treated that way.
8. If the log is too thin to group honestly (fewer than about fifteen rows, or one source only), say so and ship a collection plan instead of a content plan.