clarity and tone improvements

Author: vladvelici

src/pages/docs/guides/chat/build-task-oriented.mdx

@@ -25,10 +25,7 @@ Ably is trusted by organizations delivering chat to millions of users in realtim
 
 Delivering chat messages in realtime is key to a smooth online experience. Ably's [serverless architecture](/docs/platform/architecture) eliminates the need for you to manage websocket servers. It automatically scales to handle millions of concurrent connections without provisioning or maintenance. Ably also handles all of the edge-cases around delivery, failover and scaling.
 
-Despite the challenges of delivering these guarantees, Ably is designed to keep costs predictable.
-You can choose between MAU-based (more predictable for a known number of users) or per-minute pricing (consumption-based, pay for what you use), depending on your needs.
-Both pricing models are designed to be cost-effective and scalable.
-Features such as efficient connection management are available to help you reduce costs.
+Despite the challenges of delivering these guarantees, Ably is designed to keep costs predictable. You can choose between MAU-based (more predictable for a known number of users) or per-minute pricing (consumption-based, pay for what you use), depending on your needs. Both pricing models are designed to be cost-effective and scalable. Features such as efficient connection management are available to help you reduce costs.
 
 ## Architecting your task-oriented chat: UX first, scale always
 
@@ -47,19 +44,18 @@ For large-scale chat scenarios with many users per room, see our [building lives
 Each room includes all task participants: customers and agents in support, buyers and sellers in marketplaces, players in games, team members in projects. Participants can join and leave as the task evolves. Access to message history and other features can be granted to all or select participants via capabilities.
 
 Key considerations for task-oriented chat rooms:
-- When will the room be joined by participants and how will it be linked to the task (delivery, support ticket, game session and so on)?
-  - For something like support, you could create a ticket when the user opens the chat window in the UI and perhaps provides a name or category for the request. First create a support ticket, and also deliver a token for authentication and room name for the user to join.
-  - For games it can be one room per game session (such as a chess game), or for a MMORPG, each quest or location could be allocated a room.
-  - For deliveries, appointments, calls, there is usually a clear 1:1 mapping of task to room, and typically users join the room when they join the task.
+- When will the room be joined by participants and how will it be linked to the task (delivery, support ticket, game session and so on)? Examples:
+  - For something like support, create a ticket when the user opens the chat window; optionally ask for some details before creating the ticket. Return an authentication token and room name with the new ticket details, the user will then join using this information.
+  - For games, use one room per game session for games such as chess, or for a MMORPG, allocate a room for each location of instance of a quest.
+  - For deliveries, appointments, or calls, there is a clear 1:1 mapping of task to room and users join the room when they join the task.
 - Does the room have to be active for the whole duration of the task, or just sometimes?
   - Only attaching to rooms when they are needed is more cost-effective and saves resources.
   - For example, during a delivery, the chat room doesn't always have to be active. With a good strategy for push notifications to alert inactive users of new messages, they can attach for very short periods of time for each delivery.
 - Do you need any spam prevention measures applied before allowing users to join rooms?
-  - For example, in a support chat scenario, you could add a captcha or other measures before creating a new ticket and issuing a token that allows the user to join the room for that ticket.
+  - For example, in a support chat scenario, use a captcha or other measures before allowing users to join a room or create a new ticket.
 - Do you need long-term archiving of the chat history?
   - Check out the guide for [exporting chat data](/docs/guides/chat/export-chat) for an overview of your options.
 
-
 ## Authentication
 
 Authentication is a design decision. 
@@ -239,9 +235,7 @@ while (true) {
 ```
 </Code>
 
-You can use our [React UI Kit](/docs/chat/react-ui-kit) to easily create a [fully featured chat window](/docs/chat/getting-started/react-ui-kit#chat-window) 
-that handles subscribing to messages, loading history, message updates and deletes, message reactions, and more.
-See the [React UI Kit](/docs/chat/react-ui-kit) for more details.
+You can use our [React UI Kit](/docs/chat/react-ui-kit) to easily create a [fully featured chat window](/docs/chat/getting-started/react-ui-kit#chat-window)  that handles subscribing to messages, loading history, message updates and deletes, message reactions, and more. See the [React UI Kit](/docs/chat/react-ui-kit) for more details.
 
 ## Enriching tasks with Ably's realtime services
 
@@ -261,8 +255,7 @@ Effective moderation ensures your task-oriented chats remain professional, safe,
 
 Ably supports [moderating messages](/docs/chat/moderation) both before and after publication, making it easy to integrate with AI-powered or human moderation systems.
 
-* **After-publish moderation:** Messages appear instantly, then are removed if flagged as inappropriate.
-Best for most task-oriented scenarios, where immediacy often matters. It can be used to detect abusive behaviour or inappropriate content after the fact.
+* **After-publish moderation:** Messages appear instantly, then are removed if flagged as inappropriate. Best for most task-oriented scenarios, where immediacy often matters. It can be used to detect abusive behaviour or inappropriate content after the fact.
 * **Before-publish moderation:** Messages are held until approved. Use this for high-stakes tasks where every message must be vetted.
 
 ### Key moderation considerations for task-oriented chat
@@ -350,7 +343,7 @@ await room.reactions.send({name: '👍'});
 
 Network disruption happens - mobile internet loses signal or someone drives through a tunnel. All of Ably's SDKs are designed with this in mind, so that you don't have to handle complicated reconnection logic.
 
-Every SDK instance keeps track of where it's at in the message stream. If the connection is lost, the library will  [automatically attempt to reconnect](/docs/platform/architecture/connection-recovery) to the servers and in doing so, resume its position in the stream. This enables the chat to continue as if the user never left. After extended periods of disconnection, the client can make use of [history](#history) to backfill missing messages.
+Every SDK instance keeps track of its own position in the message stream. If the connection is lost, the library will [automatically attempt to reconnect](/docs/platform/architecture/connection-recovery) to the servers and in doing so, resume its position in the stream. This enables the chat to continue as if the user never left. After extended periods of disconnection, the client can make use of [history](#history) to backfill missing messages.
 
 It's incredibly rare, but sometimes a client might lose connection to a particular data center. Ably operates in multiple data centers around the world with multiple fallback regions available. If a client can't reach the nearest data center, it will try the next one until the connection is re-established, ensuring minimal downtime and that network issues don't disrupt the experience that you are trying to build. Ably's [fault tolerance guide](/docs/platform/architecture/fault-tolerance) describes how we do this and shows that even if an entire region goes down, it has little-to-no impact on the global service and your application.