diff --git a/_examples/basic/6-cqrs-ordered-events/README.md b/_examples/basic/6-cqrs-ordered-events/README.md
index 9581cc34..e90f6fdd 100644
--- a/_examples/basic/6-cqrs-ordered-events/README.md
+++ b/_examples/basic/6-cqrs-ordered-events/README.md
@@ -4,7 +4,7 @@ This application is using [Watermill CQRS](http://watermill.io/docs/cqrs) compon
 
 Detailed documentation for CQRS can be found in Watermill's docs: [http://watermill.io/docs/cqrs#usage](http://watermill.io/docs/cqrs).
 
-This example, uses event groups to maintain order of events. You can read more about them in the [Watermill documentation](https://watermill.io/docs/cqrs/).
+This example, uses event groups to keep order for multiple events. You can read more about them in the [Watermill documentation](https://watermill.io/docs/cqrs/).
 We are also using Kafka's partitioning keys to increase processing throughput without losing order of events.
 
 
@@ -23,6 +23,10 @@ The system maintains:
 If events won't be ordered, and `SubscriberSubscribed` would arrive after `SubscriberUnsubscribed` event,
 the subscriber will be still subscribed.
 
+## Possible improvements
+
+You may consider creating sub-topics xxxx
+
 ## Running
 
 ```bash
diff --git a/docs/content/docs/cqrs.md b/docs/content/docs/cqrs.md
index e0daa035..2923f2a2 100644
--- a/docs/content/docs/cqrs.md
+++ b/docs/content/docs/cqrs.md
@@ -135,16 +135,14 @@ In the scenario, when we have multiple event types on one topic, you have two op
 **Key differences between `EventProcessor` and `EventGroupProcessor`:**
 
 1. `EventProcessor`:
-- Each handler has its own subscriber
+- Each handler has its own subscriber instance
 - One handler per event type
 - Simple one-to-one matching of events to handlers
+
 2. `EventGroupProcessor`:
-- Multiple handlers share a single subscriber
-- Can have multiple handlers for the same event type
-- Iterates through all handlers in the group
-- Message is considered processed if at least one handler processes it
-- All handlers in a group receive messages in the same order
-- If one handler fails, the message is nacked and will be redelivered to all handlers
+- Group of handlers share a single subscriber instance (and one consumer group, if such mechanism is supported)
+- One handler group can support multiple event types,
+- When message arrives to the topic, Watermill will match it to the handler in the group based on event type
 
 ```kroki {type=mermaid}
 graph TD
@@ -166,6 +164,9 @@ graph TD
     end
 ```
 
+**Event Handler groups are helpful, when you have multiple event of different types, and you want to maintain order of events.**
+Thanks to using one subscriber instance and consumer group, events will be processed in the order they were sent.
+
 {{< callout context="note" title="Note" icon="outline/info-circle" >}}
 It's allowed to have multiple handlers for the same event type in one group, but we recommend to not do that.