# Decision Memo — Title Check pre-booking: designing for +50% payment completions

Date: 2026-07-13 · Reference: DM-20260713-01
Author: design/product · PostHog project: BhuMe App (228843)
Companion artifact: `title-check-prebooking-mockups-v3.html` (hybrid-brand redesign)

---

## Executive summary (the brief)

- **Decision required**: How to redesign the Title Check pre-booking screen to lift paid conversion **+50%** (2.5% → ~3.75% of screen-viewers), given the levers approved (visual/content + checkout flow).
- **Urgency**: High. It's the primary paid funnel; conversion is a same-session decision, so every viewed screen not converting is lost that day.
- **Deadline**: Ship a flag-gated A/B within ~2 weeks.
- **Key stakeholders**: Rajat (product), design, mobile eng, growth/analytics.
- **Bottom line**: The +50% is **not** a "make the sample report prettier" problem. Live funnel data says two leaks own the loss, and they map 1:1 onto the two approved levers. Fix both, in one flag-gated experiment, with a real control holdout.

---

## Strategic context

### Funnel definitions (so the numbers are unambiguous)

- **"Viewed"** = `sc_screen_viewed` (Title Check).
- **"Buy"** = tapping the CTA button = `sc_cta_tapped`. Nothing else.
- **"Pay"** = report actually purchased. Authoritative signal `payment_completed_server`, **but** credit/wallet-funded orders skip Razorpay and fire `credit_funded_purchase` instead — so `payment_completed_server` alone *undercounts*. The honest primary metric is "got the report" = Razorpay success **OR** credit-funded.
- Between Buy and Pay, the chain is instrumented: `document_ordered` → `payment_initiated` → Razorpay sheet → `payment_completed`/`payment_abandoned`/`payment_failed` (or `credit_funded_purchase`). We can already attribute the Buy→Pay drop across these.

### Current situation (live funnel — Title Check)

Verified on two cohorts (60-day all-users, and last-14-day joiners). The pattern is stable:

| Step | 60-day | 14-day joiners | Read |
|---|---:|---:|---|
| Viewed (`sc_screen_viewed`) | 31,196 | 4,392 | |
| Tapped Buy (`sc_cta_tapped`) | 4,706 (15.1%) | 739 (16.8%) | **Leak #1 — ~83–85% never tap Buy** |
| Paid (`payment_completed_server`) | 784 (2.5%) | 104 (2.37%) | Buy→Pay ≈ 14% completes |

Path split (14-day joiners), testing whether the khata modal itself hurts:

| Path | Reached | Paid | Rate |
|---|---:|---:|---:|
| Khata prompt (already has a plot) | 386 | 52 | **13.5%** |
| Create Request Sheet (no plot) | 363 | 55 | **15.2%** |

Two facts do the work:

1. **Leak #1 — interest → intent (dominant).** ~83–85% of viewers never tap Buy — the largest pool by an order of magnitude. This is the content/trust/value lever. It does **not** depend on the handoff's "more sample sections → more conversion" claim (correlational/self-selected — engagers are high-intent to begin with).
2. **Leak #2 — Buy → Pay completion (~86% lost, on *both* paths).** Of everyone who taps Buy, only ~14% end up with the report — and the khata-prompt path (13.5%) and the no-plot path (15.2%) convert **the same**. So the drop is *checkout completion* (Razorpay handoff, ₹999 price at the moment of pay, plus friction steps), **not** the khata modal specifically.

**Correction (intellectual humility):** an earlier read that "the khata path converts ~½ the other path" was a **60-day cohort confound** — the fresh-cohort path-split disconfirms it. Removing the khata modal will **not** ~2× conversion.

**But the khata prompt is still a real, cheap defect (your call-out):** users who reach it arrived *with a plot* — from map discovery, a nudge, saved, or a deep link — and those plots **already carry the khata**. Code: plots are keyed by `survey_no + khata_no` and the card even displays it (`PlotCardSheet.js:109-110, 325-326, 600`); saved/deeplink/nudge all pass it (`SavedScreen.js:135`, `deepLinkHandler.js:74`, `titleRiskNudgeHandler.js:63`); the screen reads it (`ServiceCheckScreen.js:400`). Yet the prompt **blanks it and re-asks** (`ServiceCheckScreen.js:595` `setKhataInput('')`). So for its entire audience we ask for a number the app already has. Fix = pre-fill or skip when khata is known; worst case neutral, and it removes a pointless step.

