# Teleton Rifa: UX, Conversion, and Landing Design Plan ## Summary This is the experience-design layer for the Teleton Peru raffle web app: a mobile-first, single-flow landing plus a registration-and-upsell purchase journey optimized for impulse micro-purchases coming from Instagram, TikTok, and lives. The design serves two motivational segments in one funnel (22 to 38 who want to win, 35 to 50 who want to support) by leading with the dual promise "tu ayuda tambien te ayuda a ti" and pairing every prize with a visible impact line. Trust, fairness, accessibility (WCAG 2.1 AA as a launch gate given Teleton's mission), and honest pricing math are treated as conversion drivers, not afterthoughts, because the upsell is also the payment-fee-survival mechanism and the charity reputation is on the line. The upsell is explicitly designed to be honest and non-dark-pattern (one tap declines, no pre-checked boxes, no fake scarcity), and Yape is positioned as the primary mobile rail to escape the S/3.50 fixed-fee cliff on small tickets. All Spanish microcopy is provided in Peruvian register with no em-dashes, no emojis, and no voseo. ## Body ## 0. Design principles that govern every screen These six principles resolve tension before it reaches a specific screen. When a layout decision is unclear later, decide in this order. 1. **One funnel, two motivations.** The audio asks for two audiences (22 to 38 prize-driven, 35 to 50 cause-driven) but never asks for two flows. Serve both in a single flow by always showing the prize and the impact together. The hero promise "tu ayuda tambien te ayuda a ti" is literally the union of the two motives, so it is the spine of the whole page. `[inferred]` that one flow is correct; grounded in the brief stating the segments are "a messaging concern, handled with copy and creative, not separate flows." 2. **The upsell is honest by construction, not by disclaimer.** Because this is a national charity, the upsell must convert without a single dark pattern. Concretely: declining is one tap and visually equal to accepting, nothing is pre-selected, there is no fake countdown on the upsell itself, and the odds language never implies a win is likely. Trust is the conversion strategy here, not a tax on it. 3. **Show the math, always.** Price per chance, total chances, total to pay, and the honest odds framing ("mas chances, mas posibilidades, nunca garantizado") are visible at every money moment. This is both a conversion lever (clarity reduces abandonment) and a legal posture (no misleading promotion per INDECOPI). 4. **Mobile-first means thumb-first and webview-proof.** Single column, large tap targets, numeric keypads, and a payment step verified inside the Instagram and TikTok in-app browsers, because that is where the traffic originates. A flow that breaks in an in-app webview is a flow that does not exist for this audience. 5. **Accessibility is the brand.** A Teleton experience that excludes people with disabilities is a brand contradiction. WCAG 2.1 AA is a launch gate. This is the highest-leverage reputational requirement in the whole build. 6. **State drives the UI, prizes are data.** Prizes are "sujeto a lo que las empresas nos puedan dar," so the landing renders prize cards from a list with explicit "por confirmar" states. The countdown, the entries counter, the prize set, and the pricing are all event configuration, so the same page runs the August warm-up and the September main raffle. A note on the playful tone: warmth and light comedy live in the copy voice and the micro-interactions, never in the money math, the legal links, or the impact statements about children. The rule of thumb is playful invitation, serious promise. --- ## 1. The landing page, section by section Mobile layout is a single scrolling column. Every section is full-width with generous vertical padding. A persistent bottom action bar (described in 1.11) keeps the primary CTA one thumb-reach away at all times, which is the single biggest conversion lever on a long mobile landing. ### 1.1 Top bar (persistent, minimal) - Left: Teleton official logo (links to teleton.pe in a new tab, labeled so a screen reader announces "Teleton, sitio oficial, abre en nueva pestana"). - Right: a small "rifa oficial Teleton" lockup so the page reads as legitimate the instant it loads from a social link. First-load legitimacy matters more here than on a normal site, because users arrive cold from an influencer post and are about to pay. - The bar is short and does not collapse the hero. No hamburger menu is needed; this is a single-purpose landing, so navigation is a few in-page anchors at most. ### 1.2 Hero (the core promise) The hero must do four jobs above the fold on a phone: state the promise, make it feel like Teleton, make it feel playful, and put the primary CTA within thumb reach. - **Headline:** the core promise "Tu ayuda tambien te ayuda a ti" as the H1. This is the union of both audiences and is the only headline candidate that satisfies the brief verbatim. - **Subhead:** one line that names the mechanic and the cause in plain Peruvian Spanish (copy in Section 5). - **Primary CTA button:** "Quiero participar" leading to the registration flow. Large, high-contrast, full-width on mobile. - **Secondary, lower-weight line under the CTA:** the price anchor and the chance unit, for example "Desde S/ [base] por una chance." This sets the expectation before the user taps so the payment step is not a surprise. The exact number stays a token until pricing is resolved (Section 6 decision 1). - **Trust strip directly under the hero CTA:** a single quiet row with the Teleton logo, "Pago seguro," and "Sorteo supervisado." Putting a micro trust signal in the hero, not only the footer, raises the odds a cold social visitor proceeds. - **Visual:** a warm, modern hero image or short looped motion that honors the cause (children and people Teleton serves) without being saccharine. Motion must respect reduced-motion (Section 3). `[inferred]` exact art direction; the brand assets are not in the repo. - **The countdown** can appear as a compact element in or just below the hero on the main-raffle event, since the September 12 date is fixed and urgency is a stated goal. For the warm-up (date is "finales de agosto," not exact), show "finales de agosto" until the exact date is set, and switch to a live countdown once confirmed (Section 6 decision 5). ### 1.3 How it works (3 steps) A three-step row, icon plus short label plus one line each, mirroring Rodrigo's own three-step description ("se inscribe, plataforma de pago, confirmacion al correo"). Keep it scannable in under five seconds. 1. **Inscribete.** Tu nombre, tu celular y tu correo. Listo en segundos. 2. **Elige tus chances.** Una o las que quieras. Mientras mas chances, mas posibilidades. 3. **Paga seguro y participa.** Te llega la confirmacion a tu correo y ya estas adentro. Design notes: numbered, semantic ordered list under the hood for screen readers. Icons are decorative (aria-hidden) with the meaning carried in text. On mobile this is a vertical stack, not a cramped three-across row, so the tap-free reading stays comfortable. ### 1.4 Prizes (data-driven, with explicit pending states) The most clickable section for the 22 to 38 segment. Render as cards from a prize list, never hardcoded. - Each card: prize image, prize name, the donating brand (when public), and an estimated value line if Teleton chooses to show valuations (note: valuations are legally required in the bases regardless; showing them on the card is a separate marketing choice, Section 6). - **Pending state:** when a prize is "sujeto a lo que las empresas nos puedan dar" and not finalized, the card shows a tasteful "Premio por confirmar" placeholder rather than a blank or a fake prize. This keeps the page honest and lets marketing launch before every brand deal closes. - **Pair every prize with impact.** Under the prize grid, a single bridging line ties winning to giving, for example "Cada chance que compras se convierte en atenciones para los chicos de Teleton." This is the structural device that makes one grid serve both audiences: the prize pulls the 22 to 38 group, the impact line pulls the 35 to 50 group, on the same screen. - A "Ver todos los premios" expander if the list is long, so the fold stays light on mobile. ### 1.5 The cause and impact This section carries the 35 to 50 segment and protects the charity framing that INDECOPI guidance wants kept primary (so the raffle never reads as a disguised sale). - A short, warm explanation of what Teleton does and what the funds enable, in Teleton's own supportive voice (this is the one section where the playful tone yields to the institutional tone). - A concrete impact translation if Teleton can supply real figures, for example "Con S/ [x] se cubre [una atencion / una terapia]." Use real numbers from Teleton or leave a clearly marked token; do not invent figures. - Official Teleton endorsement cue: "Esta rifa es organizada por Teleton" with the logo, so the cause section doubles as a trust signal. ### 1.6 Urgency (countdown to the draw) - A live countdown to the draw date (September 12 for the main raffle; the warm-up date once confirmed). Days, hours, minutes. - Honest urgency only. The countdown is real because the draw date is real. Do not add fake "solo quedan X cupos" scarcity, since chances are effectively unlimited and false scarcity on a charity site is both a dark pattern and an INDECOPI exposure. - When the sale window closes, the countdown flips to a clear "Inscripciones cerradas. El sorteo es el [fecha]" state, and the CTA changes from "Quiero participar" to "Mira el sorteo en vivo" pointing at the live (aligns with the "hacer live" plan). - Accessibility: the countdown must not be the only place the deadline is stated; the date also appears as plain text, and the live-updating region is polite (aria-live="polite") or, better, the seconds tick is visually animated but the screen-reader text updates only at coarse intervals to avoid a chatty live region. ### 1.7 Social proof (live entries or funds counter) - A live (or near-live, cached and incremented) counter of confirmed participants or chances sold, for example "Ya somos [N] participantes apoyando a Teleton." This is strong social proof for both segments and reinforces the community feeling Rodrigo wants ("se sientan parte de esa comunidad Teleton"). - **Honesty and privacy rules:** count only confirmed-paid entries (never pending or abandoned, which would inflate the number and break trust and auditability). Never display individual participant names or contacts. An aggregate count only. - `[inferred]` A funds-raised counter is more motivating for the 35 to 50 segment but is financially sensitive and must reconcile exactly with money received; default to a participants or chances counter unless Teleton explicitly wants a soles figure shown. Whatever is shown must match the auditable totals. - Performance: the counter reads from a cached value refreshed on an interval, not a per-view database hit, so a viral spike does not hammer the write path (NFR-5.2.1). - Optional, lightweight: the influencer ("representante de la rifa") featured here as the face of the campaign, with a short line and their handle, to convert their followers who arrive cold. ### 1.8 The representative / influencer block (optional) - A small section that puts the campaign influencer front and center, since their post is the traffic source. A photo, a one-line endorsement in their voice, and a clear "Yo ya participe, te toca a ti" style nudge. - Must carry the INDECOPI influencer-disclosure posture in the campaign content itself (their posts labeled "Publicidad"), which is a content-ops requirement noted to Teleton, not a UI element, but the landing should not contradict it. ### 1.9 FAQ Short accordion, answering the real friction questions that block a micro-purchase. Each item is a button that expands a panel (proper disclosure semantics, keyboard operable, aria-expanded). Suggested questions (answers kept in Peruvian register, copy direction in Section 5): - Como participo. - Cuanto cuesta y cuantas chances me dan. - Como se eligen los ganadores (state the supervised, witnessed draw plainly: this is a fairness signal). - Cuando y donde es el sorteo. - Como sabre si gane y como recibo mi premio. - Mi pago es seguro. - Puedo participar mas de una vez (this answers the returning-buyer question honestly under Fork B). - A donde va mi dinero. The "como se eligen los ganadores" and "a donde va mi dinero" answers are doing double duty as trust content. Write them straight, no jokes. ### 1.10 Bases del sorteo, terms, and footer - A prominent, permanently visible link to the **Bases del sorteo (PDF)**, not buried. The legal brief is explicit that the bases must be public and easy to reach from every shareable surface. - Footer contains: Teleton legal name and RUC, link to the privacy policy (politica de privacidad, Ley 29733), link to terms, contact, the Teleton logo, and a line naming the supervising authority posture ("Sorteo realizado con la supervision de la autoridad competente") once confirmed with legal. - Secure-payment badges (the payment provider mark, "Pago seguro") sit in the footer and are echoed at the payment step. - Builder credit is not required and should not clutter a charity footer. ### 1.11 Persistent bottom action bar (mobile) - A sticky bottom bar with the primary CTA "Quiero participar" and a tiny secondary "Ya participaste? Ingresa aqui" link (the returning-buyer entry point). On a long landing this single element is the highest-impact conversion component, because it removes the scroll-back-to-top cost on the exact moment of intent. - The bar must not cover content (the page bottom gets padding equal to the bar height), must be keyboard reachable in a sensible order, and must collapse out of the way for screen readers in a way that does not trap focus. --- ## 2. Registration plus upsell flow, screen by screen Design target: an impulse micro-purchase completed on a phone, from a cold social visit, in well under a minute. Every screen has one job. The authoritative price and chance count are computed server-side (NFR-5.2.3); the client only displays and proposes. The happy path is five steps: Register, Upsell, Review and pay, Payment (provider), Confirmation. A returning-buyer path forks in before Register. ### Screen A: Register (minimal) - **Fields, in order:** Nombre completo, Celular (numeric keypad, tel input), Correo (email keyboard). Three fields. That is the floor the audio and the law require (name plus the two recognition and confirmation contacts). - **Base chance is pre-set to 1** so the user is already "in" with one chance; the quantity choice is the next screen (the upsell), which matches Rodrigo's flow ("voy a participar con [base]" then "previamente le puede salir..."). - **Consent block, below the fields, above the CTA:** - One mandatory, unticked checkbox for terms plus data consent (Ley 29733), with the bases and privacy policy linked inline. Express, unbundled, never pre-checked (legal brief is explicit). - One separate, optional, unticked checkbox for marketing contact. Never bundled with the mandatory consent. - **CTA:** "Continuar." Disabled until required fields validate and the mandatory consent is checked. The disabled state is communicated in text, not color alone. - **Validation:** inline, on blur and on submit, with text error messages announced to screen readers (Section 3). Phone and email format checked client-side for fast feedback, re-validated server-side. - **UTM / channel capture:** silent, system-side, no field shown. Lets Teleton attribute entries to the influencer and channel at zero user friction. - **What is deliberately absent:** no DNI, no address, no birthdate. Collecting DNI from every buyer is an unnecessary data-protection liability; DNI is collected only from winners at prize handoff. If an age gate is legally required (open question), it is a single "Confirmo que soy mayor de edad" checkbox, not a birthdate field. ### Screen B: Upsell (honest "quieres mas chances") This is the revenue lever and the fee-survival mechanism, and it is where the no-dark-pattern discipline is most load-bearing. - **Header copy, playful and honest:** "Quieres mas chances?" with a one-line honest framing that more chances means more posibilidades, never a guarantee. - **The current state is always visible:** "Tienes 1 chance" updates live as the user picks an option, so the math is never hidden. - **Tiers presented exactly as Rodrigo described** (under the recommended flat model: "1 mas por S/ 5, 2 mas por S/ 10, 3 mas por S/ 15"), as a pick-one set of friendly cards. Each card states added chances, added cost, and the resulting new total chances and total to pay. The values are event configuration, so a future volume-discount or package model is a config change, not a redesign. - **Decline is first-class.** A clearly visible "No, gracias, sigo con [1] chance" option that is the same visual weight as the upsell cards, one tap, no friction, no guilt copy, no "estas seguro?" interstitial. This is the line that keeps the upsell honest for a charity. - **No fake urgency on this screen.** No countdown, no "oferta por tiempo limitado." The only urgency is the real draw-date countdown elsewhere. - **Running total** is pinned at the bottom: "Total: [N] chances por S/ [monto]." This total is recomputed server-side before payment; the screen value is a preview. - **Fee-survival nudge, framed honestly (optional, recommended):** because a bare S/ 5 single chance loses most of its value to the fixed fee on card rails, the most-prominent option can gently anchor a bundle ("el favorito" badge on the middle tier) as long as the single-chance option remains visible and selectable. Anchoring a better-value bundle is legitimate; hiding or disabling the cheap option would not be. Pair this with routing the genuine S/ 5 single to Yape (Section 6) so the low-barrier hook still exists without bleeding 80 percent to fees. ### Screen C: Review and pay - **Plain summary card:** evento (warm-up or main), numero de chances, total a pagar, the buyer's name and contact for confirmation, and the honest odds line. - **Optional "cubre la comision" toggle (recommended, opt-in, honest):** "Suma S/ 1 para cubrir la comision y que el 100 por ciento de tu aporte llegue a Teleton." Off by default, clearly labeled, never a dark pattern. Many donors opt in; this protects net proceeds transparently. The added amount is shown updating the total. - **Payment-method choice with Yape primary:** Yape as the largest, top, default button on mobile (best economics for small tickets and the method this audience expects), card next, and PagoEfectivo or other methods below as secondary. Method order is itself a conversion-and-fee decision. - **Reassurance row:** "Pago seguro," provider badge, "Sorteo supervisado," link to bases. - **CTA:** "Pagar S/ [monto]." The amount is on the button so there is never a surprise on the provider screen. ### Screen D: Payment (provider, hosted) - Hosted Checkout (Culqi Checkout or Mercado Pago Bricks per the payments research) to keep PCI scope minimal and inherit issuer fraud tooling. - **Webview resilience is the make-or-break detail:** the redirect or popup must return cleanly into the Instagram and TikTok in-app browsers. Test the full round trip inside both before launch. Prefer an integration that keeps the user in-page (embedded checkout) over a hard external redirect when possible, because in-app webviews break some redirect and cookie flows. - **State handling:** the three outcomes (success, failure, abandoned/timeout) each route to a clear screen. A registration with no confirmed payment is a lead, not an entry, and the UI says so honestly ("Tu pago no se completo. Tu inscripcion no esta confirmada todavia."). - **Source of truth is the webhook, not the browser return.** The confirmation screen and email are driven by the server-confirmed payment, not by the redirect, because mobile users close tabs. The UI may show an optimistic "estamos confirmando tu pago" state that resolves when the server confirms. ### Screen E: Confirmation plus share - **Confirmation:** "Listo, [nombre]. Ya estas participando con [N] chances." State chances bought, amount paid, which event, and that a confirmation email is on the way. - **Email expectation set explicitly:** "Te enviamos la confirmacion a [correo]." This matches the audio ("la confirmacion tal vez a su correo para que lo tenga validado"). - **This is the share screen** (detailed in Section 4): a one-tap "Comparte y suma a tus amigos" with prefilled captions for Instagram, TikTok, and WhatsApp, plus a "Quiero mas chances" button that loops the buyer back into the upsell or a fresh purchase (the honest path to repeat buying under Fork B). - **No personal data on any shareable artifact.** The share image and caption are generic campaign creative, never the buyer's name, contact, or chance count, to avoid leaking personal data into social. ### Returning-buyer entry point (Fork B recommended) Per the research recommendation, ship Fork B for the warm-up (flat-price repeat, no recognition lookup), while capturing phone and email on every purchase so Fork A can be added later with no data migration. - **Entry point:** the "Ya participaste? Ingresa tu correo o celular" link in the bottom bar and on the FAQ. Under Fork B this does not perform a privacy-sensitive lookup of someone else's entries; it simply routes the returning user into the normal flow with a friendly, honest message. - **Copy direction:** "Que bueno verte de nuevo. Para sumar mas chances, vuelve a inscribirte. Tus nuevas chances se suman a las que ya tienes." This is honest: the system aggregates a person's chances at draw time by matching their contact, even though the UI does not display their prior chances. - **If and when Fork A is chosen for September:** the same entry point gains a verification step (one-time code to email or phone) before showing any stored entries, because displaying a person's history to anyone who types their contact is a data-protection problem on a charity site. The UI is designed so adding this step later is an insertion, not a redesign. ### Cross-screen flow notes - A persistent, honest progress indicator (for example "Paso 1 de 3") so the user knows the purchase is short. Keep it to the steps the user controls (Register, Chances, Pay); the provider screen and confirmation are outcomes. - Back navigation must preserve entered data (no retyping name and contact if the user steps back from the upsell). Re-typing on mobile is a top abandonment cause. - Idempotency is invisible to the user but felt: a double-tap on "Pagar" or a flaky-network retry never creates two charges or two entries (NFR-5.2.2). The UI disables the pay button on tap and shows a spinner. --- ## 3. Accessibility as a brand imperative (WCAG 2.1 AA), concretely Treat this as a launch gate, not a follow-up. For a charity serving people with disabilities, an inaccessible flow is a brand contradiction. Concrete requirements across the landing and the full purchase flow: - **Semantic structure.** One H1 (the hero promise), correct and non-skipping heading order down each section, landmarks (header, main, nav if used, footer), and lists marked up as lists (the 3 steps, the FAQ). Screen-reader users navigate by heading and landmark, so this is foundational, not cosmetic. - **Forms.** Every field has a persistent, programmatically associated visible label (not placeholder-as-label). Inputs use correct types and inputmode (tel for celular with numeric keypad, email for correo) so mobile keyboards are right. Required fields are marked in text and with aria-required. Autocomplete attributes set (name, tel, email) so password managers and autofill work, which materially speeds mobile completion. - **Errors.** Validation messages are in text next to the field, programmatically tied via aria-describedby, and announced (an aria-live region or focus management to the first error). Never communicate an error with color alone. The submit-disabled reason is stated in text. - **Contrast.** All text meets at least 4.5:1 (3:1 for large text), and UI components and focus indicators meet 3:1. This includes the CTA buttons, the price text, the upsell cards, and the countdown. The playful palette must be validated against this; pretty-but-low-contrast is a fail. - **Color is never the only signal.** The selected upsell tier, the chosen payment method, error states, and the active step are all distinguishable without color (an icon, a check, a border weight, a text label), per NFR-5.4.3. - **Keyboard.** Full operability with no mouse: logical tab order top to bottom, every interactive element reachable and activatable by keyboard (the upsell cards, the FAQ accordion, the consent checkboxes, the payment-method buttons, the sticky bottom bar), a visible focus ring on every focusable element, and no keyboard traps (especially around any modal, the hosted checkout, and the sticky bar). - **Tap targets.** Minimum 44 by 44 CSS pixels for every tappable control, with adequate spacing so fat-finger mis-taps do not buy the wrong tier or mis-submit. This is both accessibility and conversion. - **Reduced motion.** Respect prefers-reduced-motion: the hero loop, the counter increment, and the countdown tick all degrade to static or minimal motion. No essential information is conveyed by motion alone. - **Screen-reader end to end.** Verify the entire journey with at least one mobile screen reader (VoiceOver on iOS, TalkBack on Android), including the upsell selection, the payment redirect and return, and the confirmation. The hosted checkout's own accessibility is part of the provider decision; test it, do not assume it. - **Live regions, used sparingly.** The entries counter and the countdown update visually but use polite, coarse-grained announcements so a screen-reader user is not spammed every second. The "estamos confirmando tu pago" state is announced once when it resolves. - **Language and structure for assistive tech.** lang="es-PE" on the document so screen readers use Peruvian Spanish pronunciation. Decorative icons are aria-hidden; meaning lives in text. - **Plain language.** Short sentences, concrete words, the same Peruvian register used everywhere. Plain language is an accessibility feature (cognitive accessibility) and a conversion feature at once. --- ## 4. Shareability The traffic model is social and viral, so the share mechanics are a primary feature, not a footer afterthought. ### 4.1 Open Graph and Twitter cards - Every shareable URL (the landing, and ideally a per-event URL) carries complete Open Graph tags: og:title (the promise plus the cause), og:description (the mechanic in one line), og:image (a purpose-built 1200 by 630 share image with the Teleton mark, the promise, and a prize hero, no personal data), og:url, og:type, og:locale set to es_PE. - Twitter (X) card tags: summary_large_image, with title, description, and image mirroring the OG set. - The share image is campaign creative, not a screenshot, so it always looks intentional when pasted into a feed, a story, or a WhatsApp chat. Provide a couple of variants (prize-led for the 22 to 38 share, cause-led for the 35 to 50 share). - Validate the cards in the real previewers and inside the Instagram, TikTok, and WhatsApp link unfurlers before launch, because in-app unfurling is inconsistent. ### 4.2 Share-and-add mechanic plus post-purchase share screen - The confirmation screen (Screen E) is the share moment, when intent and goodwill peak. A single "Comparte y suma a tus amigos" with native share (the Web Share API on mobile, which opens the phone's real share sheet, the highest-converting share path) plus explicit one-tap buttons for WhatsApp, Instagram (story), and TikTok where deep links allow. - Prefilled, editable captions (Section 5) so the user does not have to write anything. Peruvian register, no emojis, no em-dashes. - A "Quiero mas chances" button on the same screen turns the share moment into a repeat-purchase moment, the honest engine of repeat buying under Fork B. ### 4.3 Referral-friendliness - Make the shared link carry a channel or referrer UTM so Teleton can see which shares and which influencer drove entries, with no extra user step (NFR attribution). - `[inferred]` A full peer referral program (personal codes, leaderboards, rewards for referrers) is not in the audio and adds real legal and data complexity to a charity raffle. Do not build it for the warm-up. Keep shares attributable via UTM, and revisit a formal referral mechanic only if Teleton asks and legal clears it. - Every shared surface links back to the bases and shows the Teleton mark, so virality never travels without the trust and legal context attached. --- ## 5. Sample Spanish microcopy (Peruvian register, no em-dashes, no emojis, no voseo) Money is written S/ followed by the amount. Bracketed tokens are values that must be set once Rodrigo confirms pricing, dates, and impact figures. None of these use em-dashes, en-dashes, emojis, or voseo. ### Hero - **Headline (H1):** Tu ayuda tambien te ayuda a ti - **Subhead:** Participa en la rifa de Teleton, ayuda a miles de chicos y entra al sorteo por [premios reales]. Desde S/ [base] por una chance. ### How it works (3 steps) 1. Inscribete. Pon tu nombre, tu celular y tu correo. Te toma segundos. 2. Elige tus chances. Una o las que quieras. Mientras mas chances, mas posibilidades de ganar. 3. Paga seguro y participa. Te llega la confirmacion a tu correo y ya estas adentro. ### Upsell prompt - **Header:** Quieres mas chances? - **Subline (honest framing):** Mientras mas chances tienes, mas posibilidades de ganar. Nunca esta garantizado, pero suma a tu favor y a la causa. - **Current state:** Tienes 1 chance. - **Tier cards (under the flat model):** - 1 chance mas por S/ 5. Te quedas con 2 chances. Total S/ [10]. - 2 chances mas por S/ 10. Te quedas con 3 chances. Total S/ [15]. - 3 chances mas por S/ 15. Te quedas con 4 chances. Total S/ [20]. - **Decline (equal weight, one tap):** No, gracias. Sigo con 1 chance. - **Running total:** Total: [N] chances por S/ [monto]. ### Cover-the-fee toggle (Review screen) - Suma S/ 1 para cubrir la comision y que el 100 por ciento de tu aporte llegue a Teleton. ### Confirmation email - **Subject:** Listo, ya estas participando en la rifa de Teleton - **Body:** - Hola [nombre], - Gracias por sumarte. Tu aporte ayuda a que mas chicos reciban atencion en Teleton, y ademas te da la posibilidad de ganar. - Esto es lo que registramos: - Chances: [N] - Monto: S/ [monto] - Sorteo: [nombre del evento], [fecha del sorteo] - El sorteo se realiza de forma transparente y supervisada. Si ganas, te contactamos por este correo y por tu celular. - Quieres mas posibilidades? Puedes sumar mas chances cuando quieras desde la pagina. - Revisa las bases del sorteo aqui: [enlace] - Gracias por ayudar. - Equipo Teleton ### Share captions (2 to 3, prefilled and editable) - **Prize-led (skews 22 to 38):** Ya estoy en la rifa de Teleton. Ayudas a miles de chicos y puedes ganarte [premio]. Tu ayuda tambien te ayuda a ti. Participa aqui: [enlace] - **Cause-led (skews 35 to 50):** Apoye a Teleton y tu tambien puedes. Cada chance ayuda a que mas chicos reciban atencion, y de paso entras al sorteo. Suma aqui: [enlace] - **Short, WhatsApp-friendly:** Sumate a la rifa de Teleton. Ayudas y puedes ganar. Aqui: [enlace] ### Microcopy notes - "Sebastian" never carries an accent in any builder-facing copy. The buyer-facing copy never mentions the builder. - Tone calibration: the playful voice lives in the hero, the steps, and the upsell header. The cause section, the FAQ trust answers, the email, and anything about children stay warm but straight. --- ## 6. Trust elements For a national charity handling real money and personal data, trust is the conversion strategy. These are the concrete trust surfaces. - **Transparency on where the money goes.** A plain statement in the cause section and the FAQ of what the funds enable, with a real impact figure if Teleton supplies one (no invented numbers). The honest odds framing ("mas chances, mas posibilidades, nunca garantizado") appears at every money moment, satisfying both conversion clarity and INDECOPI no-misleading-promotion. - **Official Teleton branding, early and often.** The Teleton logo in the top bar, the hero trust strip, the cause section, and the footer, plus an explicit "Esta rifa es organizada por Teleton." First-load legitimacy is critical because users arrive cold from a social link and are about to pay. - **Secure-payment badges.** The payment provider's mark and a "Pago seguro" label at the hero trust strip, the Review and pay screen, and the footer. Card payments inherit issuer 3DS or OTP step-up (kept on for fraud protection even though it adds a step). Yape, the recommended primary rail, is a push payment, which the copy can frame as fast and familiar. - **Clear link to the terms and bases.** The Bases del sorteo PDF and the privacy policy are prominent and permanently reachable from the landing, the footer, the FAQ, and the email, never buried. The bases are both a legal requirement and the consumer-facing contract, and they must not change after publication. - **Fairness of the draw, stated plainly.** The FAQ and the cause area state that the draw is conducted transparently and supervised by the competent authority (and, if adopted, before a notary), with winners selected by a documented, reproducible method from a frozen snapshot of confirmed entries. This is the single most reputation-protective piece of copy on the site. Align the exact wording with Teleton legal. - **Honest data handling.** The consent checkboxes are unbundled and unticked, the privacy policy is linked at the point of consent, and the page collects the minimum data (no DNI from general buyers). Visible data minimization is itself a trust signal on a charity site. - **No dark patterns, anywhere.** No fake scarcity, no pre-checked upsells or fee toggles, no guilt-trip decline copy, no hidden totals, no surprise amounts on the provider screen. For Teleton, the absence of manipulation is a feature worth protecting deliberately. --- ## 7. How this maps to the open client decisions The design above is built to flex around the unresolved decisions so the build is not blocked, but several decisions still change specific screens. The ones that touch this design surface directly: - **Pricing model and exact prices (decision 1).** Every S/ token in Sections 1, 2, and 5 stays a token until Rodrigo confirms. The upsell screen is built for flat pricing (recommended) but is config-driven, so a volume-discount or package model is a content swap, not a redesign. - **Returning-buyer fork (decision 2).** The design ships Fork B (flat repeat, no lookup) and reserves the verification-gated Fork A as a later insertion at the same entry point. - **Payment provider (decision 3).** Drives the hosted checkout used, the webview behavior to test, and whether the S/ 5 single chance is viable on a given rail. Yape-primary is assumed on the Review screen. - **Winners per event and draw mechanism (decisions 4 and 5).** Affect the FAQ and countdown copy (one winner per prize assumed; live on-camera draw assumed, which aligns with "hacer live"). The warm-up date being only "finales de agosto" means the countdown shows text until the exact date is set. - **Prize display when not finalized (decision 6).** Handled by the "Premio por confirmar" card state. - **Embedding into teleton.pe (decision 7).** Affects cookies and payment redirect; the design assumes a standalone landing first, embeddable later, and the webview-resilient payment step is built with that in mind. - **Email sender, legal and consent copy, age gate (decisions 8 and 9).** The email template, the consent checkboxes, the bases and privacy links, and a possible single age-confirmation checkbox are all placed; the actual legal text comes from Teleton. - **Analytics attribution (decision 11).** Satisfied by silent UTM capture at registration and on shared links, no user friction. All of these are surfaced to Rodrigo in the open questions list so the design and the build move in lockstep with the client and legal tracks. ## Recommendations - **Lead the hero with the verbatim promise 'Tu ayuda tambien te ayuda a ti' as the H1 and pair every prize card with a one-line impact statement, so a single funnel serves both the prize-driven 22 to 38 segment and the cause-driven 35 to 50 segment without building two flows.**: The brief states the two segments are a messaging concern, not separate funnels. The dual promise is literally the union of both motives, and pairing prize plus impact on the same screen is the structural device that converts both audiences in one scroll. - **Build the upsell as an honest, config-driven 'Quieres mas chances?' step where declining is one tap at equal visual weight, nothing is pre-selected, the running total and odds math are always visible, and there is no fake scarcity.**: This is a national charity, so trust is the conversion strategy. The upsell is also the payment-fee-survival mechanism (bundles above roughly S/ 12 to S/ 15 escape the S/ 3.50 fixed-fee cliff), so it must convert, but any dark pattern would risk Teleton's reputation and INDECOPI exposure. Config-driven tiers mean a future pricing change is a content swap, not a redesign. - **Position Yape as the largest, default, top payment button on the Review and pay screen, with card and PagoEfectivo as secondary, and add an opt-in 'cubre la comision' toggle (S/ 1, off by default).**: A bare S/ 5 card sale loses about 83 percent to fees, while the same amount over Yape loses about 3 percent. Method order is a fee-and-conversion decision. The honest, opt-in fee-cover toggle protects net proceeds transparently, which many charity donors accept. - **Treat WCAG 2.1 AA as a launch gate verified end to end on a real mobile screen reader (including the upsell selection and the payment redirect and return), not as a post-launch follow-up.**: Teleton serves people with disabilities, so an inaccessible flow is a direct brand contradiction and the highest-leverage reputational requirement in the build. The payment redirect and in-app webview return are the parts most likely to break for assistive tech, so they must be tested, not assumed. - **Ship returning-buyer Fork B (flat-price repeat, no entry lookup) for the August warm-up while capturing both phone and email on every purchase, and design the 'Ya participaste?' entry point so a verification-gated Fork A can be inserted for September if repeat-buying proves real.**: Fork B is the fastest, smallest-privacy-surface path and matches Rodrigo's own fallback. Displaying a person's stored entries to anyone who types their contact is a data-protection problem on a charity site, so Fork A needs an OTP step. Capturing both contacts now keeps Fork A a later insertion with no data migration. - **Verify the entire purchase flow, including the hosted checkout redirect and return, inside the Instagram and TikTok in-app browsers before launch, and drive the confirmation screen and email from the server-confirmed webhook rather than the browser return.**: All traffic originates from social, which opens links in in-app webviews that break some redirect and cookie flows. Mobile users also close tabs after paying, so the browser return is an unreliable signal; the webhook is the source of truth for both the entries database and the confirmation. - **Make the post-purchase confirmation the share moment: native share sheet plus prefilled, editable Peruvian-register captions (prize-led and cause-led variants), purpose-built Open Graph and Twitter card images with no personal data, and a 'Quiero mas chances' button that loops back into a purchase.**: The growth model is viral and influencer-driven, and goodwill peaks right after a successful contribution. Prefilled captions remove the writing friction, dual creative variants match the two audiences, and the loop-back button is the honest engine of repeat buying under Fork B. Keeping personal data off shareable artifacts avoids leaking it into social feeds. ## Open Questions - Pricing: confirm the base price and whether extra chances are flat (recommended: S/ 5 each, shown as the '1 mas por S/ 5, 2 mas por S/ 10, 3 mas por S/ 15' tiers) or discounted, and whether there is a maximum number of chances per person. Every S/ value in the copy is a placeholder until this is set. - Returning buyer: confirm Fork B (flat repeat, no lookup) for the warm-up, with Fork A (recognize by phone or email plus an OTP verification step) reserved for September only if repeat-buying proves real. - Payment provider and methods: confirm the provider (affects the hosted checkout, the webview behavior to test, and the viable single-chance price) and confirm Yape is exposed as the primary, prominent mobile method. - Draw and dates: confirm one winner per prize, whether one person can win more than one prize per event, the exact warm-up date (currently only 'finales de agosto', which determines whether the countdown shows text or a live timer), and whether the September 12 draw is live on camera. - Impact figures: provide a real, citable impact line for the cause section and email (for example what S/ X enables), or confirm none should be shown. No figures will be invented. - Social proof counter: confirm whether to show a participants/chances count (default, safer) or a soles-raised figure (more motivating but financially sensitive and must reconcile exactly with money received). Either way it counts confirmed-paid entries only and shows no individual data. - Legal copy and age gate: confirm who supplies the bases del sorteo PDF, the privacy policy text, and the consent language, and whether a 'mayor de edad' age-confirmation checkbox is legally required on the registration screen. - Branding assets: provide the official Teleton logo, brand colors, typography, and the campaign influencer's photo and handle, and confirm the colors pass WCAG AA contrast (the playful palette must be validated, not assumed). - Embedding: confirm whether the page is a standalone landing first (recommended) and embedded into teleton.pe later, and if embedded, whether via iframe or subdomain/subpath, since that affects cookies and the payment redirect. - Fee-cover toggle: confirm whether Teleton wants the opt-in 'cubre la comision' (S/ 1) toggle on the Review screen. - Email sender: confirm the email service and the Teleton-controlled sending domain for the confirmation email (deliverability and trust). ## Risks - [high] The upsell tips into a dark pattern under conversion pressure (pre-selected tiers, a buried or guilt-tripping decline, fake scarcity, a pre-checked fee toggle), damaging a national charity's reputation and creating INDECOPI exposure. -> FIX: Lock the honesty rules into the design spec as non-negotiable: decline is one tap at equal visual weight, nothing pre-selected, no fake urgency on the upsell, fee toggle off by default, totals and odds always visible. Review the built upsell specifically against these rules before launch. - [high] The payment redirect or hosted checkout breaks inside the Instagram or TikTok in-app browser, silently killing conversion for the exact audience the campaign is built to reach. -> FIX: Test the full purchase round trip inside both in-app webviews before launch, prefer an embedded checkout over a hard external redirect, and drive confirmation from the webhook so a broken browser return still records a paid entry. - [high] Accessibility is treated as a follow-up and ships incomplete, which for a charity serving people with disabilities is a direct brand contradiction and a credibility hit. -> FIX: Make WCAG 2.1 AA a launch gate with a concrete checklist (semantics, labeled forms, 4.5:1 contrast, full keyboard, 44px targets, reduced motion, text-not-color errors) and verify end to end on a real mobile screen reader, including the payment step. - [high] A bare S/ 5 single chance is sold on a card or voucher rail, losing roughly 83 percent to the fixed fee and making the raffle economically pointless on those tickets. -> FIX: Steer the genuine S/ 5 single to Yape (about 3 percent fee), set the smallest card/voucher purchase at S/ 10 or above, anchor a bundle as the prominent option without hiding the cheap one, and offer the opt-in fee-cover toggle. - [medium] The social-proof counter or confirmation flow inflates numbers (counting pending or abandoned entries) or leaks participant data into shareable artifacts, breaking trust and data-protection compliance. -> FIX: Count confirmed-paid entries only, refresh from a cached aggregate, show no individual names or contacts, and keep all share images and captions as generic campaign creative with zero personal data. - [medium] Pricing and prize details stay unresolved (pricing ambiguity, brand-dependent prize list) past the point where copy and the legally required bases must be frozen, stalling both the page and the MININTER filing. -> FIX: Keep all prices and prizes as tokens and config so the page is buildable now, render unconfirmed prizes as 'Premio por confirmar', and flag to Rodrigo that pricing must be frozen before the bases can be filed (a stated critical-path item). - [medium] Returning-buyer recognition (Fork A) is built prematurely and exposes one person's stored entries to anyone who types their phone or email, creating a Ley 29733 data-protection problem. -> FIX: Ship Fork B for the warm-up (no lookup), capture both contacts for later reconciliation, and only add Fork A with a one-time-code verification step if repeat-buying proves real in the warm-up. - [medium] The playful, prize-led tone drifts into language that reads as a disguised product sale or downplays the charity purpose, which INDECOPI has publicly warned against. -> FIX: Keep the charity purpose primary in copy, confine the playful voice to the hero, steps, and upsell header, and keep the cause, FAQ trust answers, and anything about children warm but straight. - [medium] A viral spike from a single live or influencer post overwhelms the write path or invites carding attacks on the cheap ticket, degrading the experience at the worst possible moment. -> FIX: Statically cache the landing and the counter, keep the write path thin and idempotent, disable the pay button on tap, and add a lightweight challenge plus velocity limits on the registration and payment-initiation endpoints (build-side, but it shapes the UX of the form). ## Sources - /Users/sebasbimbi/sebastian-bimbi/projects/teleton/rodrigo-nores-transcript.md - /Users/sebasbimbi/sebastian-bimbi/projects/teleton/rodrigo-nores-2-transcript.md - Research stage REQUIREMENTS brief (provided in task context) - Research stage PAYMENTS (PERU) brief (provided in task context) - Research stage LEGAL / COMPLIANCE (PERU) brief (provided in task context)