La gestión de relaciones con clientes en Chronicle

Una relación con un cliente debe perdurar aunque cambie la herramienta de proyectos, el proveedor de pagos o la persona responsable. Ese principio orientó nuestro trabajo en Chronicle: dar un lugar estable a los datos comerciales y conectar después los sistemas que los utilizan.

Ampliamos nuestra plataforma Drupal para gestionar posibles clientes, oportunidades de servicios y actividad de los clientes. El trabajo puso de manifiesto una pregunta recurrente de diseño: ¿cuándo debe una función nueva reutilizar un registro existente y cuándo necesita uno propio?

Empiece por el registro que debe perdurar

Ya guardábamos los datos de facturación del cliente en un perfil de cliente de Drupal asociado a un usuario. Conservamos ese modelo. La relación comercial se identifica mediante un número de cuenta emitido por W&L, no mediante el identificador de cliente de un proveedor de pagos.

Esta decisión evitó crear otra cuenta con un segundo conjunto de campos de facturación. También dejó espacio para una futura cuenta de empresa compartida si varias personas necesitan acceder a las mismas facturas. Añadiremos esa estructura cuando el flujo de trabajo la necesite.

Un posible cliente no es una cuenta de acceso

Una consulta puede dar lugar a una conversación, una propuesta o nada. Ninguno de esos hechos debe conceder acceso a un portal de clientes.

Por eso, los posibles clientes se guardan en registros de contacto privados. Las oportunidades contienen la etapa, la persona responsable y la siguiente acción. El personal vincula una identidad de cliente existente cuando confirma un documento de alcance del trabajo firmado. El acceso al portal sigue siendo un paso administrativo independiente, con Paladin a cargo de la identidad.

Las pruebas concretaron este límite. El selector habitual de usuarios de Drupal excluye las cuentas bloqueadas. Esto resulta razonable para muchos flujos de acceso, pero el personal necesita registrar actividad antes de que se active la invitación de un cliente. Añadimos un selector de referencias comerciales exclusivo para el personal y comprobamos que los clientes no pudieran utilizarlo.

Asigne una función a cada sistema

Chronicle mantiene la relación y el registro comercial. Jira mantiene las tareas de ejecución. La oportunidad guarda las claves de Jira para que el personal pueda pasar de un sistema a otro sin convertir el estado del proyecto en la referencia de una venta.

Los documentos de alcance del trabajo, las facturas y los entregables permanecen asociados al usuario del cliente bajo File Gate. El CRM guarda una referencia al documento de alcance aprobado y a su revisión. No pasa a ser propietario del documento.

Esta distinción tenía consecuencias en Drupal. Un campo Entity Reference Revisions puede cambiar la entidad principal de un párrafo. Un tipo de campo cómodo habría incumplido nuestra regla de propiedad documental. Una referencia sin propiedad, con metadatos de revisión protegidos, conservó tanto la ubicación del documento como la evidencia del cierre de la oportunidad.

Un modelo correcto también necesita una interfaz útil

La primera versión superó las comprobaciones de acceso y flujo de trabajo, pero su uso en staging reveló un problema más sencillo: parecía un conjunto de formularios de administración. Abrir una oportunidad llevaba directamente a editar sus campos. El personal necesitaba contexto antes de necesitar un formulario.

Estudiamos las páginas de registros de Attio, la vista de negocios de Pipedrive y la bandeja de entrada de Close. Cada una aportó una enseñanza útil sobre cómo mantener la siguiente acción cerca del historial de la relación.

La siguiente versión da a cada oportunidad su propio espacio de trabajo: etapa, siguiente paso, contactos y actividad reciente, con la edición como acción secundaria. Al registrar una interacción, la oportunidad ya está seleccionada y, al terminar, el personal vuelve a la misma página. Los formularios de creación mantienen visible la información obligatoria y agrupan los detalles opcionales.

La página de inicio reúne el trabajo pendiente, los recuentos por etapa y la actividad reciente. Su gráfico cuenta todas las oportunidades que la persona puede consultar. Las listas de trabajo se mantienen breves e indican cuántos registros muestran. Mezclar ambos recuentos haría que un gráfico ordenado contara una historia incorrecta.

La interfaz utiliza nuestra adaptación de un componente Card de ReUI con licencia MIT y la biblioteca Recharts existente, dentro de Gin. Los estilos tienen un alcance local y Drupal sigue ofreciendo HTML utilizable cuando la mejora con React no está disponible. Una plantilla pública puede orientar el diseño; aun así, hay que comprobar la licencia de cada componente de origen.

Coloque las reglas debajo del formulario

Ocultar un botón no es un control de acceso. Situamos los permisos, las transiciones entre etapas y las comprobaciones de revisión en los servicios que guardan los registros. Se rechaza una edición desactualizada. Un reintento debe coincidir con la solicitud original. Marcar una oportunidad como ganada exige el cliente correcto y un documento de alcance del trabajo accesible y aprobado.

La revisión encontró otra forma de eludir las etapas previstas: reabrir una oportunidad perdida o en espera permitía saltar etapas. Vinculamos la reapertura a la última etapa activa y añadimos pruebas de regresión. La enseñanza fue sencilla: comprobar las vías de regreso a un flujo de trabajo con el mismo cuidado que su recorrido normal.

Reutilice los controles y compruebe los límites

