Un documento útil de requisitos para un CRM explica qué recorrido del cliente debe soportar el sistema, quién responde de cada traspaso, qué información hace falta y cómo comprobará el equipo que funciona. También delimita la primera versión y recoge las decisiones pendientes. Una lista de funciones como cuadros de mando, automatizaciones e integración con el correo no basta para encargar la implantación.

Empieza por un recorrido que hoy genere seguimiento manual o peticiones repetidas de información. Conviértelo en requisitos que quienes hacen el trabajo puedan reconocer y probar. Podrás ampliar el documento cuando el enfoque esté claro.

Acordar qué problema debe resolver el CRM

“Necesitamos un CRM mejor” deja demasiado margen a la interpretación. Pregunta qué tarea no puede realizar hoy una persona de forma fiable.

Puede que ventas no vea de dónde llega una consulta. Que marketing no sepa si un presupuesto acabó en pedido. O que, cuando falta un responsable de cuentas, nadie sepa qué clientes esperan respuesta. Son problemas distintos, aunque una misma herramienta pueda ayudar con todos.

Describe lo observado, su consecuencia y la evidencia disponible. Si nadie ha medido el tiempo que se dedica a pedir actualizaciones, deja esa cifra como desconocida. No conviertas una estimación en una promesa de ahorro.

Concreta el resultado buscado: una persona puede identificar la siguiente acción y su responsable sin revisar distintos buzones. Así el equipo tendrá algo que comprobar.

Delimitar dónde empieza y termina el proceso

Elige un límite como “desde que llega una consulta de la web hasta que una persona acepta la responsabilidad de la siguiente acción”. Decide por separado si la aprobación de presupuestos, la entrega y la posventa entran en esta versión.

Revisa ejemplos recientes con las personas implicadas, incluyendo alguno que exigiera una solución provisional. La guía de mapeo de procesos explica cómo descubrir los pasos reales, las esperas y los traspasos. El documento de requisitos da el siguiente paso: especificar qué deben permitir el sistema futuro y la rutina de trabajo.

La guía de implantación de Microsoft recomienda derivar los requisitos de los procesos documentados y probar el proceso completo. Aunque está escrita para Dynamics 365, ofrece un punto de partida útil para conversar con cualquier proveedor de implantación de CRM.

Dar a cada requisito el detalle necesario para decidir

LUKiN recomienda una ficha breve para cada requisito. Asígnale un identificador para poder seguirlo en la propuesta del proveedor, las decisiones de configuración y las pruebas.

  • Problema observado: qué ocurre ahora y de dónde procede la evidencia.
  • Comportamiento necesario: qué debe poder hacer una persona, expresado en el lenguaje de su trabajo.
  • Responsable y traspaso: quién responde de la siguiente acción y cómo acepta otra persona esa responsabilidad.
  • Información: qué campos hacen falta, de dónde salen y quién los mantiene.
  • Excepciones: qué ocurre cuando faltan datos, una persona no está disponible o el caso no encaja en el recorrido habitual.
  • Prueba de aceptación: qué ejemplo utilizará el equipo para demostrar que se cumple el requisito.
  • Decisión de alcance: si hace falta para el lanzamiento, puede esperar o necesita más análisis, con el motivo.
  • Dependencia pendiente: qué decisión, integración o aportación falta para completar el trabajo y quién debe resolverla.

La ficha no necesita convertirse en una gran especificación. Pero alguien que no haya participado en las conversaciones debe entender qué se pide y qué preguntas siguen abiertas.

Ejemplo: comprobar el traspaso de una consulta

Este requisito es ilustrativo. No describe un resultado de cliente ni una norma que todas las empresas deban adoptar.

CRM-01: responsabilidad sobre una consulta nueva. El equipo receptor necesita ver quién se encarga de una consulta entrante y cuál es el siguiente paso, también cuando falta la persona habitual.

El responsable del proceso y el proveedor podrían acordar demostrarlo con estas comprobaciones:

  1. Crear una consulta de prueba por el canal previsto. Confirmar que su origen y fecha de recepción siguen visibles.
  2. Asignarla a una persona responsable. Comprobar que quienes tienen el acceso adecuado pueden ver la siguiente acción.
  3. Reasignarla durante una ausencia. Confirmar que quedan claros el nuevo responsable y cualquier acción pendiente.
  4. Enviar una consulta con información incompleta. Comprobar que entra en un circuito de revisión acordado en lugar de desaparecer de la vista del equipo.
  5. Volver al registro original. Confirmar que se entiende su evolución sin depender de una conversación privada por correo.

