diff --git a/_search-plugins/concurrent-segment-search.md b/_search-plugins/concurrent-segment-search.md
index 4bc0e5ca765..4a1f74f7b03 100644
--- a/_search-plugins/concurrent-segment-search.md
+++ b/_search-plugins/concurrent-segment-search.md
@@ -82,6 +82,14 @@ The `search.concurrent.max_slice_count` setting can take the following valid val
 - `0`: Use the default Lucene mechanism.
 - Positive integer: Use the max target slice count mechanism. Usually, a value between 2 and 8 should be sufficient.
 
+## General Guidelines
+Concurrent segment search helps to improve the performance of search requests at the cost of consuming more resources such as CPU, JVM, etc. It is important to try your workload to understand if the domain is sized correctly for concurrent segment search or not. We recommend the following guidelines to follow to enable concurrent segment search:
+
+* Start with a slice count of 2 and measure the performance of your workload. If resource utilization is exceeding the recommended values then consider scaling your cluster. Generally based on our testing we have observed that if your workload is already consuming more than 50% of the CPU resources, then you will need to scale your domain for concurrent segment search.
+* With a slice count of 2 if you still have available resources in the domain, then you can increase the slice count to higher number such as 4 or 6 and observe the search latency along with resource utilization on the domain. 
+* With a large number of clients sending search requests in parallel, usually a lower slice count works better. This can again be reflected in the CPU utilization, since more clients means higher TPS which will translate to higher usage of resources.
+
+
 ## Limitations
 
 The following aggregations do not support the concurrent search model. If a search request contains one of these aggregations, the request will be executed using the non-concurrent path even if concurrent segment search is enabled at the cluster level or index level.