PostHog
Contexto de ingeniería a partir de comentarios de clientes

PostHog necesitaba contexto del cliente dentro de GitHub, no otro panel de feedback

PostHog se envía en público y recibe feedback desde GitHub, Zendesk, Slack, correo electrónico, redes sociales, ventas y conversaciones de producto.

Ingenieros y PM necesitaban contexto del cliente donde ya trabajan — especialmente en incidencias (issues) de GitHub.

BuildBetter puede ayudar recopilando feedback cualitativo, manteniendo el contexto de origen adjunto y vinculando detalles relevantes del cliente de vuelta a las incidencias que los ingenieros y PM ya siguen.

6
feedback sources in scope: GitHub, Zendesk, Slack, email, social, and calls
50%
less manual feedback collection
2x
more interactions captured

The Pull

PostHog intentaba conectar el feedback de usuarios con el trabajo de ingeniería que ya estaba ocurriendo en GitHub.

Su configuración actual les bloqueaba porque el feedback vivía en llamadas, incidencias de GitHub, tickets de Zendesk, hilos de Slack, correos electrónicos y publicaciones en redes sociales.

BuildBetter lo desbloquea adjuntando contexto del cliente respaldado por la fuente a las incidencias de GitHub para que los ingenieros no tengan que pedirle a alguien que reconstruya la historia a mano.

The Catalyst

El flujo es concreto: una incidencia de GitHub debe llevar la evidencia del cliente que hay detrás.

“Tener incidencias vinculadas automáticamente en GitHub significa que nuestros ingenieros tienen acceso inmediato a contexto detallado. Esto hizo que la colaboración y la priorización fueran directas y efectivas.”

— Anna Szell, PostHog

Before BuildBetter

PostHog tenía mucho feedback de usuarios, pero vivía en demasiados lugares:

  • incidencias de GitHub,
  • tickets de Zendesk,
  • hilos de Slack,
  • correo electrónico,
  • publicaciones en redes sociales,
  • conversaciones de ventas,
  • conversaciones de producto,
  • llamadas de investigación.

Ingenieros y PM necesitaban el “por qué” detrás de una incidencia sin tener que buscar en esas fuentes.

The Blocker

El trabajo no estaba recopilando más feedback.

El obstáculo era conectar el feedback con el objeto de ingeniería que importaba: la incidencia de GitHub.

Si el contexto del cliente se queda en tickets, llamadas, Slack y notas, la ingeniería ve una incidencia vaga y el producto tiene que explicar manualmente por qué importa.

“Estábamos invirtiendo incontables horas ordenando manualmente llamadas y feedback del cliente. Fue un gran drenaje para nuestra productividad y moral.”

— Anna Szell, PostHog

El flujo de trabajo de BuildBetter

Customer feedback from calls, tickets, Slack, email, social, GitHub
    ↓
BuildBetter signal extraction
    ↓
Source-backed context
    ↓
Linked GitHub issue
    ↓
Engineer or PM acts with customer evidence attached

What Changed

  • producto e ingeniería pueden ver contexto del cliente en las incidencias,
  • los ingenieros no tienen que perseguir a los PM para el contexto,
  • el producto no tiene que reconstruir manualmente el historial para cada ticket,
  • el feedback puede informar la priorización dentro de los sistemas donde el trabajo ya ocurre.

“BuildBetter se está convirtiendo en nuestra herramienta principal para la planificación estratégica. Nos permite mantenernos por delante alineando directamente las decisiones de producto con el feedback de los clientes.”

— Anna Szell, PostHog

Próximo caso de estudio

Sonder
Comenzar