It is an application that allows the internal management of typical service request processes within the banking world and controls the established SLAs through the use of BPT components. Adapting to other industries is clearly viable and quite realistic, especially in large organizations which, as the banking industry, have specialized Back Office units that provide services to commercial Front Office units.

Usually this type of system replaces processes based on email exchange. In this way, structured, transparent, monitored and naturally tracked management of all information involved is guaranteed.

How does it work?

The basic process must go through the Created, Submitted and Approved states. It may, however, after Submitted, become Rejected, thus creating the need to be Submitted again (Resubmitted). It may also, after Submitted, become Executed and await final approval. This happens when the user only has permission to execute, but does not have permission to approve, which is the case with the Executor Role. Only the Supervisor Role can approve the request and thus close the process.

The Admin Role can create types of processes/requests based on the typical process. For each type of request, an SLA time is established and a Team of Executors and Supervisors is assigned. SLA times are set in minutes for demonstration purposes.

Executors can execute requests and Supervisors can execute and/or approve requests. Executors and Supervisors can also reject requests and write comments and attach documents to it. Executors and Supervisors can belong to more than one team, which means that each of them can handle different types of requests.

The Cliente Role (in this context they are internal clients belonging to the same organization) allows you to create the request, attaching documents, and submitting it. Once submitted, the request becomes part of the Worklist of the team assigned to the corresponding type of request and the SLA time starts to count.

For each request submitted, if it does not progress to another status, and when 50% of the established SLA time is reached, the system creates a notification. The same happens when 100% of the SLA time is reached. This action, which in BaseProcess materializes with the creation of an entity in the DB, can easily be complemented in the future by a notification via SMS, Chat or Email.

In short: Once the Created request is Submitted, it can evolve into 3 states: Approved, Executed or Rejected. Once Executed, it can only progress to Approved. If Rejected, it can only evolve back to Submitted. The sequence of states experienced by each request is fully recorded by the system. Note that if a submitted request progresses directly to approved, the Executed status will be bypassed and will not be part of the request history.

The App at this stage has not yet included a well-deserved statistics module to analyze the data and support future decisions regarding the management of all the service processes involved. Maybe in future versions, in specific project contexts.