El controller global de Pipedrive nunca había programado: con Gemini creó la app de cierre que sustituyó a la herramienta de NetSuite

En dos frases

Nathaniel Dycus, vicepresidente y controller global de la empresa de CRM Pipedrive, no había escrito nunca una línea de código cuando empezó a pedir ayuda a Gemini para ordenar el cierre mensual de su equipo; unos meses de prompts pequeños y sucesivos después, el equipo cierra con la app web que él construyó en lugar de con la herramienta de gestión del cierre que venía con NetSuite. Es una herramienta modesta a propósito (un checklist compartido con sellos de fecha, plazos, avisos y gráficos), y su lección principal es dónde empezar a construir: al lado del libro mayor, no dentro.

Quién lo hace y por qué es interesante

La fuente es un reportaje de Courtney Vien en CFO Brew, publicado el 17 de julio de 2026 a partir de entrevistas con Dycus y con el director financiero de Pipedrive, Regi Vengalil. CFO Brew presenta a Pipedrive como una empresa estonia de software CRM con 16 años, valorada en 1.500 millones de dólares cuando se convirtió en «unicornio» en 2020 y con más de 800 empleados. La trayectoria de Dycus es contable, no tecnológica: 11 años en PwC y cuatro como SVP de contabilidad en HireVue. Antes de este proyecto, cuenta, su uso de la IA se limitaba a escribir prompts y pedir a los chatbots fórmulas de Excel. «Nunca había programado», dijo su director financiero.

Merece un sitio en este directorio por tres motivos:

• Es una sustitución real, no un prototipo. El CFO afirma que el equipo usa la app en vez de la herramienta de cierre incluida con NetSuite y ofrece una comparación de costes aproximada.
• Hablan quien lo construye y quien firma el presupuesto. El controller explica cómo lo hizo; el CFO, por qué acepta algo que hace menos que la herramienta comercial.
• Marca un límite sensato. Mientras aprendían, se quedaron en Google Sheets y no enviaron ningún asiento a NetSuite. Cualquier equipo puede copiarlo sin pedir permiso de escritura en el ERP.

CFO Brew volvió a publicarlo el 26 de septiembre de 2026 entre sus tres reportajes más leídos de los tres meses anteriores. No hemos encontrado otra cobertura independiente y Pipedrive no ha publicado nada, así que todo el caso descansa en lo que dijeron los dos directivos en esa entrevista.

El problema: un cierre global sostenido por una hoja de cálculo

El equipo de cierre está repartido entre husos horarios de Estados Unidos, Estonia, Reino Unido, Irlanda, Portugal y otros países. Había quien marcaba tareas como completadas o revisadas en días distintos al resto, y costaba ver el cierre «como un único proceso consolidado», en palabras de Dycus. Varios pasos eran manuales y, a su juicio, automatizables: copiar datos de NetSuite a Google Sheets, marcar cuándo se completaba o revisaba cada tarea y actualizar el balance de sumas y saldos cuando algo cambiaba.

El equipo estudió software comercial de cierre, pero la mayoría les pareció «demasiado completo»: no necesitaban «todo el proceso de cierre de principio a fin». El detalle importa: lo que faltaba era coordinación y visibilidad, no motores de conciliación ni automatización de asientos.

Qué construyó, etapa por etapa

Dycus lo describe como «prompts sucesivos que hacían una cosa, y luego un poco más, y un poco más». Según la entrevista:

1. Una barra lateral en Google Sheets (un par de horas). Solo servía para marcar una partida como completada o revisada sin desplazarse en horizontal por muchas columnas.
2. Una app sobre Google Sheets. La barra lateral fue creciendo. La primera versión que el equipo pudo usar de verdad en un cierre le llevó «probablemente unas tres semanas».
3. Una app web, pulida en los meses siguientes con las opiniones del equipo, que «hizo demostraciones e intentó romper la herramienta». Hoy muestra la cronología de cada partida con su estado, permite fijar plazos, enseña lo terminado y lo vencido, y avisa por correo a quien recibe una tarea.
4. Visualización. Con Gemini creó una matriz del cierre y una función de gráficos, por ejemplo de saldos en distintos momentos o comparados con meses anteriores, para que en lugar de mirar «500 filas» el equipo vea cómo va el cierre frente a sus plazos.

También aprovecha el historial: la cronología ayuda a «rebobinar después del cierre y ver dónde estaban los cuellos de botella».

Herramientas y arquitectura: lo que se sabe y lo que deducimos

