¡Cuéntanos tu idea!

Contexto Actualmente Sagicc permite relacionar personas con una empresa desde la hoja de vida del cliente. Esta funcionalidad es útil para construir la estructura de una organización, pero esa información prácticamente desaparece durante la atención de un caso. Cuando un agente abre un caso asociado a una empresa, no tiene visibilidad de las personas que hacen parte de esa organización ni puede identificar fácilmente con quién está interactuando. Problema En una operación B2B, el cliente real es la empresa, pero la interacción siempre ocurre con una persona. Hoy, desde la vista del caso, el agente no puede responder fácilmente preguntas como: ¿Cuántos contactos tiene registrada esta empresa?¿Quién es la persona con la que estoy hablando?¿Esta persona ya existe como contacto?¿Qué otros contactos hacen parte de esta empresa?¿Cómo agrego un nuevo contacto si la persona aún no está registrada? Esto obliga a abandonar el caso para consultar la hoja de vida del cliente o, en muchos casos, termina generando información duplicada o incompleta. Propuesta Incorporar dentro de la vista del caso una sección llamada Contactos de la empresa, que permita consultar y administrar las personas relacionadas con la organización sin salir del flujo de atención. Esta sección debería mostrar: Número total de contactos asociados a la empresa.Lista de personas relacionadas.Nombre de cada contacto.Cargo (cuando exista).Datos principales de contacto (correo y teléfono).Indicador visual que identifique cuál de esos contactos es la persona asociada al caso actual. Gestión rápida Desde la misma vista del caso debería ser posible: relacionar un contacto existente con la empresa;crear un nuevo contacto para esa empresa cuando aún no exista;asociar el caso al contacto correcto si inicialmente quedó relacionado únicamente con la empresa. Todo esto sin abandonar la atención. Ejemplo Empresa: Technologistic Contactos registrados: Juan Pérez – TIMaría Gómez – ComprasCarlos Ruiz – OperacionesAna Torres – Recursos Humanos Si el caso fue abierto por María Gómez, la sección de contactos podría mostrar la lista completa y resaltar visualmente que María Gómez es el contacto asociado a este caso. De esta manera el agente entiende inmediatamente: con quién está hablando;quiénes más trabajan para ese cliente;y qué otros contactos ya existen registrados. Beneficios Mayor contexto durante la atención.Menor duplicidad de contactos.Registro más organizado de empresas B2B.Mejor experiencia para el agente.Menos navegación entre pantallas.Mayor calidad de la información del cliente. Principio de diseño Toda la información necesaria para identificar a la persona que interactúa con nosotros y su relación con la empresa debe estar disponible desde la vista del caso. El agente no debería abandonar el caso para entender la estructura del cliente al que está prestando el servicio.

Quisiera solicitar la evaluación y priorización de una integración nativa entre SAGICC y HubSpot CRM. Esta solicitud surge debido a que varios de nuestros clientes en negociacion han manifestado la necesidad de contar con una conexión directa entre ambas plataformas para optimizar la gestión de información, automatizar procesos comerciales y mejorar el seguimiento de sus clientes. Actualmente, los siguientes clientes han solicitado esta integración: Finandina Grupo Arenas Los Olivos Unicervantes

