SlackGeek no nació como producto ni como plataforma. Empezó como una práctica: revisar cómo se comunican los equipos de producto, soporte y operaciones distribuidos en Argentina, y anotar dónde se pierde el hilo de las cosas. Con el tiempo esa práctica se ordenó en un proyecto de consultoría técnica y comunidad de práctica con base en Buenos Aires.
En la mayoría de los equipos que revisamos, el ruido no viene de la falta de herramientas sino de cómo están configuradas. Un canal donde conviven avisos automáticos, consultas de guardia y coordinación diaria termina silenciado por todos. Una incidencia crítica se pierde entre notificaciones de cambios de estado que no le importan a nadie a las tres de la mañana. Nadie decidió que fuera así: simplemente nadie escribió las reglas.
Por eso el punto de partida siempre es el mismo: mirar los flujos reales antes de proponer cualquier cosa. Qué se escribe, dónde, quién responde y qué pasa cuando nadie responde. Recién después aparecen las plantillas de mensajes, las rutinas de guardia y los criterios de escalado.
Cada equipo tiene su propio cuello de botella. Copiar la arquitectura de canales de otra empresa suele agregar problemas en lugar de resolverlos, así que primero se entiende el caso y después se propone.
Una rutina de guardia que nadie cumple es peor que no tener rutina. Las plantillas y los criterios se ajustan hasta que resultan cómodos de seguir en un día normal, no solo en un documento.
Las automatizaciones de avisos se diseñan para interrumpir solo cuando hay una acción pendiente con plazo. Todo lo demás puede vivir en un tablero de incidencias o en un resumen diario.
Quién puede crear canales, qué política de hilos aplica y qué notificaciones quedan silenciadas fuera de horario debería estar documentado. Si vive solo en la cabeza de quien administra el espacio, se pierde con el próximo cambio de rol.
La comunidad de práctica funciona como extensión de ese método: guías de buenas prácticas, ejemplos de integración con herramientas de tickets y un espacio de preguntas para administradores que configuran permisos, hilos y notificaciones. El tono es claro y técnico, sin promesas infladas. Las imágenes del sitio son ilustrativas y no representan equipos, clientes ni resultados reales.
Si querés que revisemos la arquitectura de canales de tu equipo, alcanza con un correo que describa tres cosas: en qué herramienta trabajan hoy, cuántas personas participan de la coordinación diaria y cuál es el cuello de botella que más se repite. No hace falta un documento formal ni un diagnóstico previo. Los casos que mejor se resuelven son los que llegan con un ejemplo concreto: un canal que nadie lee, una guardia que se saltea, un tablero que se actualiza tarde.
Para contar el caso con detalle, adjuntar capturas de hilos o pegar la estructura de canales actual.
Para consultas puntuales sobre permisos, notificaciones o criterios de escalado que no requieren contexto largo.
Si preferís empezar por lo escrito, la página de contacto reúne el formulario de solicitud con los datos que usamos para preparar la propuesta.
SlackGeek nació de una incomodidad concreta: equipos que trabajan bien, pero pierden horas tratando de entender dónde se dijo qué. No es una plataforma ni un software empaquetado. Es un proyecto de consultoría técnica y una comunidad de práctica que acompaña a equipos de producto, soporte y operaciones distribuidos en Argentina a ordenar su comunicación interna.
Antes de proponer cualquier cambio, se revisan los flujos reales de cada equipo. Se mira cómo se abren las incidencias, quién responde primero, dónde se pierde el hilo y qué avisos nadie lee. Recién después aparecen las propuestas: arquitecturas de canales por función, rutinas de guardia con traspasos escritos, criterios de escalado explícitos y automatizaciones de avisos que solo notifican lo que exige una acción.
Una estructura de canales sirve cuando la gente la usa sin pensarlo. Por eso trabajamos con plantillas de mensajes, convenciones de nombres y documentos breves que cualquiera pueda encontrar en su primera semana. Nada de configuraciones brillantes que dependen de una sola persona para funcionar.
La parte de práctica se apoya en guías de buenas prácticas, ejemplos de integración con herramientas de tickets y un espacio de preguntas para administradores que configuran permisos, hilos y notificaciones. El tono es claro y técnico. No prometemos resultados que no podamos mostrar, ni medimos el éxito por la cantidad de canales creados.
Las imágenes del sitio son ilustrativas y no representan equipos, clientes ni resultados reales.
La mayoría de las veces el problema no es la herramienta: es que nadie acordó qué conversación vive dónde. Un equipo puede tener Slack bien configurado y aun así perder incidencias en un canal de avisos que nadie lee. Por eso el trabajo empieza por revisar los flujos reales de coordinación antes de proponer cualquier cambio de arquitectura. Ese punto de partida es lo que nos separa de una guía genérica descargada de internet.
No llegamos con una estructura de canales cerrada para pegar en cualquier espacio de trabajo. Primero miramos cómo se asignan los tickets, quién cubre la guardia y por dónde se escalan las urgencias. Recién después proponemos nombres de canales, rutinas de traspaso y criterios de escalado que encajen con esa realidad. Si algo no se va a cumplir, preferimos no dejarlo escrito.
Una configuración sin documentación se rompe en cuanto cambia una persona. Por eso cada decisión de permisos, política de hilos y notificaciones por defecto queda registrada en un documento breve y accesible. Así, quien administra el espacio de trabajo puede explicar por qué un canal no interrumpe fuera de horario, y el equipo no depende de la memoria de una sola persona para mantener el orden.
Si querés ver el método completo antes de decidir, podés leer cómo trabajamos en el proyecto o escribirnos directamente desde la página de contacto.
SlackGeek trabaja con equipos de producto, soporte y operaciones distribuidos en Argentina que necesitan ordenar su comunicación interna. No vendemos software ni licencias: acompañamos a revisar cómo se comunican hoy y a proponer una estructura que resista el uso diario, sin depender de que alguien la recuerde de memoria.
El método es artesanal. Se miran los flujos reales de cada equipo, se detectan los cuellos de botella en la coordinación cotidiana y recién entonces se proponen arquitecturas de canales, rutinas de guardia, criterios de escalado y automatizaciones de avisos. La prueba de que algo funciona es simple: la gente lo usa sin que haya que insistirle.
Usamos cookies propias para recordar tu elección y mantener el sitio funcionando como corresponde. No activamos cookies de medición ni de terceros sin tu consentimiento.
Puedes aceptar o rechazar su uso ahora mismo. Si quieres más detalle, consulta nuestra política de privacidad.