Lo que el sistema tiene que lograr. Cada uno sale de un problema real, no del código que ya existe. Abajo de cada uno está la pantalla donde vive.
Cualquiera de los tres abre el sistema y en cinco segundos ve si Gonama gana o pierde plata este mes, y por qué.
Traer automáticamente las transacciones de la cuenta PayPal info@jinkanna.com cada 6 horas.
Cada transacción lleva una etiqueta: MRR de Gonama, setup de Gonama, proyecto de Jinkanna, servicio de Jinkanna a Gonama, herramienta compartida, herramienta de Jinkanna, o a categorizar.
El sistema propone la etiqueta y el operador la confirma o la corrige en menos de 30 segundos.
Procesar de una vez el historial de PayPal hacia atrás, hasta donde haya datos, para tener con qué comparar.
Cargar los costos que se repiten todos los meses: Renato, fly.io, Amplify, AWS, hosting de Shopify, Sentry, Sonetel, Wondershare, el sueldo de Belu, y lo que aparezca.
Cada costo se marca como de Gonama, de Jinkanna, o compartido con un porcentaje configurable.
Si un costo que viene todos los meses no aparece este mes, el sistema lo señala.
Mes a mes, cuánto le facturó Jinkanna a Gonama por servicios: Renato, Fierro, uso de la cuenta PayPal, soporte.
Saber en cualquier momento cuánto le debe Gonama a Jinkanna acumulado.
Anotar los pagos de Gonama a Jinkanna, parciales o totales.
Una pantalla con el MRR, los costos, el resultado del mes, la diferencia contra el mes pasado y el runway.
Proyectar los próximos tres meses con el MRR esperado y los costos recurrentes conocidos.
Poder consultar en el sistema cómo cerró cada mes anterior, sin depender de un PDF ni de un mail.
Bajar los movimientos y el reporte del mes en Excel para mandárselo a la contadora externa.
Cada app marcada como activa, sin cliente, o candidata a apagar, con su costo mensual estimado.
Asignar el costo de cada app deployada a su cliente para saber el margen que deja cada uno.
Traer sola la lista de apps de fly.io con su estado y su costo, y vincular cada una al cliente que corresponde. Las que quedan sin cliente saltan a la vista sin que nadie las tenga que buscar.
Un cliente que se va no queda cerrado hasta que su app está apagada. Mientras siga prendida, el sistema lo muestra como una baja pendiente con el costo mensual que sigue corriendo.
Ningún cliente se cae porque no nos enteramos a tiempo de que le falló un pago.
Cada suscripción tiene su estado al día: activa, en riesgo, suspendida, cancelada o recuperable.
Comparar cada sincronización de PayPal contra la anterior para detectar los cobros que fallaron.
Un banner en el sistema avisa cuando un cliente pasa a en riesgo (un fallo) o a recuperable (dos o más).
Cuántos fallos lleva, cuándo fue el último cobro exitoso, cuánto MRR está en juego y hace cuántos días que falla.
Definir la secuencia de avisos al cliente tras un fallo (día 1, 3 y 7) con textos editables.
El sistema envía los mails de la secuencia por AWS SES sin que nadie tenga que acordarse.
Marcar como recuperable la suscripción que lleva más de 90 días suspendida — el caso Don Gato Kids.
Cuando una suscripción pasa a cancelada, el sistema avisa y permite registrar el motivo a mano.
Poder responder cuánto pagó un cliente en total desde que arrancó.
Avisar cuando una suscripción quedó creada pero el cliente nunca la aprobó.
Ofrecerle algo al cliente antes de que cancele. Parkeado hasta definir qué se ofrece: descuento, mes gratis, plan más chico u otra cosa.
Cuando un cliente cambia de plan y le cambia el monto, el sistema lo detecta, lo registra con la fecha, y el MRR se mueve en consecuencia.
El cliente existe en el sistema desde que llega como lead. El sistema lo acompaña por todo el ciclo: contacto, acuerdo, primer cobro, acceso a su Shopify, deploy del carrito y app vinculada. Sin suscripciones huérfanas ni clientes duplicados.
Cuando entra un cobro de PayPal que no está vinculado a ningún cliente, marcarlo para que alguien lo resuelva. Cruza por mail contra los clientes y sus mails alternativos.
La sugerencia propone el cliente más probable según el mail y el monto, con los datos de PayPal a la vista para confirmarlo.
Visible desde cualquier pantalla, con un contador en el encabezado.
El caso de excepción: alguien apareció pagando sin haber pasado por el pipeline. Poder crearlo y vincularlo en un click.
Al dar de alta, poder registrar el setup fee cobrado como un movimiento separado del MRR.
Registrar en el alta si llegó por Plexo, por referido directo, por Meta Ads o por otro lado.
Vincular en el alta el dominio de Shopify y una o más apps deployadas al cliente.
El camino principal: el cliente viene del pipeline y ya está en el sistema. El cobro se engancha al que corresponde, aunque venga con otro mail. El caso Nutriciencia: existe con cafemur@hotmail.com y la suscripción llega con nutriciencia@gmail.com.
El cliente es uno solo desde que llega como lead hasta que se va. Cambia de estado —prospecto, en conversación, activo, en riesgo, ido— pero nunca se duplica ni hay que convertirlo en otra cosa.
Poder marcar un prospecto como perdido, con el motivo y la fecha. Un prospecto que nadie cierra queda abierto para siempre y ensucia todo lo que se mire después.
Cuando un cliente ya pagó pero todavía no tiene el carrito andando, el sistema avisa y muestra en qué paso está trabado: falta el acceso a su Shopify, falta el deploy, o falta vincular la app.
Saber qué prospectos hay abiertos, en qué etapa está cada uno y cuáles se enfriaron. El State dice que Plexo trae el 75-80% de los leads.
El sistema avisa en vez de esperar que le pregunten, y los tres operadores ven exactamente lo mismo.
Cada vez que detecta algo en PayPal —una suscripción nueva, un fallo, una cancelación— genera una sugerencia para el operador. Nadie tiene que ir a buscarla.
El MRR del mes, el resultado del mes y la cantidad de alertas urgentes, visibles en todas las pantallas.
Altas pendientes, confirmaciones de etiquetado y fallos sin atender, todo en un mismo lugar.
Alex, Nicolás Fernández y Belu entran con su cuenta. Los tres ven y editan todo. Sin roles.
No hay vistas personalizadas ni cálculos que dependan de quién mira.
La infraestructura del sistema tiene que costar menos de 15 dólares mensuales. Gonama está en rojo.
Aplicación web. El equipo está distribuido.
Copia de seguridad diaria de la base y los errores de producción registrados en Sentry.
Capacidades que están construidas pero que no responden a ningún requerimiento del análisis. Salieron del inventario del código de agosto 2026. Cada una tiene que terminar asignada a un objetivo o descartada — no se quedan acá.
Registrar los pedidos técnicos de cada cliente, quién los atiende y cuánto tiempo llevan.
Tener a mano los accesos a las tiendas de los clientes sin que queden en un chat o un Excel.
Que el alta de un cliente siga una secuencia con checklist, para que no se saltee nada del setup.
Tener textos preparados y reutilizables para no escribir lo mismo cada vez.
Dejar asentado qué se habló con cada cliente y cuándo, para no depender de la memoria de quien atendió.
Que cada cliente tenga su contrato firmado y guardado en el sistema.
Emitir el comprobante fiscal electrónico de cada factura.
Que lo que pasa en el CRM y lo que pasa en el admin sean la misma realidad.
Calcular cuánto le corresponde a quien trae un cliente.
Que borrar algo por error no sea definitivo — poder recuperarlo dentro de un plazo razonable.
Poder volver a una búsqueda o filtro que usás seguido sin rearmarlo.
Dar de alta, editar y dar de baja los planes que se venden, con su precio, moneda y ciclo. Hoy son cuatro estándar más los custom.
Abrir el sistema y ver qué hay que hacer hoy, sin recorrer pantallas.
Un indicador por cliente que resuma qué tan bien va la relación, para priorizar a quién atender.
Ver en un calendario qué vence y qué hay que hacer en los próximos días.
Poder agrupar clientes con etiquetas propias para filtrarlos después.
Un lugar para los parámetros que no se tocan todos los días.
Cruzar los movimientos del banco contra lo registrado en el sistema para detectar lo que falta o no coincide.
El reporte a socios y cualquier cálculo de participación tienen que usar la composición real de Gonama: Nicolás Fernández 50% y Jinkanna 50%. Croce y Fierro son socios de Jinkanna, no de Gonama.
La lista se edita en src/config/proyecto/requerimientos.ts y el mapa de pantallas en src/config/proyecto/menus.ts. Las dos se versionan con el código.