Charles Drayson

Feb 9 · 5 min read

Through a series of coincidences, I’ve been a close spectator of the workings of HR teams, small and large. I had a fun time as General Counsel for one of the large global outsourcing service providers serving the HR sector. Subsequently, I never seemed far away from projects that directly or indirectly interacted with HR processes.

Of all the back-office functions, HR functions at the confluence of regulation change, procedure and business need – but remains vitally (and ironically dependant on humant input).

Too  much procedure with too little human involvement will fail business needs. Failure to reflect regulatory requirements, or inability to roll with change, leads to the same dysfunction. It’s difficult enough to blend all the requirements in just the right mix, but then you have to add volume.

Some HR tasks require specific solutions. Nobody operates the payroll without a payroll solution, for example. Many HR teams also use more generic HR applications for wider matters like absence management, maintaining HR records, and staff appraisals. Where does an application like Legito fit?

Benefits of Legito Deployment

Legito is an enterprise application – Legito’s strength is the ability to span the needs of the whole organization without loss of utility. Enterprise adoption requires a rich feature set (simple, not simplistic), intuitive use without big change management projects, and the ability to customize the solution for the needs of each team. The HR team’s organizational view is oriented around employees and their place within the enterprise – very different to, say, a finance team or a procurement team. In stark contrast to more specific solutions, we designed Legito to be flexible, to serve the wider audience. Flexibility gives HR teams access to a solution tailored for HR. More than that, the same flexibility has two more benefits: flexibility to reflect your desired way of working within HR, and flexibility to integrate the HR workflows with procedures and teams external to the HR department.

Recruitment

Consider a new joiner process, for example. A good new joiner process begins and ends outside the HR team. At one end of the process, hiring managers need to initiate recruitment. At the other end of the process, you need to pass a new joiner’s records to the IT team to provision user accounts and systems access. The handover between the HR team and other back-office teams ought to be integrated. True integration across department boundaries is harder to achieve with disparate systems. It’s harder when those disparate systems evolve, as they must.

Let’s talk about the human dimension for a moment. It’s a rare HR workflow that can be fully automated without adverse consequence. Legito exists to augment the work of back-office professionals, not replace them. Leave space for humans to do what they do best. Legito empowers people in two contexts. Before your first colleague interacts with a Legito solution, someone needs to build it to meet your needs, leveraging the flexibility we mentioned. Cue the citizen developer (we recommend the Gartner definition if you are unfamiliar with the concept).

Legito is built on the premise that the best people to configure solutions are those who know your organization and your needs – your HR professionals, not developers. They are also best placed to ensure your solution keeps up with the pace of change.

Implementation Process

Adoption should be facilitated, not imposed. The demand for human-friendly applications is increasing because we have colleagues who consume technology, and they have high expectations. If a solution is awkward, cumbersome or mimics legacy analogue processes, it will disappoint. Use the opportunity to create something you would want to use. Optimize your chances of success by starting with small projects and seek feedback. Legito customers report that adoption is best achieved when colleagues like what they see and ask for more.

Legito case studies tell us that the success of their implementation derives from deploying a solution that is a pleasure to use.

Use of Workflow

HR matters are document-orientated, which makes them ideally suited to the Legito platform. Use rich automation templates to create documents of any complexity, and render them accessible to colleagues who might not have the inclination or knowledge to create them manually. It’s frequently necessary to make sets of documents from one data set with consistency and efficiency. Many Legito implementations will begin with a project based on document automation, often with a positive ROI for simple use cases. Document automation is a solid foundation on which to build.

When you are ready to expand from the first project, the Legito platform supports the end-to-end process. Use workflow to get approvals. Use digital signatures to execute documents. Use document management to store completed documents. Use automatic data extraction to power reminders. Build custom reports for management oversight. All these features are available within the platform without the need to integrate with other applications.

We promote Legito for enterprise-wide adoption, but organizations have to begin somewhere, and the HR team is invariably a good place to start.

Through a series of coincidences, I’ve been a close spectator of the workings of HR teams, small and large. I had a fun time as General Counsel for one of the large global outsourcing service providers serving the HR sector. Subsequently, I never seemed far away from projects that directly or indirectly interacted with HR processes. 

Too  much procedure with too little human involvement will fail business needs. Failure to reflect regulatory requirements, or inability to roll with change, leads to the same dysfunction. It’s difficult enough to blend all the requirements in just the right mix, but then you have to add volume.

Some HR tasks require specific solutions. Nobody operates the payroll without a payroll solution, for example. Many HR teams also use more generic HR applications for wider matters like absence management, maintaining HR records, and staff appraisals. Where does an application like Legito fit?

Benefits of Legito Deployment

Legito is an enterprise application – Legito’s strength is the ability to span the needs of the whole organization without loss of utility. Enterprise adoption requires a rich feature set (simple, not simplistic), intuitive use without big change management projects, and the ability to customize the solution for the needs of each team. The HR team’s organizational view is oriented around employees and their place within the enterprise – very different to, say, a finance team or a procurement team. In stark contrast to more specific solutions, we designed Legito to be flexible, to serve the wider audience. Flexibility gives HR teams access to a solution tailored for HR. More than that, the same flexibility has two more benefits: flexibility to reflect your desired way of working within HR, and flexibility to integrate the HR workflows with procedures and teams external to the HR department.

Recruitment

Consider a new joiner process, for example. A good new joiner process begins and ends outside the HR team. At one end of the process, hiring managers need to initiate recruitment. At the other end of the process, you need to pass a new joiner’s records to the IT team to provision user accounts and systems access. The handover between the HR team and other back-office teams ought to be integrated. True integration across department boundaries is harder to achieve with disparate systems. It’s harder when those disparate systems evolve, as they must.

Let’s talk about the human dimension for a moment. It’s a rare HR workflow that can be fully automated without adverse consequence. Legito exists to augment the work of back-office professionals, not replace them. Leave space for humans to do what they do best. Legito empowers people in two contexts. Before your first colleague interacts with a Legito solution, someone needs to build it to meet your needs, leveraging the flexibility we mentioned. Cue the citizen developer (we recommend the Gartner definition if you are unfamiliar with the concept).

Legito is built on the premise that the best people to configure solutions are those who know your organization and your needs – your HR professionals, not developers. They are also best placed to ensure your solution keeps up with the pace of change.

Implementation Process

Adoption should be facilitated, not imposed. Invariably, Legito case studies tell us that the success of their implementation derives from deploying a solution that is a pleasure to use. The demand for human-friendly applications is increasing because we have colleagues who consume technology, and they have high expectations. If a solution is awkward, cumbersome or mimics legacy analogue processes, it will disappoint. Use the opportunity to create something you would want to use. Optimize your chances of success by starting with small projects and seek feedback. Legito customers report that adoption is best achieved when colleagues like what they see and ask for more.

