¿Qué están construyendo?
// El problema → ¿Qué es un CRM? → Los actores → El ciclo de vida de un lead
Sin un sistema, los contactos de posibles clientes viven en hojas de cálculo dispersas, grupos de WhatsApp o simplemente en la memoria del asesor. Cuando ese asesor sale de la empresa, toda la información se va con él.
Su aplicación centraliza esos contactos y controla en qué punto del proceso de venta está cada uno.
Customer Relationship Management — Gestión de la relación con el cliente.
- Centraliza la información de leads (posibles clientes)
- Controla el estado del proceso con cada uno
- Permite asignar leads a asesores responsables
- Registra notas e interacciones del proceso
Herramientas reales: HubSpot, Salesforce, Zoho CRM. La suya es la versión en consola.
- Asesor comercial: registra leads, les hace seguimiento, actualiza estados y deja notas de cada interacción.
- Administrador: ve todos los leads del sistema, puede asignarlos o reasignarlos, y elimina los no válidos.
El asesor solo ve sus leads. El admin ve los de todos.
Un lead no entra y desaparece. Avanza (o no) por estados:
Pregunta: ¿quién mueve el lead de un estado al otro, el asesor, el admin, o ambos?
¿Cómo se organizan?
// Roles del equipo → Tablero Kanban → Fase 1 vs Fase 2 (Telegram)
El rol de "Datos + Integraciones" puede ser el más técnico de Fase 2. Que lo tome quien más disfruta investigar.
¡Muevan tarjetas aquí
cuando las empiecen!
el trabajo
terminado.
Las tarjetas con borde punteado 🤖 son Fase 2. No las toquen hasta que todo lo demás esté en "Hecho".
- El sistema funciona 100% desde
python main.py - El asesor puede crear, ver y actualizar leads
- El admin puede ver todos los leads y asignarlos
- Los datos persisten en archivos JSON entre ejecuciones
- Hay login con roles diferenciados
- Un bot de Telegram recibe mensajes de posibles clientes
- El bot extrae los datos y los guarda en
Leads.json - El asesor abre la consola y ya tiene el lead registrado
- Requiere investigar la biblioteca
python-telegram-bot - Empiecen con una función que solo simule recibir un lead
¿Por dónde empieza el código?
// Arquitectura → JSON → Flujo de datos → CRUD → Telegram como módulo aislado
services/telegram_service.py) y la consola sigue funcionando igual si Telegram no está conectado.Creen primero las carpetas y los archivos vacíos. El archivo de Telegram puede quedar vacío hasta Fase 2.
Cada lead es un objeto con toda la información necesaria para darle seguimiento.
Pregunta: ¿qué campo permite saber quién es el responsable de ese lead? ¿Y de dónde llegó?
El mismo Leads.json recibe leads tanto desde la consola como desde Telegram.
La consola no necesita saber si el lead llegó por bot o por digitación manual.
| Operación | ¿Qué hace? | Ejemplo concreto en su app | ¿Quién lo hace? |
|---|---|---|---|
| CREATE | Agregar un registro nuevo | Asesor registra un nuevo lead (o bot de Telegram lo recibe) | Asesor / Bot |
| READ | Leer y mostrar registros | Ver mis leads asignados / Admin ve todos los leads del sistema | Asesor + Admin |
| UPDATE | Modificar un registro existente | Cambiar estado (nuevo→contactado→ganado), agregar notas | Asesor / Admin |
| DELETE | Eliminar un registro | Admin elimina lead duplicado o con datos incorrectos | Admin |
Todo lo que hicieron en PSeInt —agregar, mostrar, modificar, borrar— es exactamente esto. La única novedad es que ahora los datos persisten en JSON y existe un rol que tiene más permisos que otro.
El truco es escribir primero una función simulada en telegram_service.py que simplemente crea un lead de prueba y lo guarda en el JSON, sin Telegram real. Si eso funciona, agregar el bot real solo cambia cómo llegan los datos, no cómo se guardan.
No hay preguntas malas. Si algo no quedó claro, este es el momento.