Antes de pedirle a un cliente que cambie cómo paga

Cuando pienso en un producto para cobrar, intento empezar por la persona que recibe la factura. Tiene su banco, un circuito de aprobaciones y otras cosas que hacer. Nuestro producto ocupa una parte muy pequeña de su día.

Desde el lado de quien construye, es fácil entusiasmarse con una nueva ruta, una red o una integración. Desde el otro lado aparece una pregunta bastante más sencilla: ¿qué tengo que hacer para pagar esta factura y seguir con mi trabajo?

Esa pregunta me parece un buen punto de partida para diseñar.

Cambiar la forma de cobrar puede trasladar trabajo al cliente. Dar de alta otro beneficiario. Pedir permiso a administración. Entender una moneda distinta. Averiguar si el nombre que aparece en pantalla corresponde a la empresa de la factura. Cada paso merece una razón.

Por eso, antes de añadir una opción de pago, yo pondría la factura y sus instrucciones delante de alguien que no conozca el producto. Le pediría que señalara qué copiaría en su banco. Sin explicar nada durante el ejercicio. Las dudas que aparezcan son trabajo pendiente de diseño.

Hay cinco datos que querría dejar resueltos:

• Beneficiario: el nombre exacto que debe utilizar, según las instrucciones verificadas de esa ruta. Si difiere de la marca comercial, explicar la relación.
• Destino: los datos correspondientes al método elegido, con etiquetas que el comprador pueda reconocer.
• Moneda e importe: qué cantidad debe enviar y en qué moneda. Si hay conversión, dónde se confirma.
• Referencia: el texto que necesita conservar para identificar la factura, claramente separado de otros números.
• Coste esperado: qué cargos conocemos, quién los asume y cuáles sólo puede confirmar el banco o proveedor del comprador.

El nombre merece especial atención. El esquema Verification of Payee del European Payments Council contempla comprobar el IBAN junto con el nombre del beneficiario en transferencias SEPA. Es una comprobación concreta dentro de ese sistema; no implica que todas las rutas del mundo funcionen igual. European Payments Council.

Con la referencia pasa algo parecido. La documentación de Stripe explica que, en su sistema de facturas pagadas por transferencia, el código de referencia puede ayudar a asociar el pago a la factura. Es un ejemplo útil de por qué ese campo debe entenderse antes de enviar el dinero. Stripe: facturas y transferencias.

Después miraría las opciones. Una ruta puede encajar muy bien en nuestra arquitectura y encajar mal en el trabajo de quien paga. Si exige abrir otra cuenta, conseguir otra aprobación o aprender un proceso nuevo, quiero poder explicar qué gana esa persona a cambio. A veces tendrá sentido. Otras veces habrá que simplificarla.

También incluiría un contacto reconocible para resolver dudas antes del pago. Y, si cambian las instrucciones, una forma de confirmar el cambio por un canal ya conocido. Una factura bonita no resuelve esa parte por sí sola.

Me interesa construir productos que respeten el tiempo de ambos lados. Podemos hablar mucho de infraestructura, pero una mejora pequeña en las instrucciones de una factura también es producto. Si el cliente necesita menos explicaciones para hacer bien su trabajo, hemos encontrado algo que merece la pena mejorar.

Al final, lo importante es construir. Y construir incluye pensar en quien no tiene ninguna intención de aprender cómo funciona nuestro sistema.

Si tu empresa quiere conocer Bennu, de la que soy cofundador, puedes solicitar una invitación. El acceso está sujeto a revisión y elegibilidad.