Use of Workflow

HR matters are document-orientated, which makes them ideally suited to the Legito platform. Use rich automation templates to create documents of any complexity, and render them accessible to colleagues who might not have the inclination or knowledge to create them manually. It’s frequently necessary to make sets of documents from one data set with consistency and efficiency. Many Legito implementations will begin with a project based on document automation, often with a positive ROI for simple use cases. Document automation is a solid foundation on which to build.

When you are ready to expand from the first project, the Legito platform supports the end-to-end process. Use workflow to get approvals. Use digital signatures to execute documents. Use document management to store completed documents. Use automatic data extraction to power reminders. Build custom reports for management oversight. All these features are available within the platform without the need to integrate with other applications.

We promote Legito for enterprise-wide adoption, but organizations have to begin somewhere, and the HR team is invariably a good place to start.

More Industry Insights

Charles Drayson

Jan 12 · 10 min read

Software projects in the financial services sector are a special case. The financial services sector is attractive for many vendors because the organisations command substantial budgets for software and IT services, they operate at scale, and they do what it takes to support projects for the long term. Still, financial services work in a context that brings particular requirements.

Back-Office or Costumer-Facing?

At Legito, we say our software exists to help back-office professionals. Within financial services, back-office teams do some work that is part of the customer offering, even if they do not interact directly with customers.

It will be helpful to sub-divide back-office work into at least two categories:

• Back-office processing for financial services
• Back-office support for the financial services organisation

Examples in the first category could include processing the KYC (Know Your Client) documents for anti-money laundering or issuing mortgage offer documents. The second category covers the functions of the HR team, the real estate team, the legal team, and other functions found both within and without financial services.

 Regulations

The distinction between the categories is often relevant for regulatory reasons. Within Europe, most back-office functions are familiar with working under the data protection regime. But back-office functions in financial services might also attract additional regulation if they pertain to the core financial services activities. Such regulation varies across jurisdictions, but there are common trends.

Within Europe, the European Banking Authority (EBA) publishes Guidelines on Outsourcing Arrangements which are more than mere guidelines and cover more than outsourcing. The definition of outsourcing is wide enough to potentially include the use of software-as-a-service to perform activities provided by a payment institution.

Digital transformation of back-office services critical to the delivery of financial services will be more heavily regulated than back-office services associated with more common back-office functions, like HR. There is no reason to abandon projects in the former category, but it might be easier to begin digital transformation with the latter category.

Enterprise adoption

Within some organisations, there will be people or teams with enough agency to instigate a project to deploy new systems. Aided by the growth of no-code solutions like Legito, often with free trials, citizen developers can make substantial progress without the need for IT assistance, significant budgets or enterprise support. That can still happen in financial services, but our experience is that projects need wider sponsorship before they move from non-production pilot projects. 

If financial services organisations impose more due diligence and procedural compliance to deploy new software, it makes sense to select solutions that have the widest application and the biggest potential to deliver measurable benefits. Some functions (payroll processing, for example) are sufficiently big and specialist to justify a vertical solution with no wider application. That still leaves much back-office work that is not so specialised. Moreover, solutions like payroll frequently operate at the end of a process that begins outside the scope of the application. For example, the output of a new joiner process will be the input for a payroll process. The output from the payroll process will be the input for updating a staff loan process.

Solution selection

Selecting a solution designed for enterprise adoption facilitates expansion after initial projects prove their worth. Financial services usually operate at scale, so it becomes feasible for an organisation to build a centre of excellence to leverage the experience and skills gained from initial projects. In turn, that makes it more likely that employees make an effort to acquire that experience and skill to enhance their roles and careers.

If enterprise-wide systems are more compatible with the needs of financial services, they must also accommodate the very different needs of each back-office function. The HR team, the real estate team, the legal team, the procurement team – all have different needs, diverse KPIs, and focus on different data.

At some level, they may join up, and tasks might flow between them, but it is neither desirable nor permissible to present the same views and tools to all of them. Workspaces, dashboards, reports, workflows and document stores must be customised. The customisation should be done by the people who understand best the requirements of their colleagues, which means no-code configuration that is visually intuitive without compromising data integrity, access controls or compliance.

Financial services objectives

The Economist Intelligence Unit Industry Outlook 2023, expects difficult conditions for the financial services sector in 2023. Still, the established players will benefit from resilience measures adopted over the last decade. Nevertheless, they anticipate organisations will further increase digital services to improve performance. More challenges lay ahead for new entrants who will need to curtail expenses sharply. In this sector, and at this time, cutting costs and improving performance cannot be to the detriment of the quality or responsiveness of processes that support operations.

Back-office services must play their part. If digital transformation sounds too radical in the short term, it will be imperative in the medium term. A path to incremental improvements, each delivering fast ROI without disrupting business-as-usual, will be more attractive than big projects. We expect to see the uptake of Legito-type features to augment the work of back-office teams, relieve the pressure on those teams, and facilitate performance improvements and leverage internal expertise in key functions. At a time when more colleagues are working from home, when skills shortages exist despite an economic downturn, and when employees increasingly shun pressurised working conditions, only human-friendly solutions can power digital transformation.

Compliance, command and control

“It’s easier to get forgiveness than permission” has become the rallying call of employees who espouse pragmatism in the face of bureaucracy. In many cases, they wouldn’t need that excuse if business processes were proportionate and well-designed, but that’s beyond the scope of this article. In any event, it’s not a philosophy conducive to a long career in financial services. Still, long policy documents published on SharePoint rarely promote reliable and verifiable compliance in organisations that employ as many staff as financial services.

We believe compliance is better promoted with systems that intuitively steer employees to do the right thing by default, mixed with rules to intervene for those who might be inclined to push their luck. We also believe that it’s easier to exercise oversight of systems designed with such features rather than naively assuming managers or approvers can manually scrutinise every document with 100% reliability. Financial services require compliance, command and control that is effective, not ethereal. Bland box-ticking isn’t going to fool anybody for long.

 However, the back-office of financial services deals with volume and complexity, which means systems must be simple but not simplistic. Creating the correct blend of compliance, control and agility requires a toolbox with rich features.

People like you

If you recognise your requirements in this article, talk to a Legito consultant. Legito customers include global brands with a reputation to keep – our consultants are sensitive to the needs of mature companies in regulated sectors, including financial services. 

More Industry Insights

Charles Drayson

Nov 17 · 5 min read

