In reviewPrivate betaOwner: Desmond

Artifact

Objection-handling FAQ and cheat sheet

Updated internal sales FAQ covering current positioning, product maturity, EUR pricing, assisted beta, proof, trust, and procurement; competitor claims require revalidation.

This is an internal-first draft for the founder, sales lead, and outreach owners.

It is designed for live private-beta conversations, not as a buyer-facing document to send as-is.

Competitive positioning in this draft was last refreshed against market pages on 2026-04-18. Revalidate competitor claims before approving this for August 2026 sales use.

Positioning alignment note, 2026-06-18: the current official pitch leads with faster delivery, relevance/value pressure, and the bigger challenge of making insight travel across the organisation. It differentiates through owning the whole research lifecycle rather than just storing what others produce. Use defensibility, audit trail, and confidence as product promises or responses to buyer diligence, not as validated buyer fears.

Why these questions will come up

Buyers are already hearing strong claims from current vendors:

  • Qualtrics positions ExpertReview, response quality, and enterprise-grade security.
  • Forsta now positions AI agents across setup, analysis, and reporting.
  • Attest and Zappi lead hard on data quality and fast, reliable responses.
  • Suzy positions AI-moderated conversational research and presentation-ready outputs.
  • Dovetail, Stravito, and KnowledgeHound position repository, search, AI Q&A, and evidence reuse.

That means the real sales job is not just "What is this?" It is "Why this instead of my current stack, my current vendor's AI, or a stitched-together set of tools I already trust?"

How to use this sheet

  • Start with the short answer.
  • Expand only if the buyer leans in.
  • Tie every answer to a workflow, screen, or proof hook.
  • Translate "confidence" into audit trail, governance, reduced risk, or defensibility only when that language fits the buyer's question.
  • Do not improvise on legal, security, or procurement claims that are not yet packaged.
  • Add new real objections from weekly GTM reviews instead of treating this as static.

Positioning guardrails

  • We are strongest when the buyer values governed redesign before launch, live quality oversight during fieldwork, and connected evidence reuse together.
  • Do not position the product as a forced rip-and-replace on day one.
  • Do not position the system as fully autonomous research.
  • Do not imply Research Guard already matches Qualtrics or Conjointly on in-builder product maturity or one-click immediacy.
  • Do not imply the platform already matches Qualtrics-class post-field response-quality coverage or enterprise security proof.
  • Do not imply the trust or procurement pack is more complete than it is.
  • Do not imply mature connector coverage to incumbent platforms unless the workflow shown is genuinely live.
  • Do not oversell cross-study certainty if comparability still depends on context and metadata.

Quick discovery cues before answering

  • What do you use today for survey authoring, fieldwork, reporting, and repository/search?
  • Where does the pain show up most: design quality, fieldwork quality, slow reporting, duplicate work, or stakeholder trust?
  • Are you trying to replace a system, add a layer, or run a narrow pilot?
  • Who currently owns research standards and final sign-off?
  • How heavy is your security or procurement process?

Category and fit

1. What exactly is this?

  • Short answer: It is a research platform that helps insight teams design, collect, connect, and share research so isolated studies become a body of evidence the business keeps learning from.
  • Longer answer: The pitch is not "another AI feature" or "just another survey tool." The wedge is that quality and trust are built across the workflow instead of being handled as separate cleanup, separate oversight, or a weak afterthought once the report is already done. In practice, that means junior researchers can deliver work to a safer, more senior standard, senior researchers can deliver more work more quickly without sacrificing quality, and the research has a better chance of travelling beyond the debrief. Because the research stays connected inside the platform, it can also expand over time into a system of record for insight knowledge.
  • Proof hook: design-collect-connect-share lifecycle, Trust Centre, connected evidence layer.
  • Watch-out: Do not lead with the full suite vision if the buyer only needs one immediate job solved.

2. What is genuinely differentiated here?

  • Short answer: The differentiation is not just that checks exist. It is that this is a connected research platform where the review carries through into actual approved changes instead of stopping at a generic checker or a single AI feature.
  • Longer answer: The strongest platform distinction is that <un>peel runs the research lifecycle rather than only storing finished outputs or adding one isolated AI feature. Core research workflows, live quality review, and connected evidence can stay in one system, so the team can move faster without giving up control and the work can travel further after the debrief. Incumbents cover important slices of that workflow and often have stronger enterprise packaging. Research Guard is a promising deeper review mechanism, but it is an October beta target rather than the lead proof for what is generally available today.
  • Proof hook: Current elevator pitch, live core workflows, Trust Centre, and the connected evidence model.
  • Watch-out: If the buyer only values one slice, say that honestly rather than pretending the whole-platform story matters equally to everyone.