Contexto Actualmente la vista de Casos en Sagicc permite consultar los casos mediante una lista tradicional y aplicar filtros muy completos sobre la información registrada. Adicionalmente, hemos propuesto incorporar una vista Kanban para gestionar visualmente el avance de los casos dentro de cada campaña. Sin embargo, existe una tercera vista ampliamente utilizada en los CRM modernos y en herramientas de gestión de trabajo: una vista tipo Grid, donde cada fila representa un caso y cada columna muestra información relevante para administrarlo. Situación actual Hoy la lista de casos muestra principalmente información estándar como: Número del caso. Estado (Nuevo, Abierto, Escalado, Transferido, Cerrado). Cliente. Fechas. Información básica del caso. No obstante, la mayor parte de la información de negocio se captura en los formularios de gestión del caso y queda disponible únicamente al abrir cada registro o mediante filtros. Esto limita la capacidad de administrar grandes volúmenes de casos desde una sola vista. Propuesta Incorporar una vista Grid configurable para los casos, donde cada organización pueda seleccionar qué columnas visualizar. Además de los campos estándar del sistema, deberían poder mostrarse los campos definidos en el formulario de gestión de la campaña. De esta manera, la información capturada durante la operación se convertiría también en información de consulta y administración. Ejemplo: Campaña Comercial Cada caso representa una oportunidad de negocio. Las columnas podrían incluir: Empresa. Contacto. Ejecutivo responsable. Monto del negocio. Cantidad de usuarios. Servicio de interés. País. Industria. Fecha estimada de cierre. Probabilidad de cierre. Etapa del embudo comercial. Estado del caso. Fecha de creación. Última actividad. Con esta información el equipo comercial podría ordenar, filtrar y priorizar oportunidades sin necesidad de abrir cada caso. Ejemplo: Campaña de Soporte Técnico Cada caso representa un incidente o solicitud. Las columnas podrían incluir: Empresa. Contacto. Servicio afectado. Prioridad. Nivel de escalamiento. Ingeniero asignado. Fecha de apertura. Tiempo transcurrido. SLA. Estado del caso. Fecha de última actualización. Esto facilitaría la administración diaria de la operación de soporte. Configuración La vista debería permitir: seleccionar las columnas visibles; ocultar columnas no relevantes; cambiar el orden de las columnas; ordenar por cualquier columna; aplicar filtros sobre cualquier atributo; guardar vistas personalizadas para diferentes equipos o procesos. Beneficios Esta mejora permitiría: administrar grandes volúmenes de casos con mayor eficiencia; aprovechar la información ya capturada en los formularios de gestión; reducir la necesidad de abrir cada caso para consultar información clave; facilitar el seguimiento comercial y operativo; adaptar la vista a las necesidades específicas de cada campaña. Relación con el Kanban Las tres vistas serían complementarias y responderían a necesidades distintas: Lista: consulta rápida y búsqueda tradicional. Grid: análisis, segmentación y administración detallada utilizando todas las variables del caso. Kanban: seguimiento visual del flujo de trabajo y avance por etapas. Cada usuario podría elegir la vista que mejor se adapte a su forma de trabajar y al tipo de campaña que administra. Principio de diseño Toda la información estructurada que una organización captura durante la gestión de un caso debe poder reutilizarse para visualizar, ordenar, filtrar y administrar la operación. Los formularios de gestión no deben ser únicamente un mecanismo para almacenar datos; deben convertirse en una fuente de información operativa que permita tomar decisiones desde la vista de casos.