A business case is not the same as a predicted return on investment (ROI), even if those terms seem to be used interchangeably. The objective is to demonstrate that a project is worth doing, perhaps to gain executive support, but perhaps to satisfy yourself before you put your reputation on the line. I suggest a business case is a reason to execute a project, and an ROI is an accounting device to project a financial advantage that includes figures for the costs and the rewards. It’s useful to consider both concepts, even if you are not asked for both. Otherwise, you might overlook some gems.

Long before Legito existed, I deployed a first-generation document automation solution for a sales team of 70+ people. I had a personal need to make the project work (I was struggling to do my job without something to bring order out of chaos), but I needed a more corporate motivation to win support for the project. Some projects will have a solid business case without a compelling ROI unless you take a wide interpretation of ‘return’ in an ROI calculation (a risky approach if your audience is cynical).

Sometimes, the need to change is self-evident. Don’t let a request for an ROI obscure a manifest business need. Call the business case what it is.

My observation from supporting sales teams in the IT industry is that sponsors respond to an overwhelming business case even if they have asked for an ROI. Some bid teams try to express the business case using an ROI, and there’s no harm in that if the message isn’t lost in translation. Don’t let the numbers do a job that ought to be done by a clear statement of need. If one relies on an ROI as the principal expression of a business case, people try to assign numbers to some benefits that are tricky to express numerically with much precision or evidence. If that happens, cynics find it easy to pick a fight with the numbers, and the battle is lost.

This is a particular problem for projects designed to promote governance and compliance. You could build an ROI calculation using numbers based on projected penalties from fines or litigation. However, many organisations have no direct experience of costly litigation or the heavy hand of regulatory fines, so the numbers might look too remote. The same difficulty applies to putting a number on lost business opportunities. In some industries, an organisation wouldn’t survive to recover from a governance or compliance failure. There’s no reliable data to put a figure on lost business. In those cases, speak truth unto power and be clear about the need. If the need isn’t sufficiently compelling, the project isn’t going to get support regardless of the ROI.

The project I described as a ‘just fix a broken process’ did deliver an impressive ROI, even if that was not our objective. If you can deliver ROI while meeting business needs, it will be easier to command support. Moreover, it could be the difference between getting mere approval for deployment and getting resources needed to increase the likelihood of success (for example, a budget to buy in some external consultancy assistance).

When measuring the benefits from Legito document automation, be sure to consider the cost of people checking for errors, fixing errors, and resolving formatting issues associated with legacy document drafting.

Here is a list of metrics you might consider measuring when building an ROI calculation:

Legito projects typically start small and expand after an initial quick deployment. It is usually possible to build a good ROI for a starter project – there’s no need to over-complicate the calculation by projecting results over a long IT project.

If you need help with an ROI, the Legito consultants have the experience to provide metrics from comparable projects. However, there’s nothing like a trial project to prove them for yourself.

A business case is not the same as a predicted return on investment (ROI), even if those terms seem to be used interchangeably. The objective is to demonstrate that a project is worth doing, perhaps to gain executive support, but perhaps to satisfy yourself before you put your reputation on the line. I suggest a business case is a reason to execute a project, and an ROI is an accounting device to project a financial advantage that includes figures for the costs and the rewards. It’s useful to consider both concepts, even if you are not asked for both. Otherwise, you might overlook some gems. 

Long before Legito existed, I deployed a first-generation document automation solution for a sales team of 70+ people. I had a personal need to make the project work (I was struggling to do my job without something to bring order out of chaos), but I needed a more corporate motivation to win support for the project. Some projects will have a solid business case without a compelling ROI unless you take a wide interpretation of ‘return’ in an ROI calculation (a risky approach if your audience is cynical).

My first project appeared to be one of those. External events (think litigation, disgruntled shareholders, demanding audit conditions) transpired to deliver a clear imperative to deliver good governance of the sales / contracts /invoicing process. Cost savings, efficiencies, and cycle times were not on the list of objectives. Just fix a broken process.

Sometimes, the need to change is self-evident. Don’t let a request for an ROI obscure a manifest business need. Call the business case what it is.

My observation from supporting sales teams in the IT industry is that sponsors respond to an overwhelming business case even if they have asked for an ROI. Some bid teams try to express the business case using an ROI, and there’s no harm in that if the message isn’t lost in translation. Don’t let the numbers do a job that ought to be done by a clear statement of need. If one relies on an ROI as the principal expression of a business case, people try to assign numbers to some benefits that are tricky to express numerically with much precision or evidence. If that happens, cynics find it easy to pick a fight with the numbers, and the battle is lost.

This is a particular problem for projects designed to promote governance and compliance. You could build an ROI calculation using numbers based on projected penalties from fines or litigation. However, many organisations have no direct experience of costly litigation or the heavy hand of regulatory fines, so the numbers might look too remote. The same difficulty applies to putting a number on lost business opportunities. In some industries, an organisation wouldn’t survive to recover from a governance or compliance failure. There’s no reliable data to put a figure on lost business. In those cases, speak truth unto power and be clear about the need. If the need isn’t sufficiently compelling, the project isn’t going to get support regardless of the ROI.

Looking back on many projects related to document-orientated solutions, there was a business case that could be readily expressed with a few statements of need. Still, it was also possible to build a compelling ROI, even if some of the returns were incidental or perhaps unrelated to addressing the stated needs.

The project I described as a ‘just fix a broken process’ did deliver an impressive ROI, even if that was not our objective. If you can deliver ROI while meeting business needs, it will be easier to command support. Moreover, it could be the difference between getting mere approval for deployment and getting resources needed to increase the likelihood of success (for example, a budget to buy in some external consultancy assistance).

Before you build an ROI for Legito, take a free trial. A free trial is a great way to build confidence that you have selected the correct tool, but it is also an opportunity to experiment with a prototype solution to generate metrics for an ROI. The Legito consulting team sometimes gets involved in a trial project. Legito consultants can often build a rapid initial solution sufficient to prove capability as well as helping you to measure some initial results. Legito projects often start with a document automation project (automatic production of tailored documents using variable data) to replace a legacy process of manual document creation. The time saved from manual document creation to automated drafting is easy to measure, and frequently reveals obvious savings with irrefutable evidence.

When measuring the benefits from Legito document automation, be sure to consider the cost of people checking for errors, fixing errors, and resolving formatting issues associated with legacy document drafting.

Here is a list of metrics you might consider measuring when building an ROI calculation:

Legito projects typically start small and expand after an initial quick deployment. It is usually possible to build a good ROI for a starter project – there’s no need to over-complicate the calculation by projecting results over a long IT project.

If you need help with an ROI, the Legito consultants have the experience to provide metrics from comparable projects. However, there’s nothing like a trial project to prove them for yourself.