3. Who is this really for?

  • Short answer: This is built for enterprise client-side insight teams under pressure to deliver faster, prove value, and make insight travel without losing control of quality.
  • Longer answer: The strongest buyer is the in-house research or insights team inside a mid-to-large company that is being bypassed by lighter-weight tools, is struggling to keep standards consistent, and needs research to become a reusable body of evidence instead of a folder graveyard.
  • Proof hook: Audience profiles and the phase-one positioning evidence.
  • Watch-out: Do not broaden the default answer into agencies or every research buyer if the conversation does not support that.

4. How does this help without creating more bad DIY research?

  • Short answer: The insight team keeps control of standards and sign-off, while the platform gives other teams safer access to approved research and evidence.
  • Longer answer: The aim is to make the insight team stronger and more scalable, not to erase research standards. Live workflows keep quality review and human decisions visible, while connected evidence lets non-research stakeholders use what the insight team has already approved instead of running disconnected ad-hoc work. Research Guard is intended to add stronger design safeguards, but it should be presented as an October beta target, not a live control that every customer already receives.
  • Proof hook: Trust Centre, connected evidence, and the Research Guard product-maturity label.
  • Watch-out: Never imply "everyone can now do research" if the buyer is worried about bypass and standards erosion.

Stack and competitive objections

5. Do we have to rip out Qualtrics, SurveyMonkey, or Forsta?

  • Short answer: No. We can work with your existing Qualtrics studies, and the early wedge should survive without a forced rip-and-replace.
  • Longer answer: If a buyer is locked into an incumbent, position this around the missing layer: are we sure we designed the right research for the brief, captured the right context, connected that work to the rest of the team's research, and kept quality and evidence visible through the workflow? The opening move should be low-friction adoption, not a platform war. If they want to keep Qualtrics for survey execution, that can still work. If they want to use our survey workflow, the Trust Centre adds built-in quality review that helps surface poor responses while the study is still live. The strongest wedge today is review and redesign governance around the study, not a claim that every incumbent-platform bridge is already mature and turnkey.
  • Proof hook: Stack-gravity analysis and pricing model.
  • Watch-out: Do not make replacement the lead unless the buyer brings it up first, and do not imply mature connector coverage if the workflow still depends on imported study assets.

6. Why not keep our current survey platform and add a repository tool?

  • Short answer: If a buyer is going to buy a repository anyway, ours is stronger when they also want the research itself to get better, not just easier to store and search.
  • Longer answer: A generic repository tool may be fine if the buyer only wants storage, search, or light reuse. The case for this product is stronger when the team feels pain across more than one stage: not enough design reassurance up front, bad data discovered too late, reporting that is hard to reuse, and research that disappears after the deck. In that case, buying our platform instead of a standalone repository means they get the quality-improvement layer as well as the knowledge layer. It also means the repository is tuned for an insight team rather than acting like generic document storage. In Foundation, the clean story is that research run on <un>peel stays connected and reusable after the project ends. Growth adds imported external research, so platform-run studies and past work can be connected and queried together. In beta, selective external ingestion can still be supported where it is part of the agreed scope, but we should not imply that full external-plus-native cross-querying is the default Foundation package. Because the repository sits inside a broader platform, the value can expand as the platform grows in response to customer demand instead of forcing the team to keep buying and stitching together more standalone products.
  • Proof hook: Competitive review and value-prop review.
  • Watch-out: Be honest about where the wedge is strongest. This builds trust faster than pretending every buyer needs the full thesis immediately.

7. Why not just use our current vendor's AI features?

  • Short answer: Because most current vendors cover slices of the workflow, not quality and trust built across design, collection, connection, and sharing.
  • Longer answer: Qualtrics, Conjointly, Forsta, Attest, Zappi, Dovetail, Stravito, and KnowledgeHound each cover meaningful parts of the workflow, often with more mature enterprise packaging. Our platform case is the connection between running research, reviewing live quality, and making the resulting evidence reusable rather than asking the buyer to stitch those jobs together. Research Guard can deepen pre-launch review, but it is an October beta target and must not be used as proof of current general availability. If the objection is specifically about data quality, jump to Q8 for the direct comparison.
  • Proof hook: Competitive deep dive refreshed on 2026-04-18.
  • Watch-out: If the buyer only needs one of those slices, an incumbent may genuinely be enough.

