September 16, 2021 12:00 PM EDT
Automation for insurance carriers & brokersSeptember 16, 2021 12:00 PM EDT
Learn how utilizing a digital workforce can help your employees focus on their main priority - the clients!

Documenting the process ✏️

After you have identified a process as a good candidate for automation, the first step is to document it in detail. This documentation will then serve as the basis for implementing the software robot that will take over and handle the process in the future.

During this requirements gathering phase, the software robot developer needs to work closely with the business side to get familiar with the current process and the business domain in which it runs. This often means sitting next to the user when the process is run, asking all relevant questions, and exploring all possible cases.

The Process Definition Document (PDD)

The result of this analysis phase is collected into a document called Process definition document, which is then shared with all the relevant people involved, approved, and signed off.

Contents of the PDD document

An effective PDD document should provide clear answers to these questions:

  • What is the process used for, and what is its end goal?
  • What are the steps involved in the process? Are there any decision points?
  • Who is in charge of the process?
  • By whom and how often is the process executed?
  • What are the systems involved in the process?
  • Does the user need special authorization or roles to run the process?
  • What are the possible problems and exceptions that can happen during the procedure? How does the user handle those?

Bonus: Download our process definition document template

We are happy to share our process definition document template that you can use freely in your next RPA project.

Let's write the PDD for Maria's case

Let's see together how a process definition document for Maria's case would look like.

Surprise! We have made the PDD document for you already. You can download it here and follow along:


Process name

First of all, we need to come up with a name to identify the process. The business might have a name for it already.

In our case, we have gone for "Weekly sales report creation", which is what Maria calls it (In public. She has other names for it, especially when she makes a mistake 🤬).

Document metadata


You should set up your document so that it is easy to update and archive. If you are not using a versioning system, we recommend adding the version in the file name and adding a table inside the document to show the current and previous versions.

Sign off

The information contained in the document is part of the specification that will be used to develop the software robot, so it must be verified to be accurate and signed off by the business side.

This sign-off from the business side is of fundamental importance to ensure that all stakeholders are on the same page. For the same reason, if the process being automated changes during the project, a new version of the document has to be created and signed off again by the relevant people. Also, the PDD is often the basis to calculate the required budget for the automation, and changing requirements will most likely impact it.

So, make sure that the PDD matches reality, and it has been signed-off.

In our example, we probably will require Maria's sign-off, and since the process has been the same for years, we should be safe.


List the people that have collaborated in creating the document. It will be useful to record the key people on the business side who know about the process also in the future.

In our example, we would list ourselves!

Current process analysis

This section is where you will use your analysis skills to describe how the client is handling the process now before you move in and optimize and automate it like a pro.

  • What steps someone inside the company has to take each time to make this process work?
  • How often is the process executed?
  • What software do they have to use?
  • Where do they get the information they need?
  • What happens if something goes wrong (how to resolve the situation, who to notify of failures, what parties does the failure affect)?

All these questions need to be answered in this section.

High level description

Here you should give an overview of the process. What is this process for? How often do they run it? When do they run it? Who runs it? What are the steps?

This overview description should be crystal clear and not too long to read.

Systems involved

Processes that are a good fit to be automated by RPA often span across different systems. For example, one could be a web application, another a legacy system, or even just a spreadsheet.

List in this section the systems involved. Don't forget to explain what they are used for and if the user needs to have particular authorization roles or rights because the robot will probably need to have them as well!

For our example, we will have Microsoft Excel, the Intranet, and Microsoft Word listed here.

Process flow

One of the best ways to show the steps of a process is via a flowchart, a widely used convention when describing procedures and algorithms.

There is a variety of software to easily create flow charts: good options for example are Diagrams.net (free) or Lucidchart (free with paid option), or Microsoft Visio (paid).

Here's how the process flow looks like for our example:

PDD robotsparebin flowchart

Detailed steps

This section of the document is the most crucial one: here, you will break down the process into all its steps, and for each one, you will provide all the information needed.

Try to imagine that you are explaining this to someone who knows nothing about the process: after reading your instructions, they should be able to complete the process on their own.

A good name for a step for example is in the format <operator> <action> <object of the action>. For example: "Employee downloads the Excel file". This is not a hard rule though, just make sure that the name clearly and concisely describes the step.

In each step's description, you are free to add anything that you think will help explain it better: screenshots of the user interface, the schema of the data involved, etc.

Possible exceptions

So far, you have described an ideal case where the operator has all the data they need, all systems work perfectly together, and the result is achieved.

This is not always the case: there are times when the process does not run that smoothly or cannot be completed for various reasons: we call these cases "Exceptions".

Exceptions can be of two types:

  • Logic exceptions: Logic exceptions happen when something is wrong with the information that is being processed. For example, if an order has incomplete data, the operation has to stop. Or maybe the business requires specific rules that the operator knows about: "do not sell more than ten pieces a day for that product". These need to be written down carefully because the robot will have to follow the same rules.

  • System exceptions: Software can have bugs, network connections can fail, passwords can no longer be valid: in all these cases, we say that a system exception has happened. Write down all these possible cases, explain what the operator sees, and if there are ways to get around them.

In our example, a logic exception happens if Maria types her password wrong, and a system exception is a server error that she reports to see sometimes.