A business case is not the same as a predicted return on investment (ROI), even if those terms seem to be used interchangeably. The objective is to demonstrate that a project is worth doing, perhaps to gain executive support, but perhaps to satisfy yourself before you put your reputation on the line. I suggest a business case is a reason to execute a project, and an ROI is an accounting device to project a financial advantage that includes figures for the costs and the rewards. It’s useful to consider both concepts, even if you are not asked for both. Otherwise, you might overlook some gems. 

Long before Legito existed, I deployed a first-generation document automation solution for a sales team of 70+ people. I had a personal need to make the project work (I was struggling to do my job without something to bring order out of chaos), but I needed a more corporate motivation to win support for the project. Some projects will have a solid business case without a compelling ROI unless you take a wide interpretation of ‘return’ in an ROI calculation (a risky approach if your audience is cynical).

My first project appeared to be one of those. External events (think litigation, disgruntled shareholders, demanding audit conditions) transpired to deliver a clear imperative to deliver good governance of the sales / contracts /invoicing process. Cost savings, efficiencies, and cycle times were not on the list of objectives. Just fix a broken process.

Sometimes, the need to change is self-evident. Don’t let a request for an ROI obscure a manifest business need. Call the business case what it is.

My observation from supporting sales teams in the IT industry is that sponsors respond to an overwhelming business case even if they have asked for an ROI. Some bid teams try to express the business case using an ROI, and there’s no harm in that if the message isn’t lost in translation. Don’t let the numbers do a job that ought to be done by a clear statement of need. If one relies on an ROI as the principal expression of a business case, people try to assign numbers to some benefits that are tricky to express numerically with much precision or evidence. If that happens, cynics find it easy to pick a fight with the numbers, and the battle is lost.

This is a particular problem for projects designed to promote governance and compliance. You could build an ROI calculation using numbers based on projected penalties from fines or litigation. However, many organisations have no direct experience of costly litigation or the heavy hand of regulatory fines, so the numbers might look too remote. The same difficulty applies to putting a number on lost business opportunities. In some industries, an organisation wouldn’t survive to recover from a governance or compliance failure. There’s no reliable data to put a figure on lost business. In those cases, speak truth unto power and be clear about the need. If the need isn’t sufficiently compelling, the project isn’t going to get support regardless of the ROI.

Looking back on many projects related to document-orientated solutions, there was a business case that could be readily expressed with a few statements of need. Still, it was also possible to build a compelling ROI, even if some of the returns were incidental or perhaps unrelated to addressing the stated needs.

The project I described as a ‘just fix a broken process’ did deliver an impressive ROI, even if that was not our objective. If you can deliver ROI while meeting business needs, it will be easier to command support. Moreover, it could be the difference between getting mere approval for deployment and getting resources needed to increase the likelihood of success (for example, a budget to buy in some external consultancy assistance).

Try a Free Trial

Before you build an ROI for Legito, take a free trial. A free trial is a great way to build confidence that you have selected the correct tool, but it is also an opportunity to experiment with a prototype solution to generate metrics for an ROI. The Legito consulting team sometimes gets involved in a trial project. Legito consultants can often build a rapid initial solution sufficient to prove capability as well as helping you to measure some initial results. Legito projects often start with a document automation project (automatic production of tailored documents using variable data) to replace a legacy process of manual document creation. The time saved from manual document creation to automated drafting is easy to measure, and frequently reveals obvious savings with irrefutable evidence.

When measuring the benefits from Legito document automation, be sure to consider the cost of people checking for errors, fixing errors, and resolving formatting issues associated with legacy document drafting.

Here is a list of metrics you might consider measuring when building an ROI calculation:

Legito projects typically start small and expand after an initial quick deployment. It is usually possible to build a good ROI for a starter project – there’s no need to over-complicate the calculation by projecting results over a long IT project.

If you need help with an ROI, the Legito consultants have the experience to provide metrics from comparable projects. However, there’s nothing like a trial project to prove them for yourself.

More Industry Insights

Charles Drayson

Metadata is commonly defined as ‘data about data’.

The definition is concise and clever for someone with a technical understanding of metadata. It conveys no useful understanding to anyone else,. Persevere, dear reader – the learning is worth the effort, even if it won’t make you more fun at parties.

Imagine you have a SharePoint library with a PDF copy of the signed employment contracts for all your employees, past and present. Imagine you have another library with a copy of all your customer contracts. Maybe you don’t need to imagine – this is the reality for many organisations. Suppose your organisation is seeking investment and you need to provide information about those contracts. They might ask for a list of employees who have contracts that include restrictive covenants. They might ask for a list of customer contracts that include a clause dealing with ‘change of control’ of the company. You have the documents – now you need to extract the relevant ones. How do you do it?

Documents are designed to be read by humans, one at a time, and in limited quantity. Metadata is information about documents (or spreadsheets or any other type of data) that describes the contents of the documents useable by a system that wants to interrogate the data. It’s like an index but more comprehensive. Metadata acts like a pointer to the information locked up in your data.

Documents are here to stay (we still have humans), but metadata can be created in real time when the document is created, and then retained for future use. You might not know the future requirements, but you can retain the digital inputs to have the best chance of meeting those unknown requirements when they arrive.

Metadata can power dashboard and reporting features. In Legito, we extract metadata that can be used in customised workspaces so that teams get an intuitive view of current processes.

When deploying any new system, someone should consider what happens if and when you need to move your records to another system. Metadata makes it easier to migrate data between systems.

Solutions like Legito provide enhanced features by using metadata. You will see metadata mentioned in articles and white papers. This is a guide to what metadata is and what it can do for you.

Metadata is commonly defined as ‘data about data’.

The definition is concise and clever for someone with a technical understanding of metadata. It conveys no useful understanding to anyone else,. Persevere, dear reader – the learning is worth the effort, even if it won’t make you more fun at parties.

Imagine you have a SharePoint library with a PDF copy of the signed employment contracts for all your employees, past and present. Imagine you have another library with a copy of all your customer contracts. Maybe you don’t need to imagine – this is the reality for many organisations. Suppose your organisation is seeking investment and you need to provide information about those contracts. They might ask for a list of employees who have contracts that include restrictive covenants. They might ask for a list of customer contracts that include a clause dealing with ‘change of control’ of the company. You have the documents – now you need to extract the relevant ones. How do you do it?

Typical file stores are ineffective when you need to retrieve information from your organisation’s records.

When you stored the documents, did you store them in a file structure that allows you to identify the documents in each category? Even if you stored the documents in categories, you probably didn’t anticipate the particular categories you need now. And, when you store documents using sub-categories, you can only do that for one way of working – if you store employment contracts according to the department, you cannot also store the contracts by reference to role types. If you store customer contracts according to customer name, you cannot also store them by reference to product type.