8. How is Trust Centre different from Attest, Zappi, Qualtrics Response Quality, or SurveyMonkey?

  • Short answer: Most of those offers sell a quality score, a cleanup layer, or a managed quality promise. Our stronger angle is live, researcher-facing quality control while fieldwork is still running.
  • Longer answer: Attest makes quality sound like something they handle for you behind the scenes. Zappi wraps it in a quality score and supplier-governance story. Qualtrics packages Response Quality as a native filtering and cleanup layer inside the platform. Cint frames quality through a trust-and-fraud-prevention story around its marketplace. SurveyMonkey now enables response quality scrubbing by default across all surveys, so buyers on SurveyMonkey will feel like this problem is already handled. Those are serious strengths, and we should say that plainly. The Trust Centre pitch is different: it shows the team what is going wrong while the study is still live, organizes the checks across Real, Unique, and Engaged, combines question-level signals instead of relying on one blunt rule, and keeps the human reviewer in control of the hard calls. If the buyer mainly wants a simple score, a supplier-governance layer, or a fully managed cleanup promise, those vendors may sound easier. If they want a more transparent and reviewable way to control data quality while fieldwork is still running, our story is stronger.
  • Proof hook: Trust Centre data-quality competitive analysis dated 2026-04-18.
  • Watch-out: Do not claim Trust Centre already matches Qualtrics on post-field cleanup or enterprise maturity. Do not imply the system automatically removes respondents by default the way Attest does. That is their pitch, not ours. Be explicit that we add a researcher-facing review layer on top of panel supply, not the same supplier-ranking or marketplace-governance package some panel vendors sell. If SurveyMonkey's default response quality scrubbing comes up, the honest answer is that their coverage exists but is automated and opaque. Our pitch is that the researcher can see what is happening and make the calls.

9. Why not just use ChatGPT?

  • Short answer: ChatGPT can help with tasks, but it is not a governed research workflow, project record, or insight knowledge system.
  • Longer answer: Generic AI helps draft, summarize, or brainstorm. What it does not give you by default is governed workflow and evidence traceability at the project level. In our system, requests and queries can be captured and kept with the project, so the team can see what was asked, what context was used, and what work was done without relying on separate personal ChatGPT histories. That makes the work more repeatable, reviewable, and accessible over time for the whole team. The second layer is retrieval quality. Our knowledge base is tagged specifically for research insights and business topics, and in beta we can already use that structure to make retrieval more useful than generic document search as the knowledge layer matures. That means the platform is not just storing prompts. It is helping the team retrieve the right evidence from its history of insight in a governed way. Even Dovetail now explicitly answers "why not use ChatGPT?" in security and workflow terms.
  • Proof hook: Dovetail AI docs plus internal trust narrative.
  • Watch-out: Do not dismiss ChatGPT. Treat it as the new baseline alternative the buyer is already using.

Proof, trust, and workflow control

10. What proof do you have that this works?

  • Short answer: Today the strongest proof is mechanism proof, not broad named outcome proof.
  • Longer answer: We can show live workflow and mechanism proof, especially the Trust Centre's 38+ quality metrics, its Real / Unique / Engaged structure, and its human review of combined signals. Research Guard also has useful internal mechanism and test evidence, but it remains an October beta target and should be shown only as a selected preview. We do not yet have broad permissioned outcome or ROI proof, and we should say that plainly.
  • Proof hook: Live product demonstration, Trust Centre quality framework, internal Research Guard tests labelled as preview evidence, and the proof claims sheet.
  • Watch-out: Do not fake certainty. Buyers will forgive early-stage proof gaps more than they forgive inflated claims.

11. How often is the quality or confidence layer wrong?

  • Short answer: The right answer is not "never." The right answer is that flags should be explainable, reviewable, and overridable.
  • Longer answer: Researchers will ask about false positives, especially if the system flags a respondent they would have kept or challenges a slide claim a senior stakeholder already likes. The design goal is not black-box enforcement. The design goal is explainable triggers, confidence tiers, and a human-in-the-loop review process where the researcher can see the full flag picture before making a call. That matters because attention and authenticity are often best judged from combinations of signals, not from a single hard rule.
  • Proof hook: Trust Centre flagged-respondent review flow and the Real / Unique / Engaged scoring model.
  • Watch-out: Never frame the system as infallible.

12. What can the human actually override?

  • Short answer: The system should support structured review, not remove researcher judgment.
  • Longer answer: The promise is that the human is dealing with surfaced exceptions and traceable decisions instead of blind cleanup. In the Trust Centre, that means reviewing flagged respondents in the round rather than being forced into automatic disqualification off a single metric. High-confidence issues can be handled quickly, but the real value is that the borderline cases stay reviewable instead of losing good respondents to one harsh rule. The Real, Unique, and Engaged scoring gives the reviewer a structure for deciding whether someone is genuine overall. If review burden grows with study volume and creates a new bottleneck, that is a real risk to manage, not something to hand-wave away.
  • Proof hook: Trust Centre review model and pricing-model quality layer.
  • Watch-out: Do not imply every flagged case is auto-rejected. Buyers want to know where control stays with them.