### Opportunity assessment

- **Leverage**: We already have the winning `copy_and_layout` direction shipped (`InlineReportCards`), a working sample-report/PDF pipeline, brand tokens, and the analytics to measure both leaks.
- **Force multiplier**: The two leaks are additive. Modest wins on each compound past +50% (see math below), so we don't need a heroic single lever.
- **The +50% math (margin of safety built in)**: Baseline ~2.5% (higher once credit-funded pays are counted).
  - **Leak #1 carries most of it**: view→Buy 15–17% → ~22% (a ~+30% lift on the *worst*, largest step) from a trust-first, findings-led hero. This alone gets close to +50% overall.
  - **Leak #2 tops it up**: Buy→Pay ~14% → ~18% by improving price/trust framing at the moment of pay and removing friction steps (incl. the redundant khata ask). Do **not** model this as a 2× khata win — that was disconfirmed.
  - Combined clears **+50%** with the heavy lifting on Leak #1, so the target survives Leak #2 underperforming.

---

## Decision framework

### Options

**Option A — Content/trust redesign only (attack Leak #1).**
Rebuild the screen findings-first: clear "SAMPLE report" label, a clearance summary up top, counts-first cards *open above the fold* (kill the collapse/navigate-away), mutations-led hook + honest encumbrance risk framing, CTA above the fold and sticky.
- Pros: Hits the largest pool (85%); pure client change; low risk; on-brand.
- Cons: Leaves the checkout tax in place — caps the ceiling. Section-engagement upside is unproven.
- Effort: ~1 week design+build. Risk: Low. Reversible: Yes (flag).

**Option B — Checkout completion only (attack Leak #2).**
Improve the whole Buy→Pay step: pre-fill/skip khata when it's already known (map/nudge/saved/deeplink all carry it); present price/trust better at the moment of pay; smooth the Razorpay handoff. First read the existing `payment_initiated`/`payment_abandoned`/`payment_failed` events to see whether the drop is *never-opened-Razorpay* vs *abandoned-in-sheet* vs *price shock*, then target it.
- Pros: Cheap; touches the most motivated cohort (already tapped Buy).
- Cons: Only ~14–17% of viewers reach here, so bounded absolute lift on its own; the khata fix alone is ~neutral (path parity), so most of the win must come from price/trust/Razorpay, not the modal.
- Effort: ~3–5 days. Risk: Low. Reversible: Yes.

**Option C — Both, shipped as one flag-gated A/B with a real control holdout (recommended).**
The hybrid-brand findings-first redesign **and** the checkout streamline together.
- Pros: Only option that plausibly clears +50%; leaks are independent so effects add; one experiment.
- Cons: Two changes in one variant blur attribution. Mitigation: instrument each step so we can read view→Buy and Buy→Pay *separately* even within one arm; optionally a 3-arm split (control / redesign-only / redesign+checkout) if traffic allows.
- Effort: ~1.5–2 weeks. Risk: Low–Med. Reversible: Yes (flag).

### Evaluation criteria

| Criterion | A | B | C |
|---|---|---|---|
| Expected lift toward +50% | Partial | Partial | **Full** |
| Confidence of a positive effect | Med | **High** | High |
| Build cost | Med | **Low** | Med |
| Attribution cleanliness | High | High | Med (mitigated) |
| Brand risk | Low | None | Low |
| Reversibility | Flag | Flag | Flag |

---

## Recommendation

**Adopt Option C**: ship the hybrid-brand, findings-first redesign **plus** the checkout streamline, behind a flag, with a **real control holdout** (the last experiment had a ~2% control — fix that).

### Rationale
- The data localizes the loss to two independent leaks; C is the only option that addresses both, and the +50% math needs both.
- Brand direction is **Hybrid** (decided): BhuMe tokens `#2D2B3B` + `#51B67A`, system fonts — *keep* the mockup's clearance meter, counts-first cards, and document-grade texture; *drop* parchment and serif. Stays consistent with the app while reading as an official land record.
- Honesty guardrail holds: it's a **sample** report — label it as such on every screen; every persuasion element (loss aversion, social proof) must be truthful (fraud-anxiety audience punishes dark patterns).

### Critical success factors
- **Separate instrumentation per step** (see action items) so we can attribute the two leaks independently inside one arm.
- A real control holdout and whole-arm conversion as the judged metric (not engagers-only — that ratio is a selection artifact).

---

## Risk assessment (pre-mortem + inversion)

**Imagine it's 8 weeks out and conversion did *not* move. Why?**
1. *We polished the sample report and the 85% still bounced.* → The bounce is about **relevance/trust in the first 2 seconds**, not card aesthetics. Mitigation: lead with the plot identity + a concrete finding + honest risk above the fold; treat "SAMPLE" labeling as trust, not a disclaimer to bury.
2. *Removing the khata modal cannibalized report quality (wrong khata → refunds).* → Make khata a clearly-optional inline field with a "we'll scope it in your report / contact you" fallback; monitor refund/dispute rate as a guardrail metric.
3. *We claimed a section-engagement causal win that wasn't there.* → Do **not** bank on it; judge on whole-arm paid conversion. Section engagement stays a secondary/leading indicator only.
4. *Two changes in one arm — we can't tell what worked, and can't iterate.* → Per-step events + optional 3-arm split.
5. *iOS quirk skews it.* → ~99% Android; keep the iOS Razorpay/anti-steering paths untouched.

**Inversion — what would guarantee failure?** Shipping more content without touching checkout; burying the CTA below the fold; hiding that it's a sample; running without a control again. Avoid all four.

## Bias check (Munger)
- **Social-proof / availability**: The "sections → 4–9× conversion" stat is vivid and available, tempting us to over-invest there. It's correlational. Antidote: target the *whole-arm* funnel leaks, not the engager subgroup.
- **Overconfidence**: +50% is a big claim. Antidote: margin of safety in the math (clears +50% even if one lever underperforms) and a control holdout to keep us honest.
- **Doubt-avoidance / commitment**: We already built `InlineReportCards`, so there's pull to just reskin it. Antidote: the data says the modal and the fold matter more than the grid — follow the data.
- **Reason-respecting (used *on* the user, ethically)**: give the buyer a truthful reason each check matters; never a fabricated one.

## Reversibility
Fully reversible — everything ships behind `tc_angle_variant` (or a fresh flag). No irreversible/outward-facing commitment.

---

## Action items

### Immediate (this week)
- [ ] Read the *existing* Buy→Pay events (`document_ordered` → `payment_initiated` → `payment_completed`/`payment_abandoned`/`payment_failed`, plus `credit_funded_purchase`) to split the ~86% drop into never-opened-Razorpay vs abandoned-in-sheet vs failed vs price-shock — analytics. (No new instrumentation needed here; a clean `razorpay_opened` is nice-to-have.)
- [ ] Redefine "conversion" to include credit-funded pays (Razorpay success **OR** `credit_funded_purchase`); `payment_completed_server` alone undercounts — analytics.
- [ ] Add the one genuinely-missing event: real `sc_sample_section_impression` (viewport-enter + scroll depth) to diagnose the below-fold portion of Leak #1 — eng.
- [ ] Pre-fill/skip the khata prompt when `plotDetails.khata_number` is already present (`ServiceCheckScreen.js:595`) — eng. Small, safe.
- [ ] Finalize hybrid-brand redesign from `title-check-prebooking-mockups-v3.html` — design.

### Short-term (1–2 weeks)
- [ ] Build the redesign behind a flag with a **real control holdout**; wire whole-arm paid conversion as primary metric, refund/dispute as guardrail — eng.
- [ ] Decide 2-arm (control / redesign+checkout) vs 3-arm (isolate checkout) based on available traffic — product+analytics.

### Long-term (2+ weeks)
- [ ] Read results on whole-arm `payment_completed_server`; ship the winner; retire `FORCE_INLINE_LAYOUT`.
- [ ] Only if section-impression data now shows a *causal* below-fold problem, iterate on card order/placement.

---

## Appendix — key data points & queries
- Funnel numbers: HogQL over `events`, project 228843, last 60 days, filtered to Title Check (`service_type`/`document_type='Title_check'`; khata events are Title-Check-only).
- Payment casing: server `payment_completed_server` + `document_type='Title_check'` is authoritative.
- Prior learnings: `HANDOFF-title-check-prebooking.md` (redesign wins; same-session decision; section engagement correlational; ~99% Android; honesty guardrail).
- Saved insights: paid-conversion-by-variant `NbpZ1yMj`; section→payment funnel `JJcOtcfz` (TEMP).