If you need to store any documents using more than one filing system, you have to duplicate the contract for each filing system. If one of those documents changes, will you be able to update all the other copies that exist in the other filing systems?

If you have only a few documents, you can read them and find the information you need. It probably doesn’t matter if you store them using a simple filing system. As the number of documents increases, that task becomes error-prone and tedious. The difficulty: you have the data, but you cannot readily get to it. This is the type of problem that metadata can solve.

Conceptually, you could make it easier to locate data if you store documents in a more machine-readable format instead of a scanned copy of a signed document. You can search SharePoint for keywords within Word documents, for example. You would need a library where you store the .docx files alongside the .pdf file. Most document archives don’t have that. You would also need to construct a keyword search that extracts the files you want. It’s not easy.

Documents are designed to be read by humans, one at a time, and in limited quantity. Metadata is information about documents (or spreadsheets or any other type of data) that describes the contents of the documents useable by a system that wants to interrogate the data. It’s like an index but more comprehensive. Metadata acts like a pointer to the information locked up in your data.

Metadata preserves the digital record of transactions to future-proof information retrieval.

It’s ironic and wasteful to have systems that power organisation back-office processes and to use documents to create a record of events. Using documents as the system-of-record for contracts, processes and transactions is inherently limiting. The net effect is converting machine-readable data into a human-readable medium in a one-way conversion. It’s the one-way nature of the conversion that causes the waste. It’s hard for systems to reverse engineer the information locked up in a document in a way that is reliable and flexible. Some software promises to read legacy documents (think e-discovery systems and some AI-powered software), but it’s unlikely you will get results that have the same integrity as the original data.

Documents are here to stay (we still have humans), but metadata can be created in real time when the document is created, and then retained for future use. You might not know the future requirements, but you can retain the digital inputs to have the best chance of meeting those unknown requirements when they arrive.

Metadata can power dashboard and reporting features. In Legito, we extract metadata that can be used in customised workspaces so that teams get an intuitive view of current processes.

When deploying any new system, someone should consider what happens if and when you need to move your records to another system. Metadata makes it easier to migrate data between systems.

Metadata is not just for documents.

Metadata linked to documents is useful, but organisations usually create documents when performing a process. The process probably captures data about that is not recorded in the document (audit trails for internal approvals, for example). All related data should be retained for re-use.

Use metadata to re-perform automation.

Process automation using a tool like Legito is not limited to one-way sequential steps. Processes divert according to prevailing conditions, and sometimes a process has to be repeated with altered inputs. Customers change their mind. Approvers require changes. New information emerges. Nobody wants to re-input data when re-performing a process or regenerating a document. By retaining data through the process, it’s necessary only to enter information that needs to be updated. The previous data can be re-used.

Capturing metadata.

The benefits of metadata are magnified if you collect data all the way through a process. It’s easier to capture and re-use metadata if the end-to-end process is performed using one solution, like Legito.

More Industry Insights

Charles Drayson

Comparing automation solutions is tricky if you don’t know what the more advanced features will do or whether you need them. Is it likely that you would use only the basic features, and anything else means paying for complexity and bloat that you don’t need? The assessment is harder if this is the organisation’s first deployment of an automation solution. A demo is good, but each vendor will run a demo that looks slick.

Comparing automation solutions is tricky if you don’t know what the more advanced features will do or whether you need them. Is it likely that you would use only the basic features, and anything else means paying for complexity and bloat that you don’t need? The assessment is harder if this is the organisation’s first deployment of an automation solution. A demo is good, but each vendor will run a demo that looks slick.

​Successful projects create a demand for more. Most vendors (including Legito) advise starting with a simple project and then building incrementally. Projects which begin with large, ambitious rollouts carry risk. The first project is usually a success, unless an organisation has bought something completely unsuitable. Unfortunately, some organisations find it hard to increase adoption after the first project. What will you find when it’s time to take off the water-wings and swim in the deep end?

If you decided to invest in automation, it’s probable that some of your needs were not simple. Organisations are messy. Departments want different things. For every process, there are exceptions. You might have a standard document broadly suitable for most occasions but ideally suited to almost none. You map out a process, and then someone changes it, or you find that people are not following policies. If you over-simplify the solution, your colleagues will not use it, find ways round it, or complain loudly that it doesn’t work.

​Successful projects create a demand for more. Most vendors (including Legito) advise starting with a simple project and then building incrementally. Projects which begin with large, ambitious rollouts carry risk. The first project is usually a success, unless an organisation has bought something completely unsuitable. Unfortunately, some organisations find it hard to increase adoption after the first project. What will you find when it’s time to take off the water-wings and swim in the deep end?

If you decided to invest in automation, it’s probable that some of your needs were not simple. Organisations are messy. Departments want different things. For every process, there are exceptions. You might have a standard document broadly suitable for most occasions but ideally suited to almost none. You map out a process, and then someone changes it, or you find that people are not following policies. If you over-simplify the solution, your colleagues will not use it, find ways round it, or complain loudly that it doesn’t work.

Pareto Principle

This is why, sooner or later, you will want advanced features. The Pareto Principle still works – you will get 80% of the benefit from 20% of the features, but there are three more factors to consider:

• It’s hard to predict which features will form the 20% delivering most of the benefit.
• As you expand across the enterprise, each department might depend on different features.
• People who get good at developing solutions using Legito don’t want to stop at 80% – believe me, it’s addictive, and you will want more.

It’s like buying a car. I still remember cars without electric windows – we thought it was mad that some people would pay extra money to save the effort of winding down a window by hand. Remember manual chokes to get engines started? They were not exactly complex, but none of us looked back after electronic ignition. When cars first had air conditioning, it seemed extravagant. As for heated steering wheels, why would anyone need one? But, the driving experience with all those features is fundamentally different from the experience of the sort of cars I first drove as a teenager. There’s another similarity with buying software solutions: if you buy something basic, it might be impossible to retrofit the features you need – you have to buy again (and write off the investment in the first solution). For the manufacturers, it was hard to upgrade legacy models to compete with new modern designs.

Next-generation automation solutions compared to legacy solutions are, like modern cars, easier to use and more amenable to wide adoption by colleagues who are increasingly intolerant of mediocre technology.

What are the advanced features that make the difference?

Pareto Principle

This is why, sooner or later, you will want advanced features. The Pareto Principle still works – you will get 80% of the benefit from 20% of the features, but there are three more factors to consider:

• It’s hard to predict which features will form the 20% delivering most of the benefit.
• As you expand across the enterprise, each department might depend on different features.
• People who get good at developing solutions using Legito don’t want to stop at 80% – believe me, it’s addictive, and you will want more.