• Asistente de IA: Gemini. La fuente no dice qué edición (la app de Gemini, Gemini en Google Workspace o Gemini Enterprise) ni qué modelo, ni si Gemini escribió todo el código o le ayudó a escribirlo.
• Datos: Google Sheets, con el checklist del cierre y el balance copiado de NetSuite. La entrevista presenta esa copia como uno de los pasos manuales que quería eliminar, pero no dice que ya esté automatizada.
• La barra lateral: en Google Sheets, las barras laterales personalizadas se hacen con el servicio HTML de Apps Script (documentación de Google). El reportaje no nombra la tecnología, así que es una deducción nuestra, aunque es la vía habitual.
• La app web: no se describe. Apps Script permite publicar un script como aplicación web, pero no sabemos si Pipedrive lo hizo así o cambió de plataforma.
• Avisos: correo al asignar una tarea. Si lo montas con Apps Script, las cuotas de Google limitan los destinatarios de correo al día (100 en cuentas personales y 1.500 en cuentas de Google Workspace cuando lo comprobamos).
• Frontera con el ERP: nada de esto escribe en NetSuite. «No enviábamos asientos a NetSuite, no hacíamos nada que no tuviera arreglo», dijo Dycus. «En el peor de los casos, volvíamos a la misma hoja de Google que teníamos».

Paso a paso para replicarlo

Los pasos son nuestros, a partir de la entrevista y de la documentación de Google.

1. Escribe el cierre en filas. Una fila por tarea: ID, tarea, sociedad, área, responsable, revisor, plazo (día hábil del cierre o fecha), preparado por, fecha de preparación, revisado por, fecha de revisión, enlace al papel de trabajo y notas.
2. Pide la función útil más pequeña. Una barra lateral con dos botones, «Marcar preparado» y «Marcar revisado», que registre usuario y hora en la fila seleccionada. Pide al asistente que te explique cada parte del código y guárdalo en el proyecto de script de la hoja.
3. Prueba en una copia y después en un cierre real. Intenta romperla: selecciona la cabecera o dos filas, revisa una tarea que nadie ha preparado, revisa una tarea tuya. Corrige cada fallo con un prompt nuevo.
4. Protege la evidencia. Usa intervalos protegidos para que solo el script y el responsable del cierre puedan tocar las columnas de estado y fechas; si no, cualquiera escribe una fecha y el rastro no vale nada.
5. Añade plazos y vista de vencidas. Una vista filtrada o una pestaña con lo vencido por responsable y sociedad. Después, el correo al asignar.
6. Deja los gráficos para el final. Una matriz del cierre (sociedades × áreas, coloreada por estado) y las tendencias de saldos que de verdad miran los revisores.
7. Decide cuándo pasa a ser una app. Da el salto de la barra lateral a una app web solo cuando la hoja estorbe; documenta quién la mantiene, dónde está el código y cómo se prueba una versión nueva antes de un cierre.
8. Deja el ERP en solo lectura. Si más adelante conectas NetSuite, hazlo como dice Pipedrive que lo está haciendo con herramientas más avanzadas: primero contra un entorno de pruebas seguro.

Ejemplo concreto: el primer prompt y el primer código

Nuestro primer prompt para un asistente como Gemini:

Soy controller, no programador. Tengo una hoja de Google con una pestaña
llamada "Checklist". La fila 1 tiene cabeceras. Columnas: A ID, B Tarea,
C Sociedad, D Área, E Responsable, F Revisor, G Plazo, H Preparado por,
I Fecha preparación, J Revisado por, K Fecha revisión, L Enlace al papel de
trabajo, M Notas.
Escribe un Google Apps Script vinculado a esta hoja que añada un menú "Cierre"
con una opción que abra una barra lateral. La barra tiene dos botones:
"Marcar preparado" y "Marcar revisado", que actúan sobre la fila seleccionada:
- Marcar preparado escribe mi email en H y la fecha y hora actuales en I.
- Marcar revisado escribe mi email en J y la fecha y hora en K, pero solo si H
  está relleno y H no es mi propio email (quien prepara no puede revisar).
- Muestra un mensaje claro en la barra si estoy en otra pestaña, en la fila de
  cabecera o si una regla bloquea la acción.
Explica cada función en lenguaje sencillo y dime cómo instalarlo y probarlo en
una copia de la hoja.

Una versión mínima de lo que debería salir (código nuestro, basado en el ejemplo de barra lateral de Google; revísalo antes de usarlo):

// Code.gs, vinculado a la hoja del checklist del cierre
function onOpen() {
  SpreadsheetApp.getUi().createMenu('Cierre')
    .addItem('Abrir barra del cierre', 'showSidebar').addToUi();
}

function showSidebar() {
  const html = HtmlService.createHtmlOutputFromFile('Sidebar').setTitle('Cierre mensual');
  SpreadsheetApp.getUi().showSidebar(html);
}

function markSelected(action) {
  const sheet = SpreadsheetApp.getActiveSheet();
  if (sheet.getName() !== 'Checklist') throw new Error('Abre primero la pestaña Checklist.');
  const row = sheet.getActiveRange().getRow();
  if (row < 2) throw new Error('Selecciona una fila de tarea, no la cabecera.');
  const user = Session.getActiveUser().getEmail();
  if (!user) throw new Error('El script no puede ver tu email; consulta al propietario de la hoja.');
  if (action === 'review') {
    const preparer = sheet.getRange(row, 8).getValue();
    if (!preparer) throw new Error('Esta tarea aún no está preparada.');
    if (preparer === user) throw new Error('Quien prepara no puede revisar la misma tarea.');
    sheet.getRange(row, 10, 1, 2).setValues([[user, new Date()]]);
  } else {
    sheet.getRange(row, 8, 1, 2).setValues([[user, new Date()]]);
  }
  return 'Fila ' + row + ' marcada como ' + (action === 'review' ? 'revisada' : 'preparada') + '.';
}

