diff --git a/doc/service_design/kubernetes/helm/HELM_Installation_aaS_Jenkins_Example.md b/doc/service_design/kubernetes/helm/HELM_Installation_aaS_Jenkins_Example.md
index df368c50f764c87a94d9c85cdede7d7fcb4d77f5..2a865e1ec32b362e6c75b46a12c67729292732be 100644
--- a/doc/service_design/kubernetes/helm/HELM_Installation_aaS_Jenkins_Example.md
+++ b/doc/service_design/kubernetes/helm/HELM_Installation_aaS_Jenkins_Example.md
@@ -12,7 +12,7 @@ In this example, we will use the ```Kind: Application``` of ArgoCD and create a
 	4. Go to Resource Specification Relationships
 	5. Assign **Application@argoproj.io/v1alpha1@kubernetes@https://10.10.10.144:6443/** as a related Resource Specification
 
-> Please note that the *https://10.10.10.144:6443/* part of the Resource Specification's name will vary in different Kubernetes installations. 
+> Please note that the *https://10.10.10.144:6443/* part of the Resource Specification's name will vary in different Kubernetes environments. 
 
 
 ![img02.png](./img02.png)
@@ -23,12 +23,10 @@ Specifically, we need to map the lifecycle of ArgoCD Application (e.g. Progressi
 
 In ArgoCD, the field **status.health.status** has the value that we need to check (Healty, Progressing, etc) for the lifecycle of the application. This is captured by the **_CR_CHECK_FIELD** characteristic.
 
-Also, the different ArgoCD lifycycle states must be captured by the respective **_CR_CHECKVAL_xxx** characteristics, as show in the figure below.
+Also, the different ArgoCD lifycycle states must be captured by the respective **_CR_CHECKVAL_xxx** characteristics, as show in the figure below:
 
 ![img05.png](./img05.png)
 
-
-
  
 After the state mapping, we must provide the template that ArgoCD will use to deploy the Jenkins HELM Chart as an ArgoCD application. For this, we must populate the **_CR_SPEC** characteristic. The _CR_SPEC can be designed first in a YAML or json editor for better parsing. 
 
@@ -72,12 +70,12 @@ spec:
 > **NOTE 1**: The above template assumes that the Jenkins Server will acquire a **ClusterIP**. The user should handle the external exposure and access of the Jenkins Server, depending on its cluster configuration. Also, **persistency of the data is disabled** to facilitate the deployment without the need to define storage classes and volumes, as this serves as an example. 
 
 ```yaml
-    helm:
-      values: |
-        controller:
-         serviceType: ClusterIP
-        persistence:
-         enabled: false
+helm:
+  values: |
+    controller:
+      serviceType: ClusterIP
+    persistence:
+      enabled: false
 ```
 
 > **NOTE 2**: On each installation, OSOM will change the name of the resource in order to be unique (will have a UUID), instead of "openslice-jenkins".
@@ -88,10 +86,10 @@ name: openslice-jenkins
  
 > **NOTE 3**: The namespace that ArgoCD will use to deploy the Jenkins HELM Chart is the "opencrdtest".
  
- ```yaml
- destination:
-    namespace: opencrdtest
- ```
+```yaml
+destination:
+  namespace: opencrdtest
+```
  
 **The latter implies that ArgoCD will always install Jenkins in the same namespace.**
 
@@ -102,7 +100,9 @@ The LCM rule can be created from the "Life Cycle Rules" tab, pressing the "Creat
 
 ![img06.png](./img06.png)
 
- 
+
+Let's create it step-by-step:
+
 1. Drag-Drop the _CR_SPEC block (Set characteristic value) of jenkinsrfs from the Service > Text blocks
 2. Drag-Drop the Text > Formatted text block and attach it after the block from the previous step
 3. Drag-Drop the Text > Multi-line text input block and attach it at the Input(String) connector of the block from the previous text 
@@ -127,18 +127,18 @@ To expose a service towards the users, the designer must create the respective C
 ![img04.png](./img04.png)
 
  
-Next, expose it through an already created Service Catalog and Service Category so as to make it visible to the users, thus available for ordering.
+Next, the designer must expose it through an already created Service Catalog and Service Category so as to make it visible to the users, thus available for ordering.
   
 ![img061.png](./img061.png)
 
 
 
 
-## Order the service
+## Order the Jenkins Service
 
-Order the service from the assigned Service Catalog > Service Category. 
+Order the service from the previously assigned Service Catalog > Service Category. 
 
-As soon as the Service Order is in **ACKNOWLEDGED** state, it will be processed and eventually completed rendering the services active, as seen in the figure below:
+As soon as the Service Order is in **ACKNOWLEDGED** state (may require user intervention as the initial Service Order state is "INITIAL"), it will be processed and eventually completed rendering the services active, as seen in the figure below:
 
 
 ![img07.png](./img07.png)