Acuerda con el equipo las expectativas de respuesta y el circuito de escalado. “Hacer seguimiento automático” sigue siendo una petición incompleta si nadie ha decidido cuándo toca responder, quién atiende la respuesta o qué ocurre si falla la automatización.

Resolver las decisiones sobre datos antes de hablar de integraciones

Para cada campo, pregunta qué acción o decisión permite tomar. “Quizá nos interese más adelante” es un motivo débil para hacerlo obligatorio.

Si importa el origen de las consultas, acuerda las categorías, quién lo registra y qué hacer cuando se desconoce. Distingue el origen inicial de las interacciones posteriores con marketing si el equipo necesita ambos datos. De lo contrario, un informe puede responder a una pregunta distinta de la que pretendía hacer dirección.

Identifica qué sistema aporta los datos del cliente y quién resuelve los registros contradictorios. Describe qué debe ocurrir con los duplicados y las transferencias fallidas. Una integración necesita un procedimiento de recuperación además de una conexión que funcione.

Recoge qué roles necesitan consultar, modificar o exportar información. Pide a los responsables técnicos y de gobierno del dato que confirmen los controles y requisitos de conservación. Evita rellenar los huecos del documento con suposiciones sobre la configuración del programa.

Separar la primera versión de las mejoras posteriores

La primera versión necesita un proceso coherente. Priorizar funciones aisladas puede dejar un formulario impecable conectado a un traspaso con ventas que nadie ha resuelto.

Para cada requisito propuesto, pregunta:

  • ¿Qué impediría que el proceso acordado funcionara si faltara este requisito?
  • ¿Existe un método provisional aceptable, con un responsable?
  • ¿De qué otro requisito o equipo depende?
  • ¿Qué evidencia justificaría incluirlo en una versión posterior?

Documenta qué se aplaza y explica la consecuencia. Utiliza la guía de priorización de proyectos para las decisiones más amplias si varias iniciativas necesitan a las mismas personas. Incluso un alcance reducido exige tiempo para pruebas y cambios en el trabajo diario.

Revisar el documento con quienes van a utilizarlo

Recorre el proceso propuesto con marketing, ventas y el equipo que recibe después el trabajo. Pide a alguien que represente a la persona ausente, al cliente que vuelve o a quien corrige un registro. Esas situaciones hacen aflorar decisiones que una demostración estándar del producto puede pasar por alto.

La guía del Service Manual de GOV.UK sobre necesidades de usuarios destaca la observación de usuarios reales y la necesidad de tratar las opiniones sin respaldo como supuestos. Se refiere a servicios públicos, pero la distinción resulta útil aquí: una función solicitada por un responsable también debe contrastarse con el trabajo real del equipo.

Pide al proveedor que explique cómo cubrirá cada requisito prioritario, qué incluye su propuesta y qué sigue siendo una decisión del negocio. Conserva esas respuestas junto a los identificadores. En la aceptación, revisa el recorrido completo, incluyendo las excepciones y los pasos provisionales acordados.

Qué muestra el trabajo relacionado de LUKiN

En el caso de organización de marketing y preparación para un CRM, un pequeño equipo introdujo visibilidad compartida de tareas y planificación trimestral mientras documentaba los traspasos con clientes antes del despliegue del CRM. El propio equipo implantó los cambios con el apoyo de LUKiN. La implantación general del CRM seguía en curso bajo la responsabilidad de otro equipo.

Esta distinción ayuda a definir el apoyo necesario. Organizar el trabajo del equipo y aclarar sus requisitos es una intervención concreta. Configurar, migrar y lanzar el CRM es otra, con sus propios responsables y decisiones de aceptación.

Si la dificultad está en acordar el proceso antes de encargar el trabajo a un proveedor, explora la consultoría de mejora de procesos. Si todavía no está claro si el problema principal es la carga de trabajo, las responsabilidades o los propios sistemas, un Diagnóstico de Rendimiento Operativo puede ayudar a definir el punto de partida.

Fuentes

La ficha y el ejemplo anteriores son recomendaciones prácticas de LUKiN. No constituyen una especificación de configuración para un producto concreto.