Contexto Actualmente Sagicc permite visualizar las empresas en una vista Kanban utilizando etiquetas para representar la etapa en la que se encuentra cada empresa. Esta funcionalidad es útil para clasificar clientes, pero presenta una limitación importante cuando se utiliza para administrar procesos de negocio. Problema La empresa es una entidad relativamente estática. Lo que realmente evoluciona dentro de la operación son los procesos que esa empresa genera. En Sagicc esos procesos están representados por los casos. Una misma empresa puede tener múltiples casos simultáneamente, cada uno avanzando por un flujo diferente. Por esta razón, utilizar la empresa como tarjeta del Kanban limita la capacidad del sistema para representar la realidad operativa. Ejemplo comercial Empresa: Technologistic La empresa puede tener simultáneamente los siguientes casos: Caso 1: Implementación de un Agente IA. Caso 2: Integración con ERP. Caso 3: Compra de nuevas licencias. Cada uno corresponde a una oportunidad diferente y cada uno puede encontrarse en una etapa distinta del proceso comercial. Por ejemplo: Caso 1 → Propuesta enviada Caso 2 → Negociación Caso 3 → Implementación Si el Kanban representa únicamente a la empresa, no es posible visualizar estos tres negocios de forma independiente. Ejemplo de soporte En una campaña de soporte técnico ocurre exactamente lo mismo. La empresa puede tener varios incidentes abiertos al mismo tiempo: Incidente de telefonía. Incidente de WhatsApp. Incidente de reportes. Cada uno recorre un flujo diferente: Abierto. En análisis. Primer nivel. Segundo nivel. Pendiente del cliente. Resuelto. Cerrado. El Kanban debe mostrar el avance de cada caso y no únicamente la empresa. Propuesta Adicionar la funcionalidad de Kanban a la vista de Casos. Cada tarjeta del Kanban debería representar un caso y no una empresa. Las columnas del tablero corresponderían a los estados definidos para la campaña. Por ejemplo: Campaña Comercial Prospecto Calificado Descubrimiento Propuesta Negociación Contrato Implementación Ganado Perdido Campaña de Soporte Abierto En gestión Escalado Nivel 1 Escalado Nivel 2 Pendiente del cliente Resuelto Cerrado Cada campaña podría definir su propio flujo de trabajo y el Kanban reflejaría ese proceso específico. Beneficios Este enfoque permitiría: gestionar múltiples negocios para una misma empresa; administrar varios incidentes simultáneamente; visualizar el estado real de cada proceso; medir tiempos por etapa; mejorar el seguimiento operativo; adaptar el Kanban a cualquier tipo de campaña. Conservación del Kanban de Empresas La vista Kanban actual de Empresas podría mantenerse como una herramienta de clasificación o segmentación de clientes. Sin embargo, no debería ser el mecanismo principal para administrar procesos operativos. La gestión de procesos pertenece a los casos. Principio de diseño Las empresas representan al cliente. Los casos representan el trabajo que se realiza para ese cliente. Por esta razón, el Kanban debe modelar la evolución del trabajo y no la evolución del cliente. En consecuencia, la unidad natural de un tablero Kanban dentro de Sagicc debería ser el caso, permitiendo que una misma empresa tenga múltiples tarjetas activas en diferentes campañas y en diferentes etapas de manera simultánea.

Contexto Actualmente, la hoja de vida de un cliente permite consultar el historial de casos asociados a una empresa o persona. Esta funcionalidad proporciona una visión centralizada del historial del cliente. Sin embargo, la lista de casos no indica a qué campaña pertenece cada uno. Problema En organizaciones que utilizan múltiples campañas, un mismo cliente puede tener casos abiertos o históricos en diferentes procesos, por ejemplo: Soporte Técnico. Mesa de Ayuda. Comercial. PQRS. Facturación. Cobranza. Servicio al Cliente. Hoy, al visualizar la lista de casos, el usuario no puede identificar de manera inmediata desde qué campaña fue generado cada uno. Para conocer esa información es necesario abrir el caso individualmente, lo que incrementa el tiempo de consulta y dificulta comprender el historial completo del cliente. Propuesta Incorporar una nueva columna "Campaña" dentro del listado de casos de la hoja de vida del cliente. Ver foto adjunta

