¡Cuéntanos tu idea!

Cliente requiere trascripcion de la llamada despues que se finalice conversacion

Sería de gran provecho mantener lo escrito en el apartado del caso al salir de la visual ya sea intencional o producto de una llamada entrante, ocurre frecuentemente con clientes que tienen activa la casilla de permitir llamadas entrantes en estado de gestión

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, para cargar un audio, se aplica ya sea desde soporte o en su defecto, en el apartado de marcador con audio, sin embargo, por la pbx, hay funcionalidades que un cliente puede solicitar y la posibilidad de cargar audios desde sagicc sin la necesidad de contactar al equipo de soporte y que mediante la funcionalidad de planes de marcacion en pbx, puedan darles uso

Quiero buscar un caso por una palabra X que podamos en un buscador poder dar con un caso por palabra especifica.

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.

Actualmente, una vez que el proceso de ejecución de un marcador finaliza, el estado del mismo permanece en “Ejecución”, sin realizarse automáticamente la actualización a “Finalizado”. Se solicita como mejora que, una vez culminado correctamente el proceso del marcador, el sistema actualice automáticamente su estado de “Ejecución” a “Finalizado”, de acuerdo con el resultado real del proceso. Que este comportamiento sea ajustado para que funcione de manera similar al módulo de Mensajería Masiva. Esta actualización permitirá contar con una visualización más precisa del estado de los marcadores, facilitando el seguimiento y control de las ejecuciones realizadas. Asimismo, evitará que los marcadores que ya hayan culminado permanezcan registrados como procesos en ejecución, lo que puede generar confusión al momento de realizar validaciones, seguimientos o identificar procesos que aún se encuentran activos.

Análisis con llamadas almacenadas en una fuente de información, posiblemente Azure. Quieren tomar una muestra de estas llamadas y utilizar IA para transcribirlas y analizar su contenido. El objetivo es identificar qué están reportando los clientes, cuáles son los motivos de contacto más frecuentes y qué tipos de solicitudes o problemas se repiten. A partir de este análisis, quieren determinar cuáles de estos casos podrían ser resueltos directamente por una IA, funcionando como un primer nivel de atención y filtro.

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.

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.

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