<!-- Sidebar.html -->
<button onclick="run('prepare')">Marcar preparado</button>
<button onclick="run('review')">Marcar revisado</button>
<p id="msg"></p>
<script>
  function run(action) {
    google.script.run
      .withSuccessHandler(m => document.getElementById('msg').textContent = m)
      .withFailureHandler(e => document.getElementById('msg').textContent = e.message)
      .markSelected(action);
  }
</script>

Dos detalles importan más que el código. La documentación de Google avisa de que getEmail() puede devolver una cadena vacía si las políticas de seguridad no permiten conocer la identidad del usuario; por eso el script se niega a registrar un nombre vacío. Y la comprobación de segregación (quien prepara no revisa) es el tipo de regla que una herramienta de cierre debe imponer, no solo anotar. Después vendrían las vencidas por responsable, el correo al asignar y un gráfico de avance frente a los plazos.

Resultados declarados por la fuente

• Sustitución: el equipo usa la app «en lugar de la herramienta de gestión del cierre que venía con NetSuite» (Vengalil).
• Alcance: «¿Iguala sus funciones al 100 %? No. Se ciñe a nuestras necesidades y casos de uso. No es una comparación de igual a igual» (Vengalil).
• Coste: «quizá estemos gastando un par de miles al año en costes de inferencia y automatización frente a una base de costes de unos 30.000 a 40.000 dólares» (Vengalil). Es una comparación aproximada y condicional, que no incluye el tiempo del propio controller en construirla y mantenerla.
• Esfuerzo: un par de horas para la barra lateral, unas tres semanas hasta la primera versión usada en un cierre y varios meses de mejoras (Dycus).
• Beneficios declarados: tiempo para «revisiones más rigurosas» y más «tipos de operaciones que se pueden validar» (Vengalil). No se dan horas ahorradas, días de cierre ni tasas de error.

Limitaciones y riesgos

• Una sola fuente y dos directivos de la casa. Todo sale de una entrevista con quien lo construyó y su CFO. Nada está auditado y no hemos visto la app.
• La comparación de costes se deja cosas fuera. La construcción llevó meses de un controller sénior y la app necesita mantenimiento cada vez que cambie Google, la hoja o el cierre. Vengalil reconoce que el equipo aprendió lo que «duele la fase de construcción» frente a comprar.
• Dependencia de una persona. Una herramienta hecha por una sola persona a base de prompts dura lo que dure su documentación y la segunda persona que la entienda.
• Los controles viven ahora en la herramienta. Si la app es el registro de quién preparó y revisó qué, el auditor puede preguntar cómo se aprueban y prueban sus cambios, quién puede editar las fechas y cómo se conserva el historial. Un rastro en una hoja de cálculo se altera fácilmente si no se protegen los intervalos.
• Datos en dos sitios. Mientras las cifras se copien a mano de NetSuite a Sheets, el balance de la hoja puede desviarse del libro. Los gráficos valen lo que valga la última copia.
• Límites de la plataforma. Apps Script tiene cuotas diarias (por ejemplo, de destinatarios de correo) y las funciones cambian entre cuentas personales y de Workspace.

Errores comunes

• Empezar por lo más difícil. Pipedrive empezó con una barra lateral para marcar casillas, no con conciliaciones ni asientos automáticos.
• Dejar que el asistente escriba pronto en el ERP. El espacio seguro era la hoja; la conexión con NetSuite llega después y en un entorno de pruebas.
• Construir en solitario. Dycus lo hizo con opiniones constantes del equipo, que intentó romper cada versión antes de fiarse de ella.
• Copiar la herramienta comercial función por función. El equipo decidió no igualar al 100 % la herramienta incluida. Decide qué usas de verdad antes de reconstruirlo.
• Saltarse las reglas aburridas. Sin controles de segregación, columnas protegidas y una copia de pruebas, un seguimiento del cierre hecho en casa es una hoja con botones.

Conclusiones

El caso de Pipedrive habla menos de Gemini que de método: alguien de finanzas que sabe exactamente qué necesita el cierre, un espacio seguro que no puede estropear la contabilidad y muchos prompts pequeños, cada uno probado antes del siguiente. El planteamiento del CFO es honesto: la app hace menos que la herramienta a la que sustituye, cuesta mucho menos de mantener en marcha y exige un equipo dispuesto a responsabilizarse de lo que construye. Pipedrive intenta además que esto deje de ser excepcional, con formaciones, demostraciones de herramientas de IA hechas por la plantilla y «días de construcción» en los que la gente empieza a trabajar problemas del negocio en Gemini. Para otros equipos, lo replicable es el orden de los pasos y la línea que no cruzaron mientras aprendían.