Refund Pilot
Product concept and two funnel variations
Product review draft · Updated 25 October 2026
Lean test summary
Big idea: Start with a support chat for the exact refund or cancellation the visitor needs. Introduce MoneyPilot after understanding the request.
Customer context: The team reports cheaper Google Ads clicks for branded refund terms but low conversion. The working explanation is that customers expect help with a specific company, while the existing journey introduces a broader service. Actual CPC and conversion baselines still need to be added.
Hypothesis: Addressing the specific request in chat will increase paid customers per ad visitor. Compare free help before signup with trial signup before the first assistance step.
Success metric: Paid customers per eligible Google Ads visitor and cost per paid customer. Check retention, service cost, complaints and real case outcomes. Agree on the improvement threshold and test window before launch.
MVP variations: A gives initial free guidance, then offers savings and signup. B asks for trial signup, then starts the first case and introduces the full service near connection. Both use the same initial conversation.
Use the test plan and review checklist on the site to try each version. The sections below are supporting details.
1. The idea
Refund Pilot is a MoneyPilot product that meets a customer at a specific moment: they want to cancel a subscription, request a refund, or resolve an unwanted recurring charge from a named company. Google Search supplies the initial intent. A conversational landing page helps them explain the problem and understand the appropriate next action. The conversation then introduces MoneyPilot as a broader way to manage subscriptions and identify additional savings.
The acquisition hypothesis is that a useful, specific support experience can earn enough trust to turn immediate cancellation demand into interest in a continuing subscription management service. This is a hypothesis to validate, rather than a proven improvement over the existing MoneyPilot funnels.
The product combines three elements: brand specific acquisition, support style chat, and a deliberate transition into MoneyPilot. Refund Pilot should be clearly identified throughout as an independent MoneyPilot service. The conversation can be warm and practical while explicitly identifying the assistant as AI.
2. What is decided and what remains proposed
Confirmed direction
- Refund Pilot is an acquisition entry point for MoneyPilot.
- Initial traffic comes from Google Search with cancellation or refund intent.
- The landing page is led by chat, inspired by the interaction pattern reviewed on JustAnswer.
- The landing header uses MoneyPilot branding only. Henry is identified inside the chat as an AI assistant powered by MoneyPilot.
- The assistant confirms cancellation or refund intent, asks for the company or product through free text, gathers the relevant situation and asks the reason for cancellation.
- The broader savings offer appears within the same conversation.
- The next major navigation is to a dedicated signup page.
- Useful supporting content sits below the initial chat experience and remains available through ordinary scrolling.
- One shared site contains two distinct, shareable variation paths.
Prototype assumptions
- The first supported case receives free guidance and a prepared next step. Universal automatic cancellation is not assumed.
- Variation B models a seven day free trial with no card and no automatic billing. These terms require a product decision.
- The price and entitlements of the full service are undecided. The prototype shows a plan review rather than a real purchase.
- Signup, case submission, email connection, bank connection and financial results are simulated.
- The example scan uses fictional subscriptions and charges. It does not inspect a visitor's email or banking information.
- Session progress is stored only in the browser for the interactive demonstration. There is no shared reviewer database.
Open decisions
Launch country, launch brands, supported billing routes, the operational cancellation method, refund eligibility rules, trial entitlements, paid price, connection providers, data scope, retention, consent wording and actual service times must be agreed before launch.
3. Customer intent and product promise
The primary customer has a concrete task, rather than a general desire to assess their financial habits. They may want to stop a renewal, cancel an unused product, challenge a charge, request a refund, or find a cancellation route after an unsuccessful attempt.
Their immediate questions are: Can you help with this company? What do I need to do? Are you the company itself? Will this cost me anything? Is my subscription actually cancelled? The first screen and conversation should address these questions progressively.
The initial promise is help with a named cancellation or refund request. A savings estimate, a paid subscription and a broader financial scan are subsequent opportunities. They must not erase or change the status of the original request.
Cancellation, savings and refund are different outcomes:
| Outcome | Meaning | Appropriate evidence |
|---|---|---|
| Cancellation guidance | Relevant steps have been provided | Route and instructions shown |
| Request prepared | Details or a message are ready for the customer or service to submit | Draft request and next step available |
| Request submitted | A request has actually been sent with authorization | Submission record and timestamp |
| Cancellation confirmed | The billing provider confirms cancellation or no renewal | Provider confirmation or equivalent evidence |
| Potential savings | Future spending that could be avoided if an action succeeds | Charge amount, frequency, assumptions and action |
| Refund requested | A refund claim has been submitted | Submission record |
| Refund received | Money has actually been returned | Confirmed payment or transaction evidence |
These states should be visible in the case summary and persist through signup and the broader MoneyPilot journey.
4. Acquisition and landing page personalization
Use Google Ads ValueTrack parameters to pass the matched account keyword, for example through a final URL suffix containing utm_term={keyword}. This is the keyword from the advertiser's account that matched the search, not necessarily the user's exact search query. Keywordless traffic may produce an empty value. The implementation must have a neutral fallback.
Map keyword context to a small set of safe intent categories: cancellation, refund, both or unknown. Do not insert raw URL text into the page as HTML. The first question should ask the visitor to confirm the inferred intent. Free text must remain available so they can correct it.
The company or product remains an explicit free text question, even when the keyword suggests a brand. This creates an opportunity to correct broad match ambiguity, distinguish a product from its parent company and identify the actual billing provider.
Relevant supporting content can explain cancellation routes, billing through an app store, refund requests, the service process, costs and FAQs. It should be useful to visitors and visibly accessible. Keyword stuffing, invisible text and unsupported claims are not part of the concept. Supporting content may improve message alignment; no specific Google Ads relevance or Quality Score improvement is assumed.
5. Shared conversation before the experiment branches
Ask one question at a time. The first several steps should be consistent across both variants so the test isolates the sequencing of signup and monetization.
| Step | Purpose | Example assistant behavior |
|---|---|---|
| Intent confirmation | Confirm rather than assume | Are you looking for help cancelling a subscription, requesting a refund, or both? |
| Company or product | Establish the target | Which company or subscription do you need help with? |
| Billing route | Identify the party that controls billing | Did you subscribe directly, through an app store, or somewhere else? |
| Situation | Gather action relevant context | What happened, and have you already tried to cancel or request a refund? |
| Reason | Understand the need and tailor the later bridge | What is the main reason you want to cancel? |
| Charge amount | Support a transparent estimate where useful | What do you pay each month? You can skip this. |
| Summary | Check understanding and preserve trust | Here is what I understood. Is anything missing? |
The questions should adapt. A cancellation case needs renewal and billing route information; a refund case may need the charge date, reason for refund and any prior contact. The prototype captures these in a situation field. A production system should ask targeted follow ups only when they change the next action.
Do not ask for passwords, bank credentials or payment information in chat. A connection, if offered later, belongs in a dedicated provider consent experience. Requests that require a human, a verified policy check or unsupported provider access should be routed honestly.
6. Variation A: Free assistance first
Hypothesis: Providing a useful cancellation next step before asking for signup increases trust and improves qualified scan adoption and retained paid conversion.
Journey: support chat → initial free assistance → optional broader savings offer → signup → optional email or bank connection → findings → full service offer.
After the customer confirms the case summary, the assistant provides a useful action plan. For a guided case, this can be the correct billing route and a prepared cancellation message. For an operationally supported case, it may be a submitted request after the required authorization. The prototype demonstrates preparation only and labels it accurately.
The customer can access their free next step without accepting a broader scan. Declining the savings offer should preserve the case summary and guidance. This makes the initial offer concrete and avoids making the later offer a condition of help already promised.
The transition reflects the reason for cancellation. A cost concern leads naturally to reviewing other recurring charges. Low usage leads to finding forgotten subscriptions. An unexpected charge leads to reviewing recurring payments and renewal alerts.
Suggested transition: Your cancellation steps are ready. Would you also like MoneyPilot to help you check for other subscriptions you may no longer need?
Accepting leads to signup. The page should explain why an account is useful: retaining the request, accessing the broader review and following progress. Carry the chat context forward. Following signup, explain the scope of any email or bank connection and allow users to skip it.
7. Variation B: Trial signup first
Hypothesis: Giving signup an immediate purpose, starting a cancellation case during a trial, produces more activated accounts and eventually more retained paid customers.
Journey: support chat → trial invitation → signup → initial cancellation assistance → full service introduction alongside optional connection → findings → paid upgrade decision.
After the shared conversation, the assistant summarizes the request and offers an account to begin the first supported case during a trial. The trial invitation must specify what the customer receives. Signup should preserve the request without falsely suggesting that the provider has already cancelled the subscription.
The prototype assumes seven days free, no card and no automatic billing. These are scenario assumptions, not established MoneyPilot terms. The product team can change them after deciding the commercial model. If a future trial automatically converts to paid service, the user must understand its price, billing date and cancellation terms before accepting it.
After signup, show the original case and a useful assistance milestone before expanding the offer. Introduce the full service near the email or bank connection step: it can help review additional recurring charges, organize subscription decisions and track supported cases.
The choice to connect data and the choice to pay remain distinct. Explain whether scanning is included in the trial, which features require the full plan, and what happens if the user declines either option. In the prototype, previewing sample findings is available without paying and no real connection is made.
8. How the experiment stays interpretable
There is one experiment with two funnel variants. The shared entry page, assistant identity, early question order, traffic targeting and first case scope should be held as consistent as possible. The treatment is the sequence and framing of free assistance, signup and the full service offer. This compares complete journeys; it does not isolate a single button or one wording change.
Assign visitors to a variant at entry and preserve that assignment across navigation and return visits. Explicit review links should override assignment only in a test environment. A production experiment needs a defined eligible visitor population, bot and internal traffic filtering, device and brand segments, and an attribution window agreed before launch.
The prototype has direct paths for review and deliberately does not implement real experiment allocation, advertising tags, billing or account creation.
9. Signup and context handoff
Signup is a dedicated page after chat. It should retain the confirmed company, intent, billing route, cancellation reason, situation and case status. Ask only for information required to create the account and provide the service. Explain the offer attached to that signup.
The prototype uses a prefilled fictional reviewer account and a clearly labeled simulated signup button. It never transmits entered account details to MoneyPilot. Production signup needs the actual account service, authentication, consent handling, abuse prevention, errors and recovery.
Returning from signup must preserve the case and route the visitor to the correct next step for their assigned variation. A duplicate account should enter the existing account flow without losing the request.
10. Scan, findings and full service
A real scan must have a real source. Before connection, explain what data is requested, what will be examined, how it will be used, and whether scanning email or banking data is sufficient for the supported workflow. Do not assume that both are needed.
The prototype lets reviewers simulate either source. It does not open OAuth, Plaid or an authentication window and does not request credentials. All resulting merchants, amounts and flags are sample data.
Findings should identify recurring charges and ask the user which subscriptions they no longer need. A recurring charge is not automatically waste. Potential savings should be calculated from selected actions and stated assumptions, exclude the subscription already being handled, and show gross avoided charges separately from the MoneyPilot fee. Money returned through refunds should have its own status.
The prototype uses two fictional monthly recurring charges of $12 and $8. If the reviewer marks both as unwanted, the illustrative gross annual avoidable spend is $240, assuming the charges remain unchanged and both cancellations succeed. This is neither a refund nor a verified prediction. Actual MoneyPilot pricing is undecided, so the prototype does not claim net savings.
The full service offer should state its real capabilities, price, renewal schedule and cancellation method. This review prototype shows proposed capabilities and a plan interest action, with pricing pending. No purchase occurs.
11. Mobile interaction model
The chat is the primary first screen. The landing header contains the MoneyPilot logo only. At the top of the chat, Henry is labeled as an AI assistant powered by MoneyPilot. There is no separate headline above the welcome. A short greeting and compact trust signal keep the initial screen focused. It must not imply that the customer is speaking to the subscription company or a human agent. Avoid invented expert profiles, availability counters, ratings or social proof.
Use the initial viewport to focus attention on the conversation. Supporting sections remain below it and accessible by scrolling. Keep the chat in a bounded window with a stable composer. The transcript scrolls within that window; a Review chat control opens the full conversation in a separate reader. Supporting page content remains below the chat and can be reached with an explicit How it works link. Keep scroll ownership clear and respect the software keyboard and safe area.
When the visitor scrolls beyond the chat, display a compact return to conversation control. Expanding it returns to the existing conversation and draft. It must not reset messages or jump unpredictably during keyboard opening. New messages must not steal the scroll position if the visitor is reviewing earlier messages. Show a Latest reply control instead. Keep draft text through replies, review and page reload. Enter sends on desktop, Shift+Enter creates a new line, and the phone keyboard keeps Enter available for a new line.
The product review hub includes a phone sized frame that exercises the responsive CSS and an actual full page link. The frame is a preview, not a substitute for testing software keyboards on real Android and iOS devices.
12. Supporting content below the chat
Supporting content explains the three steps: understand the case, prepare the appropriate request, and follow the status. It also explains the distinction between cancelling and receiving a refund, how direct billing differs from app store billing, the free offer, the optional full service and the identity of Refund Pilot.
Content should remain relevant to the confirmed brand where verified routes and policies exist. The prototype does not invent universal brand cancellation instructions; it offers general preparation steps and makes policy verification an operational requirement.
Real social proof can be added after its source, population, period and outcome definition are verified. Report cancellations confirmed, refund requests initiated and money actually recovered separately. No customer counts, testimonials or dollar totals are invented for this concept.
13. Measurement and economics
Primary commercial outcome: retained paid customers per eligible acquired visitor, evaluated over a predeclared window long enough to observe at least the first renewal. Trial signup alone is not the winning metric.
Primary service outcome: the proportion of visitors reaching a useful first case milestone, with prepared, submitted and confirmed counted separately.
| Metric | Definition and purpose |
|---|---|
| Chat start rate | Visitors who submit their first response divided by eligible visitors |
| Case qualification | Visitors who confirm a usable request summary divided by eligible visitors |
| Assistance milestone | Prepared, submitted and confirmed cases, reported separately |
| Signup conversion | Completed accounts divided by eligible visitors, plus conversion from the signup page |
| Connection completion | Successful authorized connections divided by connection offers |
| Scan activation | Visitors who receive usable findings divided by scan starts |
| Paid conversion | First paid subscriptions divided by eligible visitors |
| Retained conversion | Paying customers still active at the agreed renewal checkpoint divided by eligible visitors |
| Cost to serve | Human support time, provider fees and service cost per case and per retained customer |
| Trust guardrails | Complaints, mistaken brand identity, unexpected billing reports, failed cancellations and early churn |
Evaluate by brand, intent, billing route, device and campaign segment. Investigate mismatches such as many signups but few completed connections, or high initial sales followed by churn. Avoid declaring a winner from small early differences.
Retained customer acquisition cost equals media spend divided by retained paid customers. Contribution should subtract payment and data provider fees, assisted cancellation cost and ongoing support cost. Compare the free first case cost and retained contribution across the two variants. Exact sample size, minimum detectable effect, test duration and decision thresholds require baseline conversion data and should be set before launch.
14. Proposed events
Events: landing_view, intent_confirmed, brand_provided, billing_route_selected, situation_provided, reason_selected, amount_provided, case_summary_confirmed, assistance_prepared, savings_offer_viewed, savings_offer_accepted, trial_offer_viewed, signup_started, signup_completed, connection_offer_viewed, connection_started, connection_completed, connection_skipped, scan_completed, opportunity_selected, plan_viewed, paid_started, renewal_retained and case_status_changed.
Common properties: experiment ID, assigned variant, anonymous journey ID, step, intent, normalized supported brand ID, billing route category, device class, campaign IDs and case status. Do not place raw chat text, email addresses, banking details, credentials or sensitive charge descriptions in analytics payloads. Keep operational case data separate from advertising measurement.
The prototype exposes a local review event log for checking navigation and branches. It is not a production analytics implementation and contains no real customer information.
15. MVP scope and launch dependencies
Start with a small set of brands and billing routes for which the team can verify an effective assistance method. The exact brands remain undecided. Build a maintained source of cancellation routes and refund policies with a verification date and an owner. Use AI to interpret a case and assemble a conversation, with reliable rules for actions and status changes.
MVP capabilities: intent aware greeting, free text brand capture, adaptive support questions, editable summary, accurate case statuses, context preserving signup, two distinct journey sequences, optional connection explanation, evidence based findings, clear plan presentation and end to end measurement.
Before real launch: implement account creation, verified provider integrations, action authorization, connection security and permissions, billing and trial entitlements, exception handling, service operations, customer support and real device QA. A chatbot front end alone cannot guarantee cancellation or refunds.
16. Product decisions for review
- What exact outcome is included free for each supported brand?
- Which brands and billing routes launch first?
- Is the trial time limited, case limited, or both?
- Is a card required, and does a trial ever convert automatically?
- What does the paid plan add after the first case?
- Which connection is necessary for the intended scan, and can users choose either source?
- What actions can the service perform directly and which remain guided?
- How is a successful cancellation or received refund verified?
- What baseline metrics and support costs determine the experiment design?
- Which market and audience are eligible?
17. Review walkthrough
Open Variation A and finish the support conversation using a sample subscription. Review the free action plan, accept or decline the broader offer, then simulate signup, a connection, findings and the plan review. Restart to test a refund or combined intent.
Open Variation B with the same sample inputs. Observe how the signup invitation arrives before the free assistance milestone, then review the trial case and the full service offer at connection. Decline the connection to ensure the original case remains accessible.
Use the phone preview to check narrow layouts, scrolling, the composer and the compact return control. Open a demo directly on a real phone to test the keyboard. Review the comparison page for the differences, measurement plan and unresolved decisions.
Sources and grounding
- User supplied product concept and subsequent decisions in this conversation, 25 October 2026.
- User supplied mobile recording of the JustAnswer interaction pattern, reviewed in this conversation. The concept uses the interaction pattern, not JustAnswer identity or claims.
- MoneyPilot pages and funnel steps observed in this conversation: https://www.moneypilot.com/subscriptions and https://www.moneypilot.com/subscription-management/v2/0
- Google Ads ValueTrack documentation: https://support.google.com/google-ads/answer/6305348?hl=en
- Google Ads misleading representation: https://support.google.com/adspolicy/answer/15936666?hl=en
- Google Ads misrepresentation and pricing transparency: https://support.google.com/adspolicy/answer/6020955?hl=en
This document separates the agreed concept, prototype assumptions, recommended implementation and decisions still needed. Performance improvements, operational capabilities and commercial terms remain unvalidated until tested.
Mobile landing update
Use a short greeting below 70 characters. The default is: Hi, I'm Henry. Need help canceling a subscription? Refund and combined intent have equally short versions. Henry is fifth in the SSA list for US boy births in 2025: https://www.ssa.gov/OACT/babynames/ This ranking is for newborns, not all adult men.
The initial mobile screen contains a MoneyPilot logo header, the illustrated assistant, the published platform member count, a brief welcome, two intent replies and the composer. Reviewer tools are kept outside the initial mobile screen. The count of 150,000+ MoneyPilot members is sourced to the current subscriptions page and is a first party platform claim, not proof of cancellation or refund outcomes. No rating or testimonial is invented.
Chat layout and supporting visuals
The initial mobile screen has no extra headline. Size the chat to the smallest available viewport measure, subtract the measured logo header and leave 20 pixels of clearance. Recalculate on viewport resize, keyboard changes and page restoration so the composer remains visible without scrolling. Real device keyboard testing is still needed.
An illustrated AI avatar and an original subscription management illustration are included as optimized website assets. Supporting content uses short topic cards, three interactive process panels and a compact FAQ. Long prototype notes sit in an expandable section.