13. How are answers tied back to evidence?

  • Short answer: The value is not just faster answers, but answers that can be traced back to the exact supporting documents and pages or slides behind the claim.
  • Longer answer: This should be framed as concrete claim-to-evidence traceability. The system should not just give an answer. It should help the team retrieve the underlying source material, including the exact document pages or slides that support the claim, so the evidence can be checked directly. If the business wants to know what supports a claim in a board deck, the goal is to pull up the exact supporting source rather than rely on summary language alone. That is the defensibility layer, but it should be presented as a product promise and audit-trail capability, not as a validated buyer fear. The second layer is project-level traceability: what was asked, what data came back, what was excluded, what prior work supports the conclusion, and where caveats remain. That is the difference between "AI said so" and "here is how we know."
  • Proof hook: Confidence as audit trail, connected evidence narrative.
  • Watch-out: Do not use vague "AI insight" language if the buyer is really asking about defensibility.

Product reality and operating questions

14. What is live today versus beta versus directional?

  • Short answer: Quantitative Surveys, core Discussion Groups, Guided Interviews subject to workflow confirmation, and Trust Centre form the live core. The rest must carry an explicit maturity label.
  • Longer answer: Discussion Groups V2 is in test. Insight Navigator is in controlled beta. Segment Lens is in build with an August-September target. Research Guard and Research Architect are October beta targets and may only be shown as selected previews. Access is agreed account by account, with founder-assisted delivery where required. There is no blanket `full designed product set` promise.
  • Proof hook: Beta product map and product follow-up log.
  • Watch-out: The fastest way to lose trust is to collapse "visible in beta" into "fully mature."

15. How do you make cross-study answers comparable instead of noisy?

  • Short answer: Comparable reuse depends on metadata discipline and explicit caveats, not magic.
  • Longer answer: Cross-study support only becomes trustworthy when the system can account for question wording, audience definition, timing, method, and context. The default story should be metadata discipline first, with clear caveats where comparability is limited. We should talk about evidence-aware reuse and caveated synthesis, not imply frictionless comparability across every study shape.
  • Proof hook: Comparative reuse risk analysis and pricing model for system-of-record tiers.
  • Watch-out: Do not overstate cross-study certainty before the metadata and workflow truth support it.

16. How much human review overhead does this create?

  • Short answer: The promise is both less low-value cleanup and a more structured review workflow that shows people what matters.
  • Longer answer: Buyers will want to know who reviews flagged respondents, who confirms design warnings, and how much work remains manual. The answer should be that the system is there to reduce low-value cleanup and inconsistent review, not to add a second layer of bureaucracy. It points reviewers toward the important things they should look at and walks them through the key review steps, so the human effort is focused on surfaced exceptions rather than manual chaos.
  • Proof hook: Assisted-beta delivery model and Trust Centre narrative.
  • Watch-out: If the real answer is still "high founder touch," say so for beta rather than hiding it.

17. Can this handle enterprise complexity?

  • Short answer: It can handle most complex research needs, including multi-lingual studies and traceable, reviewable ways of working. The honest caveat is that the formal enterprise security and procurement pack is still being assembled.
  • Longer answer: The right framing is not that the platform only works for simple use cases and grows into complexity later. The stronger answer is that it can already support most complex research work, including multi-lingual studies, heavier enterprise research programs, and traceable review workflows. The connected platform and quality layer are designed to keep governance, traceability, and evidence visible as complexity rises, not just when a study is small and simple. Over time, that can deepen further into a broader system of record for insight knowledge, with stronger access control and organizational reach across teams and markets. The real caveat is not research complexity. It is that the formal security documentation, procurement packaging, and legal pack are still catching up for the most procurement-heavy enterprise conversations.
  • Proof hook: Current launch narrative, audit-trail capability, and pricing-model tiers.
  • Watch-out: Do not imply enterprise-wide rollout is frictionless if the operating model is still catching up.

Commercial and pilot questions