It’s like buying a car. I still remember cars without electric windows – we thought it was mad that some people would pay extra money to save the effort of winding down a window by hand. Remember manual chokes to get engines started? They were not exactly complex, but none of us looked back after electronic ignition. When cars first had air conditioning, it seemed extravagant. As for heated steering wheels, why would anyone need one? But, the driving experience with all those features is fundamentally different from the experience of the sort of cars I first drove as a teenager.

There’s another similarity with buying software solutions: if you buy something basic, it might be impossible to retrofit the features you need – you have to buy again (and write off the investment in the first solution). For the manufacturers, it was hard to upgrade legacy models to compete with new modern designs.

Next-generation automation solutions compared to legacy solutions are, like modern cars, easier to use and more amenable to wide adoption by colleagues who are increasingly intolerant of mediocre technology.

What are the advanced features that make the difference?

#1 No code development

Here’s the problem: not many people fall into that category, and even if they do, not many organisations want to pay their key staff to mess around dabbling in code just because it has some esoteric appeal. They want their lawyers to use their legal drafting skills. They want their HR professionals thinking about people-friendly processes. They want their procurement teams focused on delivering value.

#2 Workflow

#3 Dashboards

#4 Customisation

#5 Digital signatures

#6 Data mining

#7 Who knows what’s coming?

#1 No code development

I liked writing code using the first generation of document automation solutions. It was satisfying to get it right. But, I was one of those who also liked programming as a kid, and I relished the challenge. If you want your subject experts to build a solution for their teams, you could look around for people who also like messing around with code.

Here’s the problem: not many people fall into that category, and even if they do, not many organisations want to pay their key staff to mess around dabbling in code just because it has some esoteric appeal. They want their lawyers to use their legal drafting skills. They want their HR professionals thinking about people-friendly processes. They want their procurement teams focused on delivering value.

#2 Workflow

Many organisations who bought the first-generation solutions were surprised to find that the solutions generated a document and then did nothing else. The data used to create a document was mostly discarded or useless. The documents were no less and no more useful than a simple Word file. Everything else happened by email. Have your colleagues reviewed the document? No idea – email them. How many replies are you waiting for? No idea – trawl your sent items folder and see if you’ve had replies. Maybe create a list in a notepad and tick them off as they arrive. Is your document waiting for approval from someone who is on annual leave? You will need workflow. Do you have the budget and bandwidth to buy a workflow solution and integrate it with the document automation tool? Much better to have them in the same tool.

#3 Dashboards

​If you deploy an automated solution, you probably have more than a few work items to get processed. After the solution has been running for a while, you will want to manage the workload. You will want visibility of current work. You will want to retrieve information from work processed months ago.

#4 Customisation

​It’s better to have one solution that can be used across the whole enterprise, rather than each department buying its own solution. Each department might not care, but each department might not have the autonomy to fly solo on such things. However, each department will have a different requirement and a different view on your organisation’s world. That’s why you need to be able to customise. Customising a solution is more than just adding a logo and being able to select a colour scheme for the screens. True customisation means recognising that each team uses different data, different reports, and different processes. Moreover, they might want to separate one from another. The HR team does not want employee records accessible across the organisation. On the other hand, HR might want to roll out some processes (annual leave requests, new joiner processes) across all teams. This level of customisation requires software designed to be enterprise-wide.

#5 Digital signatures

​Many documents need to be signed: contracts, purchase orders, job offers, approvals, audits. If they need to be signed by more than one person, you might need to specify the order in which they get signed. In many situations, you might need to verify that a signature is genuinely applied by the person named. It might not be good enough to copy and paste a GIF image taken from your scanned hand-written signature. Signing documents the old-fashioned way is a nuisance, time consuming and increasingly it makes you look old-fashioned. Since Covid, digital signatures have dramatically increased. In my work as a lawyer, I rarely see documents signed using hand-written ‘counterparts’ scanned and emailed. If a document is to be digitally signed, generate the document in a way that is natively ready for digital signature, and integrate the workflow with a digital signature solution. It’s easier if you can do all this in one tool.

#6 Data mining

Your organisation’s total document store contains valuable data that could provide insight into your business that is available from no other source. Litigators have been looking for ways to scrutinise documents using e-discovery tools. Mercifully, there are more beneficial reasons to look back at your documents to see what you can find. That task is easier if you keep digital records about each document. Inevitably, you might want information in the future that you did not anticipate when the document was first created. The tools to extract useful information from documents and processes are starting to deliver additional value beyond the obvious automation benefits.

#7 Who knows what’s coming?

It’s a trite observation to say solutions are, in general, becoming more sophisticated. You could wait for the next new thing, but there will always be something new coming, and you might never get started. The better strategy is to buy a solution with a history of developing new features, regularly – it’s the most reliable assurance that the solution will not drift out of date.

More Industry Insights

Charles Drayson

Jul 26 · 3 min read

Documents are awkward components of digital transformation.

You store them on digital media but, ultimately, they remain analogue materials for human consumption. Advances in machine learning and artificial intelligence are as yet unable to extract full and reliable data from documents. Hell, you can put the same document in front of several humans and not even yield consistent interpretations of the content.

What can we do with those pesky documents in a quest to make things better?

Documents are awkward components of digital transformation.

You store them on digital media but, ultimately, they remain analogue materials for human consumption. Advances in machine learning and artificial intelligence are as yet unable to extract full and reliable data from documents. Hell, you can put the same document in front of several humans and not even yield consistent interpretations of the content.

What can we do with those pesky documents in a quest to make things better?

Abandon documents that we don’t need

If a document exists to present digital data in human-readable form, keep the data and create a transient document on each occasion when it’s needed. Bank statements are a good example. Who needs years of bank statements if we can reconstruct a statement (probably with more insightful data) on demand from a digital record of transactions? The veracity of a digital record is easier to verify – documents are prone to fabrication. Document assembly tools are ideal for this.

Store documents with the data that spawned them

If you must keep a document, and if the document was generated automatically from machine-readable data (just about all high volume documents), make sure you store the data (or a link to it) with the document. Systems can then read the data rather than trying to reverse engineer the document. Insurance policies, mortgage documents, employment contracts, purchase orders – all fall into this category.

If a dispute arises, someone can verify the data tallies with the document on an exceptions basis. You also mitigate the risk of a document presenting ambiguous information – you can look back at the source to resolve discrepancies. It’s helpful to have a document management system that allows such files to be collocated.

Store documents with metadata

If you cannot link a document to machine-readable data that contains the same information, tag the document with clues about what it contains. Typical metadata could include the date of the document, the name of the author, the type of document, maybe a tag to describe a related project. This might be sufficient for most reporting purposes, and reduce the task of searching for specific documents when the occasion arises. Created metadata at the same time as the document – it’s harder to tag documents retrospectively (although some AI systems are good at that).

