¡Cuéntanos tu idea!

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.

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

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.

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.

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.

Haciendo seguimiento a algunas alertas, hay clientes que descargan reportes ejecutandolos con fechas bastante amplias, ej reportes de llamadas de varias campañas, varios agentes con fechas de 6 meses hasta un año o mas, teniendo presente que puede tardar en ejecutar la descarga, encolando otros procesos o generando un pico de consumo alto en cada db, tener una validacion que verifique estos datos y si hay solicitudes grandes, mande esta solicitud a una cola que solo se ejecute en fuera de horario

Se propone implementar un reporte de consumo de Inteligencia Artificial por caso que permita visualizar de manera detallada el uso de los servicios de IA asociados a cada proceso o solicitud. El reporte debería incluir métricas como el número de interacciones, tokens consumidos, usuario responsable y fecha de ejecución. Esta mejora facilitará el seguimiento del consumo, permitirá identificar casos con mayor demanda de recursos, optimizar costos, generar indicadores de eficiencia y respaldar la toma de decisiones sobre el uso de herramientas de IA dentro de la organización. Además, contribuirá a establecer controles de consumo, detectar oportunidades de optimización y planificar de forma más precisa la capacidad y el presupuesto destinado a estos servicios.

Que cuando un usuario sea eliminado, se desasignen todos los canales que que este tenga asignados en las campañas, esto con el fin de prevenir que al usuario eliminado se le sigan asignando casos.

Se presenta casos en que un usuario nos contacta por determinado canal, se le brinda la información, pero solicita algo adicional, para lo cual, para una mejor atención se le solicita al usuario que nos contacte por otro canal, en estos casos, el aplicativo solo cuenta la interacción del segundo canal, por ejemplo el caso 17270, en que a la usuaria se le atendió por llamada telefónica, se le solicitó que nos contactara por whatsapp, para poder compartirle unos archivos, el agente comenta que al revisar sus interacciones telefónicas, solo le aparace una llamada (caso 17253) y el caso en mención no le aparece, se ve reflejada solo la interacción por WhatsApp. Primer adjunto: interacción caso 17270 en ambos canales Segundo adjunto: Registro de llamadas de la asesora el día de hoy Tercer adjunto: Evidencia de que solo registra el caso como WhatsApp y no como llamada.