18. What budget line does this replace?

  • Short answer: Lead with existing tool spend first, then support that case with time and rework savings.
  • Longer answer: The cleanest budget anchor is usually displaced tool spend: survey platform spend, repository spend, or adjacent ResearchOps tooling that the buyer already understands. Under that, the supporting savings come from fewer analyst hours spent on cleanup, less re-fielding, and less duplicate or corrective work. Which line matters most depends on the buyer's current stack and pain, but the first conversation should usually start with what this can replace before expanding into the operational savings it creates.
  • Proof hook: Gap analysis on displaced spend.
  • Watch-out: If we cannot identify displaced spend, the deal risks sounding optional.

19. How do pilots work?

  • Short answer: Pilot structure depends on the strategic value of the account and the level of commitment we need.
  • Longer answer: Product access follows the approved maturity map rather than a blanket suite promise. A free pilot can make sense for a strategic account only when it has strong brand or signal value, important product-learning value, and a believable paid-conversion path. Other qualified buyers should normally enter through a paid pilot or Foundation. Every engagement needs agreed users, included products, founder support, manual work, success criteria, evidence rights, an end point, and the bridge to annual pricing.
  • Proof hook: Beta product map plus onboarding and pilot workstream.
  • Watch-out: Do not present free pilots as the default offer, and do not promise identical pilot terms to every buyer.

20. How does pricing work?

  • Short answer: Starter is EUR 260 per seat per month. The connected platform starts at Foundation from EUR 1,750 per month; Growth starts at EUR 5,850; Enterprise is contact us.
  • Longer answer: Starter is for focused product use. Foundation is the normal entry point for research run on <un>peel to stay connected. Growth adds imported prior research and broader cross-method evidence reuse. Respondent and sample costs are separate unless a proposal says otherwise. The remaining founder decisions are final figures, package inclusions, usage limits, beta support, and pilot-to-annual conversion.
  • Proof hook: Pricing conversation sheet and pricing model.
  • Watch-out: Do not describe the product as simple seat-based SaaS if that is not the actual commercial logic.

21. Why buy now if the product is still evolving?

  • Short answer: Buy now if one of the live workflows solves an immediate problem and a founder-assisted beta is an acceptable way to adopt it.
  • Longer answer: The right beta customer can get value from the live core while helping shape selected controlled-beta capabilities. They should expect explicit product-maturity labels, founder-assisted usage, and evolving packaging. A buyer who needs every planned product, standardised procurement, or low-touch enterprise rollout today is a later-stage fit.
  • Proof hook: Private-beta posture across the GTM system.
  • Watch-out: This answer should qualify as much as persuade.

Trust, privacy, and procurement

22. How do you handle security, privacy, model training, and procurement review?

  • Short answer: This answer is intentionally provisional for now. Answer what is true today, and do not pretend the formal pack is finished if it is not.
  • Longer answer: Buyers will ask about data ownership, model training, PII, retention, access control, DPA path, and contracting entity. We can explain the workflow and trust posture in plain language, but the formal procurement FAQ and DPA pack are still being packaged. Until those legal materials exist, the live-call answer should stay high-level, honest, and proportionate, with clear follow-up rather than improvisation. We should revisit and tighten this section once the legal scaffold is in place. The key internal rule is that we do not imply enterprise security or procurement parity with Qualtrics-class vendors before that pack exists.
  • Proof hook: Existing trust pages, trust/legal workstream, and external market reality that enterprise buyers now expect these answers quickly.
  • Watch-out: Never imply a finished procurement pack exists if it does not.

Suggested shorter default answers for live calls

  • "We help insight teams turn isolated studies into a trusted body of evidence the business keeps learning from, with quality built in because we run the whole lifecycle rather than just storing what others produce."
  • "You should not need to rip out your current stack on day one to see value."
  • "Most quality tools either give you a score or clean the data after the fact. Trust Centre helps your team review quality while fieldwork is still live."
  • "Generic AI can help with tasks. It does not give you governed workflow, project-level traceability, and reusable research context by default."
  • "We are strongest when teams need insight to travel across the organisation and keep creating value long after the study, not just land one fast answer."
  • "We will be explicit about what is live now, what is beta, and what is still directional."
  • "If a question is really about procurement or legal diligence, we should answer what is true and follow up with the formal material rather than wing it."

Open gaps this sheet does not solve yet

  • Founder-ready sales deck
  • Golden-path demo script
  • Formal discovery guide
  • Procurement FAQ and DPA pack
  • Finalized security and procurement live-call language once the legal pack exists
  • More permissioned proof and named outcome evidence
  • Founder-approved pilot-to-paid conversion language

Update rule

Every time the same objection appears twice in real GTM reviews, update this sheet with:

  • the exact wording the buyer used
  • the best short answer
  • the proof hook that landed
  • the missing artifact or product gap if the answer was still weak