Proposals & Invoices · Article 5.4

Lo que ve su cliente cuando recibe una enmienda

El cliente recibe un correo con un PIN nuevo, aterriza en una página protegida por PIN, ve una comparación lado a lado entre lo antiguo y lo nuevo con totales y un motivo, y firma (o rechaza) — exactamente como el flujo de la propuesta original pero con la diferencia incorporada.

La experiencia del cliente para una enmienda refleja deliberadamente la experiencia de la propuesta original. Mismo estilo de correo (nombre visible = nombre de su empresa), misma puerta de PIN, mismo patrón de URL alojada en Clozo, misma captura de evidencia al firmar. La diferencia es la página en sí: en lugar de una vista previa única de la propuesta, el cliente ve una comparación estructurada para que el cambio sea inequívoco. Esta coherencia importa — los clientes que firmaron una propuesta una vez nunca deben sentir que navegan por una interfaz desconocida para firmar la modificación del pedido.

Step by step

El correo llega en ~5 segundos.
Desde noreply@useclozo.com, nombre visible «[Nombre de su empresa] vía Clozo». El asunto es por defecto «Solicitud de cambio de propuesta: [título original]» pero es editable en el Paso 4 del asistente.
El cliente hace clic en Revisar cambio.
Aterriza en app.useclozo.com/p/amendment/{slug} — una página alojada en Clozo protegida por el PIN de 4 dígitos que aparece en el cuerpo del correo.
El cliente introduce el PIN.
Cinco intentos incorrectos en 24 horas activa un bloqueo por slug (clave de caché slug_amend_locked:{slug}). Después del bloqueo, solo usted puede emitir un PIN nuevo (artículo 7.7).
El cliente lee la vista de diferencias.
Las líneas originales aparecen a la izquierda, las revisadas a la derecha. Las etiquetas de colores reflejan el asistente: verde + añadido, ámbar ~ modificado, rojo − eliminado, gris igual. El delta de totales es prominente en la parte inferior («Aumento de coste: +€500» / «Reducción de coste: −€500» / «Reembolso pendiente: €1.200»). El motivo que escribió en el Paso 2 aparece como una nota entre comillas encima de la diferencia.
Bloque de renuncia B2C (si aplica).
En las enmiendas Δ+ donde el cliente está marcado como B2C, la página muestra dos casillas de verificación de renuncia obligatorias inmediatamente encima del botón Firmar. Ambas deben estar marcadas antes de que Firmar se habilite. Consulte el artículo 7.5 para la mecánica legal.
El cliente firma (o rechaza).
La firma captura la misma evidencia eIDAS que la propuesta original: nombre escrito, correo, IP, User-Agent, marca de tiempo del servidor y indicador de consentimiento. El estado de la enmienda cambia a firmado, el pipeline post-firma se ejecuta y los correos de confirmación se envían a ambas partes en segundos.

La página de detalle de la propuesta muestra un panel «Enmienda pendiente» con el número de enmienda, la marca de tiempo de envío, la cuenta regresiva de caducidad (14 días desde sent_at) y tres botones: Copiar enlace de firma, Reenviar con nuevo PIN, Cancelar enmienda. La Línea de tiempo registra Enmienda propuesta a HH:MM UTC. Cuando el cliente abre el enlace, aparece un evento en la Línea de tiempo Enmienda vista a HH:MM UTC por IP X.X.X.X. Cuando firma, el panel desaparece, reemplazado por los nuevos documentos en el menú desplegable de Documentos más un correo de confirmación en su bandeja de entrada.

Why this works this way

¿Por qué un PIN nuevo por enmienda, incluso para el mismo cliente que ya firmó la propuesta original? Porque la enmienda es un artefacto legal separado — tiene su propio registro de auditoría, su propia pila de evidencia, su propio registro inmutable. Compartir el PIN de la propuesta original confundiría los dos artefactos y debilitaría la cadena de evidencia si la enmienda alguna vez es impugnada. El bloqueo de 5 intentos en 24 horas (_check_amendment_access_code en backend/apps/public/amendment_views.py) se aplica de forma independiente por slug de enmienda.

El renderizado de la vista de diferencias utiliza comparación basada en posición (computeDeltaAction en AmendmentWizard.tsx) — la línea en el índice i de la lista revisada se compara con la línea en el índice i de la original. Los añadidos aparecen al final de la lista revisada con etiquetas verdes; las eliminaciones aparecen en la columna original con tachados rojos; las modificaciones permanecen en su lugar con etiquetas ámbar. Esto es simple y predecible; no detectará un «intercambio de dos líneas adyacentes» como una operación nula (mostrará ambas como modificadas) — por diseño, porque tales reordenaciones pueden cambiar el énfasis de un contrato incluso si los totales de las líneas coinciden.

Troubleshooting

Keep reading

Proposals & Invoices

Creating an amendment (the 4-step wizard)

The amendment wizard at `/proposals/{id}/amend` walks you through line items, reason, preview, and email — in that order. Five minutes for a simple change, ten minutes for a complex one. The client doesn't see anything until you click Send on Step 4.

Proposals & Invoices

B2C cooling-off: when the CRD Art. 16(a) waiver appears

When you increase scope on a contract with a consumer (B2C) client, EU consumer law gives that client a fresh 14-day right to withdraw from the added portion. Clozo presents a mandatory waiver checkbox so the client knows the right exists and explicitly waives it.

Proposals & Invoices

Resending the amendment link with a fresh PIN

Client lost the email, hit the PIN-attempt lockout, or just can't find the original message? Resend with a fresh PIN. The old PIN is invalidated, the lockout is cleared, a new email goes out, and the audit log records the re-issuance.

Proposals & Invoices

When the client declines (or the amendment expires)

Two terminal states for an unsigned amendment: the client clicked Decline (with optional reason) or 14 days passed with no action. Either way, the original contract is unchanged — and you can immediately draft a new amendment to try again.