Contract Portal

The brief

Contracts were drafted from a Word template. Someone typed in the customer's details, exported a PDF, emailed it and waited. The customer printed it, signed it, scanned it and sent it back. Someone else saved the scan to a shared folder — if they remembered — and retyped the details into the CRM.

Something got lost at every step. The status of a contract did not exist anywhere as data, only in people's heads and email threads. "Have we sent it yet or not?" was answered by searching the inbox. And because the template text was copied by hand, over time several subtly different versions were in circulation.

The solution

A portal where a contract is created, goes out and comes back signed — and everything in between happens on its own.

A contract starts from a document, not an empty form. The sales rep uploads what the customer provided — a bill or their current contract — and a model extracts what is needed: name and address, the supply point ID, consumption, the current supplier. The form is pre-filled and the person only checks it instead of retyping. Every such read is logged, so for any disputed field you can trace where the value came from.

Templates and key mapping. A PDF template is uploaded in the settings and its fields are bound to keys such as {{client.name}} or {{price.total}}. When a contract is issued, the values are filled in from the portal's data. A new contract variant is a task for the person who will use it, not a request for a developer.

Signing through DigiSign. The finished contract goes to the customer for electronic signature via the API. Nobody prints or scans anything and the customer does not have to install anything.

A webhook finishes the rest. Once it is signed, DigiSign sends a notification and the portal reacts on its own: it switches the contract status, uploads the signed document and attachments to the job folder on Google Drive and creates a record in the CRM. Between signature and archive there is no person to wait for.

An overview of the whole operation. The dashboard shows how many contracts are in progress, how many are awaiting signature and how many are done — over time and by status. "How are we doing this month?" is answered on a single screen.

Four roles. Sales reps issue their own contracts, back office processes them across all reps, managers see the numbers for the whole team and admins manage templates and users. The template is the common denominator of every contract, so only the person responsible for it may touch it.

How it’s built

The core is a state machine over a single contract: in progress → sent for signature → signed → archived. Every transition has a cause — a user action or a message from outside — and without one the status does not change.

The interesting part is the last one. A webhook is someone else's system calling you whenever it suits it — twice in a row, or right when Google Drive is unavailable. A naive implementation then either creates the contract in the CRM twice, or the first error brings down the rest of the chain and the signed document is left hanging nowhere.

So processing is split into steps that can be repeated without side effects, and the status only moves forward once each of them has been confirmed. If Drive does not respond, the contract stays signed and waiting for archiving — not half broken.

Outcome

The path from issuing a contract to its record in the CRM runs without a single manual step. The status of every contract is data in the portal, not a guess from the inbox, and signed documents end up in one place every time, not just when someone remembers.

0

manual steps between signature and archive

4

roles with graded permissions

3

systems connected by one webhook

1 template

covers a whole range of contracts through key mapping