Contexto Como parte de la evolución del modelo de empresas en Sagicc, proponemos incorporar campos personalizados para almacenar información estructurada propia de cada empresa. Sin embargo, el verdadero valor de esta información aparece cuando puede utilizarse para consultar, segmentar y administrar la base de clientes. Actualmente la vista de Clientes muestra únicamente la información básica registrada para cada empresa o persona. Situación actual Hoy la información disponible en la lista de clientes es muy limitada e incluye principalmente: Tipo de cliente.Tipo de identificación.Número de identificación.Nombre.Fecha de creación. Cuando un cliente necesita clasificar o segmentar su base de empresas utilizando otros criterios, no dispone de herramientas para hacerlo. Como alternativa se ha propuesto utilizar etiquetas. Sin embargo, las etiquetas presentan varias limitaciones: No son datos estructurados.No garantizan consistencia en la información.Son difíciles de controlar en organizaciones grandes.No permiten construir filtros robustos sobre atributos del cliente. Las etiquetas cumplen un propósito diferente y no deberían reemplazar información estructurada de la empresa. Propuesta Permitir que la vista de Clientes pueda mostrar como columnas los campos personalizados definidos para la empresa. Cada organización debería decidir qué información desea visualizar dentro del listado. Ejemplos: Sector.Industria.País.Ciudad.Cantidad de usuarios.Cantidad de empleados.Partner responsable.Segmento.Cliente estratégico.Estado.Nivel de prioridad. Filtros Además de visualizar estas columnas, los usuarios deberían poder construir filtros utilizando dichos atributos. Por ejemplo: Empresas del sector salud.Empresas del sector inmobiliario.Empresas de Colombia.Empresas de México.Empresas con más de 500 empleados.Empresas con más de 100 usuarios.Empresas clasificadas como clientes estratégicos.Empresas administradas por un partner específico. Beneficios Esta funcionalidad permitiría: segmentar la base de clientes de manera estructurada;realizar búsquedas mucho más precisas;facilitar campañas comerciales;mejorar el trabajo de Customer Success;simplificar la administración de clientes corporativos;preparar la información para futuras automatizaciones e inteligencia artificial. Principio de diseño Los atributos permanentes de una empresa no solo deben poder almacenarse, sino también consultarse, filtrarse y visualizarse dentro de la herramienta. Los campos personalizados adquieren verdadero valor cuando hacen parte de las capacidades de búsqueda, segmentación y administración de clientes. Por esta razón, la evolución de la ficha de la empresa debe ir acompañada de una evolución equivalente en la vista de Clientes, permitiendo que la información estructurada se convierta en una herramienta de trabajo para toda la organización y no únicamente en un dato almacenado.

Contexto Actualmente la ficha de una empresa en Sagicc contiene únicamente un conjunto reducido de campos estándar, como: Fecha de creación.Usuario asignado.Tipo de documento.Número de documento.Nombre de la empresa.Clientes relacionados. Sin embargo, en muchos proyectos es necesario almacenar información adicional propia de la empresa para segmentarla, consultarla y utilizarla en la operación diaria. Hoy esta necesidad no está cubierta de forma adecuada. Situación actual Cuando un cliente necesita almacenar información adicional de una empresa, la alternativa más utilizada ha sido crear una Cuenta asociada a esa empresa y registrar allí la información. Por ejemplo: Sector económico.País.Ciudad.Cantidad de empleados.Cantidad de usuarios de Sagicc.Tamaño de la empresa.Cliente estratégico.Canal de atención.Comentarios generales.Observaciones permanentes. En nuestra implementación incluso hemos adoptado la práctica de crear una cuenta utilizando el mismo número de documento de la empresa para poder almacenar esta información. Aunque funciona, en la practica toca crear para cada cliente la estructura de campos de manera manual, lo ideal es que funcione como los formularios de gestion de un caso, definir los campos y poder llenarlos con listas de seleccion etc. Alternativa evaluada Otra posibilidad consiste en registrar esta información dentro de un caso mediante formularios de gestión. Sin embargo, esta solución presenta varias limitaciones: La información queda asociada únicamente a un caso.Si el caso se cierra, la información pierde visibilidad.Si posteriormente se crea otro caso para la misma empresa, es necesario volver a capturar los mismos datos.No existe una única versión de la información de la empresa.No es posible utilizar estos datos para segmentar empresas de manera eficiente. En consecuencia, los formularios de los casos son adecuados para capturar información relacionada con una interacción específica, pero no para almacenar información permanente de la empresa. Propuesta Incorporar en la ficha de la empresa un mecanismo de campos personalizados, similar al que hoy existe para los formularios de gestión de casos. Estos campos deberían permitir crear atributos estructurados de diferentes tipos, por ejemplo: Texto.Número.Fecha.Lista desplegable.Selección múltiple.Sí/No.Casillas de verificación. Cada organización podría definir qué información desea almacenar sobre sus empresas sin necesidad de desarrollos adicionales. Casos de uso Algunos ejemplos de información que los clientes desean registrar directamente sobre la empresa son: Sector económico.País.Ciudad.Tamaño de la empresa.Número de empleados.Número de usuarios contratados.Segmento.Canal de adquisición.Partner responsable.Nivel de prioridad.Cliente estratégico.Observaciones permanentes. Beneficios Disponer de estos campos directamente sobre la empresa permitiría: filtrar empresas por cualquier atributo;segmentar clientes para campañas o análisis;generar reportes por características de la empresa;evitar duplicidad de información;mantener una única fuente de información permanente de la cuenta. Principio de diseño Debe existir una diferencia clara entre la información permanente de la empresa y la información específica de un caso. La ficha de la empresa debe almacenar información maestra, reutilizable y consultable en cualquier momento. Los formularios de los casos deben registrar únicamente la información correspondiente a una interacción puntual. Separar estos dos niveles de información mejora la calidad de los datos, facilita la segmentación y fortalece el modelo B2B de Sagicc.

