Turn scattered customer research into ad-targeting personas built around actual objections, not demographic guesses

Turn the raw customer research below into ad-targeting personas. Each persona must be defined primarily by the objection or hesitation it holds toward this product, not by demographic traits alone — a persona built only from age range and job title tells an ad team nothing about what to say to that person.

PRODUCT
A cloud backup tool for small accounting firms.

RAW RESEARCH INPUTS
12 support tickets mentioning worry about client data security compliance; 4 sales call notes where prospects asked about migration downtime; a survey where 60% cited "too expensive for what it does" as their top concern.

HOW MANY PERSONAS NEEDED
2-3 — the team only has bandwidth to run distinct creative for a small number of segments.

EXISTING PERSONAS TO RECONCILE WITH
"Busy Bookkeeper" persona currently used in Google ads, built mostly on job title with no stated objection.

Read the raw research inputs for recurring hesitations, not just recurring facts — if three different support tickets or call notes independently express doubt about the same thing (implementation time, whether it integrates with an existing tool, whether the price scales badly), that's a persona-defining signal even if the people who said it don't share obvious demographic traits. Do not manufacture a demographic detail (age, income, company size) that isn't actually supported by the research inputs — if the inputs don't specify company size, say the persona is defined by role and objection only, and leave demographic fields honestly blank rather than inventing plausible-sounding numbers. For each persona, name the one ad angle or proof point that would most directly address their specific objection — not a generic value proposition restated per persona, but the one argument this specific person needs to hear that a different persona wouldn't. If existing_personas are provided, merge or split against them explicitly rather than starting over — say which existing persona each new one maps to, replaces, or splits into two, so the team doesn't end up running two parallel and uncoordinated persona sets.

OUTPUT FORMAT
For each persona: name, the objection that defines them (quoting or closely paraphrasing the research signal it came from), what demographic/firmographic traits are actually supported by the data (marking any as "not established by research" rather than guessing), and the one ad angle that addresses their objection directly. Close with a one-line map of how these personas relate to any existing_personas given.