diff --git a/docs/byoc/installation.md b/docs/byoc/installation.md
index 8151fdb0..776fe42f 100644
--- a/docs/byoc/installation.md
+++ b/docs/byoc/installation.md
@@ -25,6 +25,8 @@ Quix recommends a production ready Kubernetes cluster, with HA control plane and
 
 In this step you will be receiving a username / API token and docker registry URL. These will be provided to you by Quix before you start the installation process.
 
+    [Contact sales](https://share.hsforms.com/1iW0TmZzKQMChk0lxd_tGiw4yjw2)
+
 ## 3. Obtain a copy of the Quix Platform BYOC installer (Ansible Recipe + Docker Image)
 
 With the provided API key you can download the installer from our private Container Registry. The installer is a Docker image that contains an Ansible recipe and all the required dependencies to run it. This way you don't need to install Ansible (and its particular Python version dependencies), Helm and all the other programs and libraries required to run the installer. We have packaged it all to offer a turn-key, convenient experience.
diff --git a/docs/byoc/requirements.md b/docs/byoc/requirements.md
index 41e21334..786b60e7 100644
--- a/docs/byoc/requirements.md
+++ b/docs/byoc/requirements.md
@@ -8,9 +8,9 @@ The requirements are designed to ensure that the platform will run effectively a
 
 To ensure the success of the installation process, the following essential requirements must be fulfilled:
 
-- For running the installer: A computer capable of running Linux containers. It may be either a physical or a virtual machine. This computer should run Linux, MacOS, or Windows (using Docker Desktop or WSL), and it may have either an aarch64 (arm64, Apple Silicon in most cases) or amd64 architecture. This will only be used to run the installation scripts.
+- For running the installer: A computer capable of running Linux containers. It may be either a physical or a virtual machine. This computer should run Linux, MacOS, or Windows (using Docker Desktop or WSL), and it may have either an aarch64 (ARM64, Apple Silicon in most cases) or AMD64 architecture. This will only be used to run the installation scripts.
 - For running the installer: A kubectl client that has already been configured to communicate with this cluster. This client must be able to communicate with the cluster from the computer running the installation scripts. 
-- To run the platform: A Kubernetes cluster that has already been set up.
+- To run the platform: An AMD64 Kubernetes cluster that has already been set up.
 - Sufficient permissions to create a service account, manage limited tokens, and create new namespaces and other resources.
 
 ## Kubernetes cluster minimum requirements
diff --git a/docs/get-started/cli.md b/docs/get-started/cli.md
index 3142e7b6..95a932a0 100644
--- a/docs/get-started/cli.md
+++ b/docs/get-started/cli.md
@@ -55,7 +55,7 @@ There are two ways to obtain this:
     Run the following command:
 
     ```
-    quix workspaces get
+    quix workspaces list
     ```
 
     This lists all workspaces in the organization, and displays the workspace ID, along with the following:
@@ -112,7 +112,7 @@ quix command [subcommand] [options]
 To list all your deployments you would use:
 
 ```
-quix deployments get --workspaceId your-workspace-id
+quix deployments list your-workspace-id
 ```
 
 The information returned includes:
@@ -130,7 +130,7 @@ The information returned includes:
 To list all your applications (in your environment):
 
 ```
-quix applications get your-workspace-id
+quix applications list your-workspace-id
 ```
 
 ## Obtaining output in JSON format
@@ -138,7 +138,7 @@ quix applications get your-workspace-id
 You can return your results as JSON, rather than in tabular form. For example, to return a list of topics in an environment in JSON format:
 
 ```
-quix topic get your-workspace-id --output json
+quix topics list your-workspace-id --output json
 ```
 
 With some practice, you will find the usage follows a similar pattern for most commands.
@@ -168,7 +168,7 @@ quix contexts use byoc
 To list your available contexts, use the following:
 
 ```
-quix contexts get
+quix contexts list
 ```
 
 ## Managing permissions
@@ -189,10 +189,11 @@ Scope is hierarchical. For example, if you assign a user a role at the `Organisa
 
 Role can be one of:
 
-* Admin - complete control
-* Editor - sync, permissions, logs, start/stop deployments
-* Viewer - view only
-
+* `Admin` - complete control
+* `Manager` - complete control except editing users, billing and organisation
+* `Editor` - same as `Manager` without permissions of create or delete Repositories and Workspaces
+* `Viewer` - read only permissions
+  
 Roles are assigned to specific users.
 
 ### Users
@@ -216,13 +217,13 @@ This returns your:
 To obtain a complete list of users in an organization, use the following command:
 
 ```
-quix users get
+quix users list
 ```
 
 To narrow down the returned list:
 
 ```
-quix users get | grep tony
+quix users list | grep tony
 ```
 
 This returns:
@@ -240,13 +241,13 @@ You can also use the CLI to explore permissions.
 To get a complete list of users and their permissions:
 
 ```
-quix permissions get
+quix permissions list
 ```
 
 You can reduce the list using:
 
 ```
-quix permissions get | grep tony
+quix permissions list | grep tony
 ```
 
 This returns:
@@ -324,7 +325,7 @@ This sets the following permissions for the specified repository and workspace:
 
 !!! tip
 
-    Repository IDs can be found by typing `quix repositories get`.
+    Repository IDs can be found by typing `quix repositories list`.