Contexto Actualmente Sagicc permite visualizar claramente el usuario responsable (Owner) tanto en la vista del caso como en la hoja de vida del cliente. Una vez existe una asignación, el usuario puede: visualizar el responsable;cambiarlo;eliminar la asignación. Sin embargo, existe una limitación importante: la primera asignación no puede realizarse desde estas vistas. Problema Cuando un cliente aún no tiene un Owner asignado, el agente o supervisor no encuentra una opción para asignarlo directamente desde el caso ni desde la hoja de vida del cliente. Esto obliga a buscar otros módulos o realizar pasos adicionales para completar una tarea que normalmente surge durante la atención del cliente. En la práctica, la necesidad de asignar un responsable aparece precisamente cuando se está atendiendo el primer caso de ese cliente. Propuesta Completar el ciclo de gestión del Owner permitiendo que, desde los mismos lugares donde hoy se visualiza la información, también pueda realizarse la asignación inicial. La funcionalidad debería permitir, según los permisos del usuario: asignar un Owner cuando aún no existe;cambiar el Owner existente;eliminar la asignación cuando sea necesario. Todo ello sin abandonar la vista del caso o la hoja de vida del cliente. Alcance Es importante aclarar que esta asignación corresponde al cliente (persona o empresa) y no al caso. El caso puede seguir teniendo su propio agente o responsable operativo, pero el Owner representa el responsable permanente de la relación con ese cliente. Son dos conceptos diferentes que deben coexistir. Beneficios Reduce pasos operativos.Facilita la asignación del responsable desde el momento en que se detecta la necesidad.Incrementa el uso de la funcionalidad de Owner.Mejora la continuidad en la atención y el seguimiento de clientes.Mantiene toda la gestión dentro del flujo natural de trabajo del agente. Principio de diseño Si una pantalla permite visualizar, editar y eliminar un atributo, también debería permitir crearlo cuando aún no existe. Completar este flujo hace que la funcionalidad sea consistente y evita que los usuarios tengan que salir del contexto de atención para realizar una acción básica.

Separación entre Empresas (Cuentas) y Personas (Contactos) Contexto Durante los últimos meses varios clientes B2B, entre ellos Steckerl y Technologistic que se fue, nos han manifestado la misma necesidad. Inicialmente puede parecer una funcionalidad propia de un CRM, pero al analizar el problema encontramos que realmente corresponde a una limitación del modelo de datos de Sagicc. Actualmente Sagicc maneja empresas y personas dentro de una única entidad de cliente. Aunque existe la posibilidad de relacionar personas con empresas en la hoja de vida del cliente, esta relación es únicamente informativa y no participa en la operación diaria del sistema. Como consecuencia, los casos, conversaciones, tickets e interacciones quedan asociados únicamente al registro con el que se atendió la conversación, sin generar una visión consolidada de la empresa a la que pertenece esa persona. Problema actual Hoy, cuando un empleado de una empresa contacta la mesa de ayuda, normalmente el asesor termina agregando el correo electrónico o el número celular directamente en el perfil de la empresa. Con el tiempo ocurre lo siguiente: Una empresa termina teniendo decenas de teléfonos.Una empresa termina teniendo múltiples correos electrónicos.No es claro a quién pertenece cada dato de contacto.Se requiere crear etiquetas ("Juan", "Gerencia", "TI", etc.) para intentar identificar cada dato.Los casos quedan asociados únicamente al registro utilizado en la atención. Esto genera pérdida de información y dificulta el seguimiento de los clientes corporativos. Cómo funcionan los CRM modernos La mayoría de los CRM manejan dos entidades claramente diferenciadas: Cuenta (Empresa) Representa la organización cliente. Ejemplos: Banco XYZTechnologisticSteckerl Contacto (Persona) Representa cada individuo que trabaja en esa organización. Ejemplos: Juan PérezMaría GómezCarlos Rodríguez Cada contacto pertenece a una empresa, pero conserva su propia información: nombrecorreoteléfonoscargohistorialconversacionestickets Lo que debería ocurrir en Sagicc Cuando Juan Pérez escribe al soporte: El caso pertenece a Juan Pérez.Juan Pérez pertenece a Technologistic.El caso automáticamente también pertenece a Technologistic. Esto permite tener dos vistas simultáneas: Vista de la persona Historial individual.Conversaciones.Tickets.Canales utilizados.Datos de contacto. Vista de la empresa Todos los contactos registrados.Todos los casos de todos sus empleados.Indicadores consolidados.SLA de la empresa.Historial completo de la cuenta. Beneficios para los clientes Este modelo permite responder preguntas que hoy Sagicc no puede responder fácilmente: ¿Cuántos casos ha tenido esta empresa este mes?¿Qué empleados han reportado más incidentes?¿Qué áreas generan más solicitudes?¿Cuál es el SLA consolidado de la empresa?¿Cuántas personas diferentes han interactuado con nosotros?¿Qué contacto es el principal responsable dentro del cliente? Caso real En campañas de soporte técnico esto es especialmente importante. Ejemplo: Empresa: Technologistic Contactos: Juan Pérez (TI)María Gómez (Compras)Carlos Ruiz (Operaciones) Cada uno abre casos independientes. Hoy Sagicc termina almacenando: Empresa: Technologistic Teléfonos: 300...315...320... Correos: juan@maria@carlos@ Sin conocer claramente a quién pertenece cada uno. El resultado es una ficha de empresa desorganizada y sin trazabilidad. Con un modelo Empresa–Contacto: Technologistic tendría su propia ficha corporativa. Cada persona tendría su ficha individual. Los casos quedarían relacionados automáticamente tanto con la persona como con la empresa. Impacto estratégico Esta evolución no busca convertir a Sagicc en un CRM tradicional. Busca fortalecer el modelo de datos para clientes B2B, permitiendo atender correctamente organizaciones donde múltiples personas interactúan con la mesa de servicio. Es una capacidad presente en prácticamente todos los CRM modernos porque responde a una necesidad estructural del mercado B2B y no a una funcionalidad comercial adicional. Incorporar este modelo permitiría a Sagicc ofrecer una experiencia mucho más sólida para clientes corporativos, mejorar la trazabilidad de los casos, facilitar el análisis de indicadores por empresa y acercar el producto a las expectativas que tienen los clientes cuando administran relaciones B2B complejas.