Limit the use of documents as the sole repository of information

This requires some discipline among the teams of prospective authors. They need to understand that using a document as the medium to record the product of their work could be the least efficient way to apply their efforts.

For example, a real estate agent could feasibly create a very pleasing document describing a client’s house, with photographs, plans and descriptions. How useful is that document for analysis by anything systematic (or to share with marketing agents)? Instead, have a taxonomy for describing houses (number of rooms, dimensions, plot size, etc) and for collating plans and photographs. Compile it digitally, and then use document assembly to render descriptive documents (with the added benefit of having documents that are consistent and meet the organisation branding). Lawyers should create more legal documents this way too.

Impose a screening process before assimilating ad hoc documents into a digital system

If you must have incoming documents that don’t fall into the categories above, you do at least need to safeguard your organisation with a few steps to keep a healthy document store. The exact steps will depend on your industry but think about compliance and safeguarding.

Before you accept a document, you might want to remind users about data protection (you might want to know if documents contain personal data), security classification, password protection (if documents have to be opened by someone without a password), or simply to check if this is the correct system to be storing such documents.

Build a process for the human-in-the-loop

If documents are for human consumption, build an automated business process that has a place for the human-in-the-loop. Don’t try to replicate the nuanced, sensitive, intuitive work that only humans do well. Provide a way for humans to participate and leave their mark. Workflow tools integrated with document automation are what you need.

Abandon documents that we don’t need

If a document exists to present digital data in human-readable form, keep the data and create a transient document on each occasion when it’s needed. Bank statements are a good example. Who needs years of bank statements if we can reconstruct a statement (probably with more insightful data) on demand from a digital record of transactions? The veracity of a digital record is easier to verify – documents are prone to fabrication. Document assembly tools are ideal for this.

Store documents with the data that spawned them

If you must keep a document, and if the document was generated automatically from machine-readable data (just about all high volume documents), make sure you store the data (or a link to it) with the document. Systems can then read the data rather than trying to reverse engineer the document. Insurance policies, mortgage documents, employment contracts, purchase orders – all fall into this category.

If a dispute arises, someone can verify the data tallies with the document on an exceptions basis. You also mitigate the risk of a document presenting ambiguous information – you can look back at the source to resolve discrepancies. It’s helpful to have a document management system that allows such files to be collocated.

Store documents with metadata

If you cannot link a document to machine-readable data that contains the same information, tag the document with clues about what it contains. Typical metadata could include the date of the document, the name of the author, the type of document, maybe a tag to describe a related project. This might be sufficient for most reporting purposes, and reduce the task of searching for specific documents when the occasion arises. Created metadata at the same time as the document – it’s harder to tag documents retrospectively (although some AI systems are good at that).

Limit the use of documents as the sole repository of information

This requires some discipline among the teams of prospective authors. They need to understand that using a document as the medium to record the product of their work could be the least efficient way to apply their efforts.

For example, a real estate agent could feasibly create a very pleasing document describing a client’s house, with photographs, plans and descriptions. How useful is that document for analysis by anything systematic (or to share with marketing agents)? Instead, have a taxonomy for describing houses (number of rooms, dimensions, plot size, etc) and for collating plans and photographs. Compile it digitally, and then use document assembly to render descriptive documents (with the added benefit of having documents that are consistent and meet the organisation branding). Lawyers should create more legal documents this way too.

Impose a screening process before assimilating ad hoc documents into a digital system

If you must have incoming documents that don’t fall into the categories above, you do at least need to safeguard your organisation with a few steps to keep a healthy document store. The exact steps will depend on your industry but think about compliance and safeguarding.

Before you accept a document, you might want to remind users about data protection (you might want to know if documents contain personal data), security classification, password protection (if documents have to be opened by someone without a password), or simply to check if this is the correct system to be storing such documents.

Build a process for the human-in-the-loop

If documents are for human consumption, build an automated business process that has a place for the human-in-the-loop. Don’t try to replicate the nuanced, sensitive, intuitive work that only humans do well. Provide a way for humans to participate and leave their mark. Workflow tools integrated with document automation are what you need.

More Industry Insights

Charles Drayson

Here’s what I discovered:

#1 The No.1 tip agreed upon by people who have deployed Legito is: start small and simple, and wait for the success that will see users asking you for more. Improve and extend based on feedback – repeat.

#2 The Legito user base is international, but the stories, challenges and opportunities are remarkably similar wherever you are based.

#3 There’s valuable data generated from your everyday transactions and processes – but most organisations are not fully using it. It’s time to start mining business intelligence.

#4 Most organisations prefer to build a ‘centre of excellence’ (COE) for automation – it’s the best way to leverage automation investments across the whole enterprise. The COE can then work with subject matter experts in different teams to enable quick-start projects.

#5 Get vendors to do a demo using your process and documents – it’s the best way to see the solution in the context of your business, and you can test which vendors have agile solutions.

#6 We are blessed to have customers who are so enthusiastic to share their stories and their ideas. On the group events, it was like the delegates were all from one company – an onlooker wouldn’t know which people were from Legito and which people represented customers. It felt like one team.

#7 Prague is a must-visit city. Noel O’Connell seems to know more restaurants and bars than the locals – and they were all good.

See the PowerUp highlights below ↓

More Industry Insights

Charles Drayson

May 24 · 5 min read

Capital expenditure on software sold with a perpetual licence discouraged switching. Now, vendors sell more software on a subscription basis. The subscription model works for software vendors if most customers continue to use the software for a long time. Vendors have an incentive to reduce churn with regular updates and new features. That trend favours software deployed as software-as-a-service from a cloud-based platform. This should be good for customers: no capital expenditure (on software or hardware), regular upgrades, and less risk.

If your current solution disappoints, it should be easier to switch. Of course, it’s not quite that simple.
How do you rationalise changing to another system?

Document automation solutions have been around for years, but the market wasn’t big enough to support multiple vendors. Document automation was then limited to document assembly (generating tailored documents from templates driven by variable data provided in the form of an ‘interview’). The product was aimed at lawyers, and it’s fair to say they made productive use of document assembly, and still do. Vendors issue updates occasionally. Most updates merely extended document assembly to harness more tricky features like automating tables and keeping up with changes in Microsoft’s features and file formats.

Document assembly has evolved to be more competent and comprehensive. I’ve been using document assembly solutions for about 20 years, and it’s now rare to find a requirement that cannot be templated and automated somehow. More recently, the trend is towards improving the user experience rather than adding significant capability. If your only requirement is document assembly, it’s not difficult to find solutions that will do the job. If your organisation has already deployed a document assembly solution, there’s no reason to suppose it won’t continue to do the job.

