diff --git a/spring-cloud-contract.html b/spring-cloud-contract.html
index 69a005f81d..d0656df44a 100644
--- a/spring-cloud-contract.html
+++ b/spring-cloud-contract.html
@@ -1614,36 +1614,38 @@ public void shouldBeRejectedDueToAbnormalLoanAmount() {
 <pre class="highlight"><code class="language-groovy" data-lang="groovy">package contracts
 
 org.springframework.cloud.contract.spec.Contract.make {
-			request { // (1)
-				method 'PUT' // (2)
-				url '/fraudcheck' // (3)
-				body([ // (4)
-					clientId: value(consumer(regex('[0-9]{10}'))),
-					loanAmount: 99999
-					])
-				headers { // (5)
-					contentType("application/vnd.fraud.v1+json")
-				}
-			}
-			response { // (6)
-				status 200 // (7)
-				body([ // (8)
-					fraudCheckStatus: "FRAUD",
-					rejectionReason: "Amount too high"
-				])
-				headers { // (9)
-					contentType("application/vnd.fraud.v1+json")
-				}
-			}
+	request { // (1)
+		method 'PUT' // (2)
+		url '/fraudcheck' // (3)
+		body([ // (4)
+			   clientId: $(regex('[0-9]{10}')),
+			   loanAmount: 99999
+		])
+		headers { // (5)
+			contentType('application/vnd.fraud.v1+json')
+		}
+	}
+	response { // (6)
+		status 200 // (7)
+		body([ // (8)
+			   fraudCheckStatus: "FRAUD",
+			   rejectionReason: "Amount too high"
+		])
+		headers { // (9)
+			contentType('application/vnd.fraud.v1+json')
+		}
+	}
 }
 
 /*
 Since we don't want to force on the user to hardcode values of fields that are dynamic
-(timestamps, database ids etc.), one can provide parametrize those entries by using the
-`value(consumer(...), producer(...))` method. That way what's present in the `consumer`
-section will end up in the produced stub. What's there in the `producer` will end up in the
-autogenerated test. If you provide only the regular expression side without the concrete
-value then Spring Cloud Contract will generate one for you.
+(timestamps, database ids etc.), one can parametrize those entries. If you wrap your field's
+ value in a `$(...)` or `value(...)` and provide a dynamic value of a field then
+ the concrete value will be generated for you. If you want to be really explicit about
+ which side gets which value you can do that by using the `value(consumer(...), producer(...))` notation.
+ That way what's present in the `consumer` section will end up in the produced stub. What's
+ there in the `producer` will end up in the autogenerated test. If you provide only the
+ regular expression side without the concrete value then Spring Cloud Contract will generate one for you.
 
 From the Consumer perspective, when shooting a request in the integration test: