¡Cuéntanos tu idea!

podrían incluir un modo oscuro para ayudar a proteger la vista de los usuarios.

Actualmente el nodo GEN AI recibe datos del prompt base, prompt user y si está activa la tecnologia RAG, toma los datos de los articulos de base de conocimiento para generar respuestas. Sería de gran ayuda que las respuestas de los nodos webservice puedan ser entregadas a la inteligencia artificial a través de la variable que hoy se maneja para acceder a su contenido, esto corresponde a que recientemente hemos recibido consultas a través de preventas y proyectos de integraciones de IA con iendpoints compartidos por los clientes. Nota: Al día de hoy podemos enviarle al nodo GEN AI el response del webservice, pero solo de un filtro que podamos aplicar con un identificador como nombre o cédula, tocaría imprimir todo el response en la conversación para que el nodo GEN AI tenga el contexto completo.

Buen día Solicitamos evaluar la posibilidad de implementar una funcionalidad que permita generar un enlace único y permanente con código QR para las encuestas de satisfacción. Esta mejora facilitaría el acceso de los pacientes a las encuestas mediante códigos QR ubicados en recepción, salas de espera, resultados diagnósticos y otros puntos de atención, incrementando la tasa de respuesta y reduciendo la dependencia de los enlaces personalizados enviados por campañas masivas. Agradecemos que esta propuesta sea considerada por el equipo de producto y analizada como una posible funcionalidad dentro de la plataforma. Quedamos atentos a sus comentarios.

las plantillas no permite hacer modificación de ya que aparece un texto que interfiere en la función

Buenos días. Comparto una oportunidad de mejora solicitada por el cliente Gases del Caribe, relacionada con el almacenamiento del historial de conversaciones del agente de IA en Voice (IVR). Se requiere que las conversaciones entre el agente de IA y el cliente final se almacenen, incluso cuando no se transfieran a una cola de atención ni a un asesor humano. De esta manera, los administradores y supervisores podrán consultar el historial y, si es posible, escuchar las grabaciones para verificar la información proporcionada por el agente virtual. Agradezco validar la viabilidad de esta funcionalidad.

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

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.

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.

Es clave poder tener habilitado canales salientes y entrantes de llamada por medio de whatsapp, con el Whatsapp Calling API.

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 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.

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.

Descripción de la mejora: Se propone implementar una funcionalidad que permita identificar y diferenciar, dentro de la instancia de Sagicc, las llamadas telefónicas convencionales de las llamadas realizadas a través de WhatsApp. Actualmente, la plataforma no permite distinguir de manera visual o mediante un campo específico el origen de estos dos tipos de llamadas, lo que dificulta su identificación y seguimiento por parte de los clientes o agentes. Objetivo: Facilitar la identificación del canal de origen de cada llamada mediante un indicador visual o un campo informativo que especifique si corresponde a una llamada telefónica convencional o a una llamada de WhatsApp. Resultado esperado: Que los usuarios puedan identificar fácilmente, desde la instancia de Sagicc, si una llamada corresponde a telefonía convencional o de WhatsApp, sin necesidad de realizar validaciones adicionales.

Actualmente, el archivo que se genera posterior al envío no conserva el universo total de pacientes impactados, lo que limita significativamente la medición y el análisis de resultados. Por esta razón, requerimos un desarrollo que permita que la misma base cargada para el envío masivo sea retornada íntegramente en el reporte de resultados, manteniendo el 100% de los registros originalmente enviados. Adicionalmente, sobre esa misma base, necesitamos que se identifique claramente: Pacientes que interactuaron con la plantilla. Pacientes que no registraron interacción. Opción o botón seleccionado por cada paciente cuando aplique. Indicadores que permitan medir efectividad, conversión y cobertura sobre el universo real del envío.