Contracts & E-signature
By Conversa Labs
By Conversa Labs
Issuing companies, A1 certificate, templates, variables, auto-fill, internal/external signing, public page and validator.
Contracts & E-signature overview
Overview The ConversaLabs Contracts & E-signature module lets you create, send, sign and validate contracts without leaving the platform. You build documents from templates with variables, fill in the data automatically from information that already lives in your support workspace (contact, conversation, CRM deal, catalog and account), send the signing link through native channels (WhatsApp and email) and track the status in real time. The signing process is fully electronic and offers different legal levels β from a simple signature (consent with IP and device record) to a qualified one with an ICP-Brasil A1 digital certificate. Every contract produces an immutable audit trail, a final signed PDF and a public validation page so anyone can check the document's authenticity. Prerequisites - The Contracts module is optional and must be enabled for your account. If you can't find the Contracts area, talk to an administrator. - Your user needs permission to access and manage Contracts. - To issue contracts you must register at least one issuing company (the "contracted" party). For qualified signatures, that company needs an A1 digital certificate. - To send the signing link through channels, have a WhatsApp or email Inbox configured. Step by step 1. Open the Contracts area from the sidebar (commercial section, next to Payments). 2. Register your issuing company and, if you'll use qualified signatures, upload its A1 certificate. 3. Create a contract template in the editor or upload a ready-made model, using {{ }} variables wherever the content changes from one contract to another. 4. Generate a contract from the template: variables are filled in automatically with the contact/conversation/deal data; adjust anything missing. 5. Define the signers and the desired signature level. 6. Send the link through native channels. The contracted party can sign automatically; the other signers sign on the public page. 7. Track the status to completion and download the signed PDF. Share the validation page whenever you need to prove authenticity. Settings & options - Issuing companies: register as many as you need, each with its own details, branding and A1 certificate. - Templates and clauses: a reusable library of models and clauses. - Signature levels: simple, advanced (with OTP) and qualified (A1). - Module settings: document retention, time-stamping (TSA) and other adjustments. - Automation: contracts can be created/sent via Automations, Macros and the Flow Builder. Use cases - Close a deal in the CRM and send the contract for signature in the same conversation. - Issue service agreements, proposals and membership terms with a standardized model. - Collect a signature over WhatsApp with OTP for stronger legal assurance. - Generate a charge in the Payments module right after the contract is signed. Tips, limits & best practices - Standardize your contracts as templates to gain speed and reduce mistakes. - Choose the signature level based on the document's risk β the higher the value, the stronger the recommended signature. - For full legal validity of qualified signatures, keep the A1 certificate valid and, where applicable, configure an accredited time-stamp (TSA). - Always double-check the auto-filled data before sending for signature. Troubleshooting - I don't see the Contracts module: it may not be enabled for the account or your role β talk to an administrator. - I can't issue a qualified contract: make sure the issuing company has a valid, in-date A1 certificate. - The signer didn't get the link: confirm the channel (WhatsApp/email) and the signer's contact details. See also - Issuing companies and the A1 digital certificate - Templates, variables and auto-fill - Internal and external signing - Public contract page and validator
Issuing companies and the A1 digital certificate
Overview The issuing company is the "contracted" party of your contracts β the one that issues and, where applicable, signs the document automatically on your side. You can register as many issuing companies as you need (for example, one per brand, branch or tax ID), each with its own details, branding and digital certificate. To use a qualified signature (ICP-Brasil), the issuing company needs an A1 digital certificate β a password-protected .pfx/.p12 file. That certificate is uploaded to the platform and used to sign contracts with stronger legal validity. Prerequisites - Contracts module enabled for the account and a user with permission to administer Contracts. - The company's registration details (legal name, tax ID, address, contact). - For qualified signatures: a valid A1 certificate in .pfx/.p12 format and its password. - The A3 certificate (hardware token/card) is not supported in this version β only the A1, which is a file. Step by step 1. In the Contracts area, open the issuing companies section. 2. Create a new issuing company and fill in its registration details. 3. Add the branding (logo and colors), which will appear on the contract and the public pages. 4. To enable qualified signatures, upload the A1 certificate (.pfx/.p12) and enter its password. 5. The platform validates the certificate: if the password is wrong or the file is invalid, the upload is rejected with an error message. 6. When valid, the certificate holder and the expiry date are shown. 7. Save. The issuing company is now ready to be used when generating contracts. Settings & options - Multiple issuers: keep as many issuing companies as your business requires. - Branding per company: each one's own logo and colors, reflected in the document and the validator. - Certificate status: the platform shows holder, file and expiry; replace the file when you renew it. - Time-stamp (TSA): in the module settings you can point to an accredited time-stamp server to strengthen validity (TSA authentication is kept in the environment, not on screen). Use cases - A company with multiple brands/tax IDs issuing contracts under different identities. - An operation that needs stronger legal validity via an A1 certificate. - Standardizing the look of contracts (logo and colors) per issuing company. Tips, limits & best practices - Keep the A1 certificate always valid β an expired certificate blocks new qualified signatures. - Treat the certificate password as a secret: it is required in order to sign. - The certificate is sensitive data β only users with admin permission should manage it. - For full validity in Brazil, combine the A1 with an accredited time-stamp (TSA). Troubleshooting - The certificate upload was rejected: check that the password is correct and that the file is a valid, uncorrupted .pfx/.p12. - The expiry shows as expired: the certificate has expired; generate/renew a new A1 and upload it. - I can't sign in qualified mode: make sure the selected issuing company has a valid A1 loaded. - I need A3 (token/card): it is not supported in this version yet; use the A1 (file). See also - Contracts & E-signature overview - Templates, variables and auto-fill - Internal and external signing - Public contract page and validator
Templates, variables and auto-fill
Overview Templates are reusable models of your contracts. You create a template once, define the variable parts with {{ }} (for example, customer name, tax ID, amount, dates) and generate as many contracts from it as you like. When generating, the variables are filled in automatically with the data that already exists in your workspace β contact, conversation, CRM deal, catalog and account β leaving you to simply review and adjust anything missing. You can build the template in the platform's editor or upload a ready-made model. There is also a reusable clause library to standardize common passages across multiple templates. Prerequisites - Contracts module enabled and a user with permission to manage templates. - The contract content (base text) and the list of fields that change from one contract to another. - For auto-fill to work well, the source data (contact, deal, etc.) should be populated. Step by step 1. In the Contracts area, open Templates and create a new one. 2. Write the content in the editor or upload a ready-made model. 3. Wherever the text changes from one contract to another, insert a variable in the form {{ variable }}. 4. Reuse common passages from the clause library. 5. Save the template. 6. To issue, generate a contract from the template: the variables are filled in automatically with the source data (contact/conversation/deal/catalog/account). 7. Review the filled-in values, manually adjust anything missing and proceed to signing. Settings & options - Data source: variables can be filled from the contact, conversation, CRM deal, catalog and account data. - Manual entry: any variable can be edited by hand before sending. - Agentic generation: Maestro can help draft/fill the contract from the conversation context. - Clause library: standardize clauses and reuse them across multiple templates. - Model upload: import an already-formatted document and turn it into a template. Use cases - A standard service agreement with variable name, tax ID, scope and amount. - Proposals and membership terms that change only a few fields per customer. - Reuse of legal clauses (confidentiality, termination, jurisdiction) across different templates. Tips, limits & best practices - Give variables clear names so automatic and manual filling is obvious. - Check that each {{ variable }} has been replaced before sending β empty variables can leave gaps in the document. - Centralize common clauses in the library to keep consistency and ease updates. - Always review the generated contract: auto-fill speeds things up, but the check is your responsibility. Troubleshooting - A variable wasn't filled in: the source data may be empty (e.g., a contact with no tax ID). Populate the source or edit it manually. - The text came out with literal {{ }}: check the spelling of the variable in the template. - The uploaded model lost its formatting: adjust the formatting in the editor after the upload. See also - Contracts & E-signature overview - Issuing companies and the A1 digital certificate - Internal and external signing - Public contract page and validator
Internal and external signing
Overview A contract usually has two sides: the contracted party (your issuing company) and the external signers (the customer and other parties). In ConversaLabs: - Internal signing is the contracted party's auto-signature β performed server-side, using the issuing company's details (and, for qualified signing, its A1 certificate). - External signing is done by the signers through a secure public page, with no need to sign up or log in. You choose the signature's legal level based on the document's risk: simple (consent with IP and device record), advanced (with OTP by email/WhatsApp and a visual signature) or qualified (an ICP-Brasil A1 digital certificate, PAdES standard). Prerequisites - Contracts module enabled and a contract generated from a template. - A registered issuing company (for the auto-signature). For the qualified level, it needs a valid A1 certificate. - To send the link to external signers, a native channel (WhatsApp or email) and the signers' contact details. Step by step 1. On the contract, define the signers (the contracted party and the external signers). 2. Choose the signature level (simple, advanced or qualified). 3. Send for signature: the link is delivered through native channels as a card with a button in the conversation. 4. The contracted party signs automatically (server-side auto-signature). 5. Each external signer opens the public page, reviews the document and signs. 6. At the advanced level, the signer validates an OTP code and records a visual signature (drawn, typed or uploaded as an image). 7. Once all signatures are complete, the final signed PDF is generated and the status becomes completed. Settings & options - Signature levels: - Simple β consent with capture of IP, date/time and device. - Advanced β OTP by email/WhatsApp + visual signature (drawn, typed or uploaded). - Qualified β A1 digital certificate (ICP-Brasil), PAdES standard. - Auto-signature: the contracted party signs automatically with the issuing company. - Order and multiple signers: define who needs to sign. - Time-stamp (TSA): when configured, it strengthens the signature's legal validity. - Audit trail: each signature records IP, device, consent and timestamp (SHA-256). Use cases - A customer signs over WhatsApp with OTP in a few taps, installing nothing. - A higher-value contract requires a qualified signature with an A1 certificate. - The contracted party signs automatically and just waits for the counterparty. Tips, limits & best practices - Use the advanced (OTP) or qualified level for higher-value or higher-risk documents. - Make sure the signers' contact details are correct so the link is delivered. - For the qualified level, keep the A1 certificate valid and, if applicable, an accredited TSA configured. - Track the contract's status β it shows who has signed and what's still pending. Troubleshooting - The signer didn't get the link: confirm the channel and contact details; resend if needed. - The OTP code doesn't arrive: check the signer's email/WhatsApp and try resending the code. - The qualified auto-signature failed: make sure the issuing company has a valid, in-date A1 certificate. - The contract won't complete: check that all signers have signed. See also - Contracts & E-signature overview - Issuing companies and the A1 digital certificate - Templates, variables and auto-fill - Public contract page and validator
Public contract page and validator
Overview Every contract has a secure public page, accessible through a link, where external signers review the document and sign β with no need to sign up or log in. This page shows the contract content with the issuing company's branding and guides the signer through the signing flow (including OTP and the visual signature, when the level requires it). After it's signed, there is also a public validator: a verification page that lets anyone check the authenticity of the contract and the final signed PDF. The validator shows verification details in a masked way (without exposing sensitive data), backed by the immutable audit trail (SHA-256, IP, device, consent and timestamp). Prerequisites - A contract sent for signature (for the public signing page) or already signed (for the validator). - The matching link, delivered to the signer through native channels or shared for validation. - No login is required for the external signer or for whoever validates. Step by step 1. Send the contract for signature: the signer receives the public page link. 2. On the public page, the signer reviews the document and follows the signing flow. 3. Depending on the level, they confirm an OTP and record the visual signature. 4. Once the signatures are complete, the platform generates the final signed PDF with the manifest/certificate. 5. To prove authenticity, open (or share) the public validator page. 6. The validator confirms whether the document is authentic and shows the verification details in a masked form. Settings & options - Branding: the public page uses the issuing company's logo and colors. - Flow by level: simple, advanced (OTP + visual signature) or qualified (A1). - Final signed PDF: generated on completion, with the audit trail and manifest/certificate. - Masked validator: shows the verification without exposing sensitive data (privacy/LGPD). - Time-stamp (TSA): when configured, it appears in the verification to strengthen validity. Use cases - Send the customer a signing link that opens straight on their phone, with no install. - Provide a third party (bank, registry, auditor) with a contract validation link. - Prove the integrity of the signed PDF at any time, even after closing the deal. Tips, limits & best practices - Share the validator when you need to prove authenticity without sending sensitive data. - Advise the signer to open the public page in an up-to-date browser. - Keep the final signed PDF β it carries the audit trail and the verification manifest. - Remember the validator is masked by default to protect personal data. Troubleshooting - The public page link won't open: check that the link is complete and that the contract is still active (not canceled/expired). - The validator says the document was not found: check that the contract was completed and that the validation link is correct. - The PDF doesn't match the verification: the file may have been altered β always use the final signed PDF generated by the platform. - The signer can't sign: check the required level (e.g., OTP) and the contact details for sending the code. See also - Contracts & E-signature overview - Internal and external signing - Templates, variables and auto-fill - Issuing companies and the A1 digital certificate