Actualmente, en el apartado de creación de mailing, no existe una opción para guardar estructuras o diseños base. Esto obliga a maquetar cada campaña desde cero, volviendo el proceso repetitivo e ineficiente. Propuesta: Añadir la funcionalidad de "Guardar como plantilla/esquema" dentro del editor de mailing. De esta forma, se pueden almacenar layouts predefinidos (estructuras de cabeceras, columnas, botones y pies de página) para usarlos como punto de partida en futuros envíos. Impacto y Beneficios: Ahorro de tiempo crítico: Optimiza drásticamente el flujo de trabajo del diseñador y agiliza el lanzamiento de campañas masivas. Autonomía y retención de clientes: Los clientes finales podrán autogestionar sus correos de forma más rápida, reduciendo la fricción con la plataforma. Consistencia de marca: Permite mantener estructuras estandarizadas y profesionales sin esfuerzo adicional en cada envío.

seria util que en las condiciones de ultima interaccion ya sea del agente o del cliente en las reglas de negocio sea tenido en cuenta valores inferiores a una hora, que se pueda trabajar por medio de minutos, esto ayudaria a los clientes, ya que hay algunos que sus tiempos de gestion son inferiores a una hora y existen clientes que pueden dejar de responder en algun momento cuando estan en interaccion con el bot y los casos se represan en la recepcion y no pueden ser gestionados por los agentes antes de la hora.

seria excelente que el app mobile se pueda hacer llamadas por llamada saliente. ojala lograran implementarlo. saludos camilo

Actualmente tengo un caso de un cliente del sector salud que requiere aplicar análisis de sentimiento e IA sobre respuestas de encuestas de satisfacción enviadas a pacientes. Hoy el análisis de sentimiento en Sagicc se ejecuta principalmente sobre la información contenida en un caso/interacción. Sin embargo, cuando las encuestas se responden mediante links, las respuestas no necesariamente quedan asociadas al caso, lo que limita el uso de estas capacidades de IA sobre los comentarios de la encuesta. Sería interesante evaluar alguna alternativa funcional o técnica que permita relacionar las respuestas de encuestas con los casos/interacciones, manteniendo al mismo tiempo las capacidades actuales del módulo de encuestas y dashboards.

Como oportunidad de mejora, sería interesante incorporar una funcionalidad de creación rápida de casos enfocada en operaciones B2C y ventas retail, especialmente para escenarios donde los asesores únicamente cuentan con el número telefónico del prospecto. La propuesta consiste en permitir que, desde la búsqueda avanzada, el asesor pueda crear un caso de manera inmediata utilizando solo el dato de contacto. El sistema validaría automáticamente si el cliente ya existe: Si existe el cliente con el dato contacto, se crea el caso asociado al cliente encontrado.Si no existe, se habilita un botón independiente de “Crear caso con cliente vacío”, generando un registro básico temporal para continuar rápidamente con la gestión y contacto del lead. Esta mejora permitiría agilizar el contacto inicial con prospectos, reducir tiempos operativos y optimizar la atención en campañas de alto volumen. ya que solo seria necesario un dato contacto para crear el caso, sin llenar el actual flujo para la creación de un caso.

Cordial saludo. Como propuesta de mejora para el cliente Avsa, se sugiere evaluar la incorporación de las imágenes de los artículos seleccionados desde el catálogo de WhatsApp dentro del mensaje de la interacciones generada al proceder con el pedido Actualmente, al momento en que el cliente selecciona un producto y se crea el caso en la plataforma, únicamente se recibe información relacionada con la orden, como identificador, costo y demás datos asociados al pedido; sin embargo, no se visualiza el artículo seleccionado ni su imagen correspondiente. Contar con esta información permitiría una mejor trazabilidad y brindaría mayor contexto a los televendedores durante el proceso de atención y gestión de la compra realizada por el cliente. Se comparten imagenes de como llega la interaccion a la instancia del cliente,se visualiza el catalogo con sus imagenes y como se ve en el chat el articulo seleccionado.