But, why stop at document assembly?

While documents remain at the heart of many business processes, we want to automate more processes, and automate more of each process. Most humans (yes, I include lawyers in that grouping) don’t enjoy processing documents. Our organisations hand us a mandatory process, and we have to contort, negotiate and manage our way through it. Every time something changes, we have to get approvals. When we get busy, it’s hard to keep track of things using email. No wonder there’s a backlash against documents, especially long documents. They don’t fit neatly into a world that insists we get more done in less time.

It’s easy to visit a business team and find supporters who would like to ease their business processes. They know their existing methods are imperfect. Most of them could tell you what needs to be done to improve them. You can get all this feedback very easily…if you’re a colleague having a chat over a coffee at lunchtime, or if you’re a spouse who has to listen to all the things that are rubbish at the office (even the home office). They are much less likely to be forthcoming to a software sales exec! Be honest: 

Let’s look at the business case for switching to a modern document automation and document lifecycle management solution, assuming you already use an older document automation solution. 

Start your free trial

Some vendors, including Legito, will happily set you up with a free trial. Usually, it’s limited to one month, but ask Legito to extend the trial period if you need more time. If you are already using an older solution, it should be easy to pick a document to try on the new system. If you’re looking at Legito, we can usually connect you to a consultant who can help you migrate an existing template so you can see it working in your trial. This is your chance to check out two issues: how easy is it to move existing documents to the new solution, and how is the experience of using them?

Migrate existing documents

Switching from an older solution is usually quicker than starting from scratch. You have already identified the documents worth automating, and you already know how the documents work. Many of us at Legito have used older systems from other vendors, and we have helped other organisations make the switch. If you need help migrating existing documents, we can guide you on what’s involved. 

All it takes is one tool

When you switch, the first thing you’ll notice is that a solution like Legito can span your whole business process with one tool. It’s probably one of the reasons why you are thinking about the move. You don’t have to use every feature from day #1. Start with the improvements that your users will notice most. It’s easy to do more over time gradually. Aim for the smallest initial project that delivers value. Avoiding a big implementation project is an excellent way to win hearts and minds.

The ability to customise is key

Legito is easily customised – build a business case that isn’t limited to one team or process. Organisations typically deployed legacy document automation systems to provide a specific solution for a specific team. We find that organisations are switching from legacy solutions because they want to use one tool across the whole enterprise – they don’t want the overhead of managing user communities using different tools. Still, every team wants a solution that is designed for them. The HR team wants an employee-centric view of the world (offer letters, employment contracts, reference requests, joiner and leaver processes). The real estate team wants a property-centric view (lease documents, renewal reminders, facilities contracts).

Customising isn’t just about changing the look of the application (although that is nice) – it’s also about building a model of your data that matches the business needs. This ability reduces the total cost of ownership while at the same time increasing user satisfaction. If you are thinking of changing, the ability to customise (and get access to a wider range of tools within one solution) is key to ensuring you won’t outgrow the next solution.

Reduce technical debt

Switching to a no-code solution reduces technical debt. ‘Technical debt’ is a way to describe the difficulty of moving from an old code-based system to something new. It’s a concept representing the effort, cost and risk of having to re-code a solution. Some document automation solutions use scripts to deal with more complex documents, so that organisations need ‘template developers’ to create and manage them. Some users of such systems have been reluctant to walk away from a portfolio of templates that includes so much of that script. If technical debt holds you back, your applications will become increasingly harder to maintain, and users will become disillusioned. It makes sense to switch to a no-code solution.

Moreover, some of the vendors of older solutions are relying on the difficulty of moving away from their complex solutions to justify subscriptions that offer poor value for money. “They won’t move because it will be too hard for them to switch.” Is that a good reason to deprive your organisation of the benefits of a more capable solution? No, and it’s based on flawed assumptions and prejudice about the difficulty of switching.

Start your free trial

Some vendors, including Legito, will happily set you up with a free trial. Usually, it’s limited to one month, but ask Legito to extend the trial period if you need more time. If you are already using an older solution, it should be easy to pick a document to try on the new system. If you’re looking at Legito, we can usually connect you to a consultant who can help you migrate an existing template so you can see it working in your trial. This is your chance to check out two issues: how easy is it to move existing documents to the new solution, and how is the experience of using them?

Migrate existing documents

Switching from an older solution is usually quicker than starting from scratch. You have already identified the documents worth automating, and you already know how the documents work. Many of us at Legito have used older systems from other vendors, and we have helped other organisations make the switch. If you need help migrating existing documents, we can guide you on what’s involved. 

All it takes is one tool

When you switch, the first thing you’ll notice is that a solution like Legito can span your whole business process with one tool. It’s probably one of the reasons why you are thinking about the move. You don’t have to use every feature from day #1. Start with the improvements that your users will notice most. It’s easy to do more over time gradually. Aim for the smallest initial project that delivers value. Avoiding a big implementation project is an excellent way to win hearts and minds.

The ability to customise is key

Legito is easily customised – build a business case that isn’t limited to one team or process. Organisations typically deployed legacy document automation systems to provide a specific solution for a specific team. We find that organisations are switching from legacy solutions because they want to use one tool across the whole enterprise – they don’t want the overhead of managing user communities using different tools. Still, every team wants a solution that is designed for them. The HR team wants an employee-centric view of the world (offer letters, employment contracts, reference requests, joiner and leaver processes). The real estate team wants a property-centric view (lease documents, renewal reminders, facilities contracts).

Customising isn’t just about changing the look of the application (although that is nice) – it’s also about building a model of your data that matches the business needs. This ability reduces the total cost of ownership while at the same time increasing user satisfaction. If you are thinking of changing, the ability to customise (and get access to a wider range of tools within one solution) is key to ensuring you won’t outgrow the next solution.

Reduce technical debt

Switching to a no-code solution reduces technical debt. ‘Technical debt’ is a way to describe the difficulty of moving from an old code-based system to something new. It’s a concept representing the effort, cost and risk of having to re-code a solution. Some document automation solutions use scripts to deal with more complex documents, so that organisations need ‘template developers’ to create and manage them. Some users of such systems have been reluctant to walk away from a portfolio of templates that includes so much of that script. If technical debt holds you back, your applications will become increasingly harder to maintain, and users will become disillusioned. It makes sense to switch to a no-code solution.

Moreover, some of the vendors of older solutions are relying on the difficulty of moving away from their complex solutions to justify subscriptions that offer poor value for money. “They won’t move because it will be too hard for them to switch.” Is that a good reason to deprive your organisation of the benefits of a more capable solution? No, and it’s based on flawed assumptions and prejudice about the difficulty of switching.

More Industry Insights

Charles Drayson