Chronicle ya contaba con Field Guard, File Gate, registros de auditoría y Sentinel. El CRM utiliza esos controles. Las herramientas sujetas a controles exponen un conjunto reducido de operaciones para cada función del personal, con límites de registros y resultados restringidos. No ofrecen una exportación general de perfiles de clientes o documentos.

También comprobamos la ejecución directa de las herramientas. Debe repetir la comprobación de acceso, aunque su invocador habitual ya la realice. Y un evento de auditoría solo resulta útil si el registro almacenado conserva los identificadores necesarios para explicar el cambio. Nuestras pruebas comprueban el evento guardado, no solo la llamada que intentó escribirlo.

Para conocer mejor esta base, lea Cómo Chronicle permite auditar las operaciones de contenido.

Mantenga la búsqueda tan privada como el registro

Un índice privado es solo el primer límite. Los resultados de búsqueda pueden sobrevivir a un cambio de permisos o a una edición. Chronicle comprueba cada resultado candidato contra el registro actual y los permisos de sus campos antes de mostrarlo. Si el texto indexado ya no coincide con el registro visible, el resultado espera a que se vuelva a indexar.

Esto cuesta más que devolver sin cambios la respuesta del motor de búsqueda. También impide que títulos, fragmentos y recuentos desactualizados revelen información que el lector ya no puede consultar.

Deje que cada módulo gestione sus comandos

Las reglas comerciales pertenecen al módulo que mantiene los registros. Dimos a los módulos una forma de exponer sus propios comandos sujetos a controles, esquemas y comprobaciones de acceso. El conector descubre los comandos aprobados y los ejecuta a través de Sentinel.

Esto mantiene las reglas del CRM fuera del conector y permite que otros módulos utilicen el mismo contrato. Los adaptadores existentes para el núcleo de Drupal y los módulos de terceros siguen disponibles. Descubrir un comando no concede permiso para ejecutarlo: cada llamada sigue comprobando la credencial, el esquema actual y la política de origen.

Compruebe la solicitud completa

Las pruebas de servicios y las comprobaciones del navegador detectaron problemas distintos. Una prueba integrada del conector reveló uno más: una escritura rechazada podía dejar la siguiente solicitud en espera. Una respuesta transmitida por streaming había regresado antes de terminar su trabajo en la base de datos, y una reversión podía deshacer la liberación de un bloqueo de sesión.

La corrección mantiene la limpieza dentro de la función que transmite la respuesta. La prueba de regresión utiliza el SDK real y el bloqueo de la base de datos, y después comprueba qué sucede tras el rechazo. Un componente puede superar sus propias pruebas mientras sigue fallando la coordinación entre componentes.

El punto de entrada de la línea de comandos necesita el mismo examen. La lógica de recuperación superaba sus pruebas de servicio, pero una opción de confirmación duplicada detenía el comando Drush antes de ejecutarse. Añadimos pruebas con el sitio instalado para el rechazo, la confirmación, el reintento y la exportación. Una prueba debe entrar por la misma puerta que la persona que realiza el trabajo.

Una programación debe producir evidencia, no solo actividad

Añadimos cuatro revisiones periódicas: comprobaciones de recepción en días laborables, una revisión diaria de oportunidades, una comprobación semanal del traspaso a ejecución y una revisión semanal de las fechas de seguimiento. Cada puesto puede reclamar su propia tarea, leer un conjunto limitado de datos y presentar un borrador interno. No puede enviar mensajes ni cambiar un registro comercial.

Chronicle conserva la programación y el historial de ejecuciones. Sentinel controla el acceso. Un ejecutor independiente envía al modelo seleccionado una pequeña selección de los datos de origen: etapas, fechas e indicadores de evidencia. Los datos de contacto, los cuerpos de mensajes, los importes financieros y las credenciales quedan fuera de esa solicitud. Una fecha de seguimiento no demuestra una renovación, y un enlace a un documento no demuestra una firma.

Las primeras pruebas en producción confirmaron por qué estas partes deben permanecer separadas. Un modelo repitió claves JSON hasta alcanzar su límite de salida. Aumentar el límite no ayudó. Conservamos la ejecución fallida, probamos otro modelo con contextos sintéticos vacíos y de tamaño completo, y realizamos una nueva comprobación en producción. La elección del modelo pertenece a una configuración revisada; una respuesta fallida no debe borrar su coste ni su historial.

La ejecución manual tampoco detectó un problema de arranque del servicio: el proceso desatendido no heredaba la configuración del intérprete de comandos que indicaba dónde encontrar su clave de descifrado. Una referencia explícita al archivo resolvió la localización sin introducir la clave en la definición del servicio. Las pruebas deben incluir el proceso que realmente se ejecutará mañana.

Las recomendaciones válidas aparecen en las revisiones operativas del CRM. Una persona comprueba los enlaces de evidencia permitidos y marca el borrador como revisado o descartado. Esa decisión no autoriza a contactar con nadie. La cola también conserva los fallos y el trabajo omitido, para que el silencio no se confunda con una revisión completada.

Diseñe en torno a decisiones, no a un catálogo de campos

Cada campo adicional crea otro dato que mantener. Conservamos los campos necesarios para identificar a un posible cliente, asignar responsabilidades, registrar evidencia y elegir la siguiente acción. El procesamiento de pagos, la sincronización de buzones y las previsiones financieras siguen siendo trabajos independientes.

La medida útil de esta ampliación es si el personal puede responder con confianza a unas preguntas habituales: ¿quién es responsable de la relación, qué se acordó, qué viene después y quién puede verlo? Esas preguntas dieron forma a la implementación.