07 Document workflow automation for a consulting firm: templates, approval, and archive

A consulting firm runs on documents: contracts, appendices, service reports, client reports, commercial proposals. None of these are creative work, they are an assembly of a standard frame and one client's data. But that assembly looked like this: open a similar document from a past client, save it under a new name, and proofread it, replacing everything that belonged to the previous one.

Hence the first problem: errors that stay invisible. A document assembled from someone else's leaves something of theirs behind: a detail, a deadline, a clause phrased for a different deal. An error like this is not flagged, it simply ships to the client and surfaces whenever it happens to surface.

A document was assembled from a past client's document, and along with the frame, something of theirs traveled with it: a detail, a deadline, a term. An error like this is not flagged, it simply ships to the client.

The second problem was approval. A document went out over email and messengers, and edits came back inconsistently: someone sent a file, someone else pasted a paragraph as text, someone replied 'ok' to an email a week old. Assembling one version out of that was a separate job, and the document's author did it from memory.

The third followed from the second: the question 'which version is current' had no technical answer. Drives held files named things like 'final,' 'final_2,' 'final_edits'; inboxes held attachments of varying freshness. The answer came from a person, and that person could be on vacation.

And the fourth, the most unpleasant one to untangle: there was no way to reconstruct how a document arrived at its current form. Who insisted on a clause, when a term changed, why this particular version was ultimately approved: all of it existed only in correspondence scattered across participants' personal inboxes.

A web app in which a document stopped being a file and became a record. The record has a type, a client, an author, a status, approval participants, and a change history, and all of that is a property of the document itself, not information about it living in someone's head.

The foundation of the system is templates. A standard document is described once: fixed text plus fields that get filled in. Data comes not from a past document but from the client's record: details, terms, responsible parties. An employee picks a document type and a client instead of hunting for something to copy from. Someone else's content can no longer carry over into a new document, because copying no longer exists as an operation.

A document stopped being a file and became a record: with a status, a route, versions, and correspondence that are its own properties, not information about it living in someone's head.

Approval runs on top of that. A document has a route: who reviews it and in what order, who approved it, who returned it with comments, who currently holds it. Edits go into the document itself rather than into a forwarded copy, and each one becomes a version in the history, with an author and a date.

And an archive that no longer needs to be maintained separately. The document already lives in the system, linked to the client, with a full version history and correspondence. Search works by client, type, period, status, and content, instead of digging through network folders and personal inboxes.

In this work, email is not a notification channel, it is where a document actually gets discussed. That's why the integration with the company's Yandex 360 corporate email was built both ways, not as a one-way mailing from the system.

The system sends emails to approval participants and to the client, with the document and what's required from the recipient. Replies come back the other way: the system pulls in correspondence about the document and links it to that document. A client's reply flagging a clause in a contract lands not in a manager's personal inbox but in the document's record, where every participant can see it.

A client's reply flagging a clause in a contract lands not in a manager's personal inbox but in the document's record, where every approval participant can see it.

This closes the fourth problem from the first section, the one about reconstructing how events unfolded. The document's history stopped being the sum of personal inboxes: it is collected in one place and stays there when an employee goes on vacation or leaves the company.

It's also worth noting separately that the company's email address stayed the same. The system did not introduce a new communication channel that clients would need to be told about, it built into the one they already use.

A consulting firm handles other people's commercial terms, and access to a document is not a convenience, it is a commitment to the client. Access rights in the system are tied to an employee's role and to their involvement in work for a specific client.

This gives an answer to a question that previously had none: who had access to this client's documents. While files sat in network folders and inboxes, the honest answer was 'whoever had access to the folder, plus everyone it was forwarded to.'

An action history is written at the record level: who created it, who edited it, who approved it, who opened it. For a firm that answers to its clients for keeping their terms confidential, this is the ability to show how access works, not just promise it.

Preparing a document stopped being a proofread of someone else's work. An employee picks a type and a client, the system assembles the document from the template and the record's data, and the work shifted from 'find something to copy and don't forget to replace everything' to reviewing the actual content.

Approval became visible. Every document has a status and a route: where it is now, who is holding it, what was said. This removed an entire class of questions that used to be asked in chat and that pulled every participant's attention at once.

The question of the current version disappeared along with its cause. Version became a property of the record rather than a filename, and past versions remain accessible as history rather than as files nobody dares delete.

And most importantly: a document's history stopped depending on people. Who edited it, when, what the client replied, and what was ultimately agreed is now stored in the system, not in the personal inboxes of employees, some of whom no longer work at the company.