apply feedback, change M&B color for top nav, remove discounts page

Signed-off-by: Diana <[email protected]>

Author: cloudjumpercat

app/_assets/stylesheets/index.css

@@ -110,8 +110,8 @@
     --color-operator-background: var(--color-semantic-blue-secondary);
     --color-api-products-brand: var(--color-semantic-orange-primary);
     --color-api-products-background: var(--color-semantic-orange-secondary);
-    --color-metering-and-billing-brand: var(--color-semantic-grey-primary);
-    --color-metering-and-billing-background: var(--color-semantic-grey-secondary);
+    --color-metering-and-billing-brand: var(--color-semantic-orange-primary);
+    --color-metering-and-billing-background: var(--color-semantic-orange-secondary);
   }
 
   .dark {

app/_how-tos/get-started-with-metering-and-billing.md

@@ -141,7 +141,10 @@ In {{site.metering_and_billing}}, meters track and record the consumption of a r
 In this guide, you'll enable API Gateway requests for metering. This will meter API request traffic in {{site.metering_and_billing}} so that you can charge customers for API traffic usage.
 
 1. In the {{site.konnect_short_name}} sidebar, click **{{site.metering_and_billing}}**.
-1. Enable **API Gateway Requests**.
+1. In the API Gateway Requests settings, click **Enable Gateways**.
+1. Select the "quickstart" control plane.
+1. Click **Enable 1 Gateways**.
+
 
 ## Create a feature
 

app/_includes/konnect/metering-and-billing/discounts.md

@@ -14,44 +14,9 @@ rows:
   - discount: Percentage discount
     description: "Reduces price by a fixed percent across all usage."
   - discount: "[Usage discount](#usage-discounts)"
-    description: "Provides discounts on the metered value."
+    description: "Pricing applies only after the discounted usage value is reached. You can use this to define overage prices."
   - discount: Minimum spend
     description: "Guarantees a customer pays a specified amount, even if their usage is less. For example, if the minimum spend is set to $10, customers will pay $10 even if they only use $2 worth of the API or LLM token. The minimum spend line only appears on the invoice that includes the end of the line’s billing period."
   - discount: Maximum spend
     description: "Sets the maximum amount a customer will pay for a feature. For example, if maximum spend is set to $10, customers will only pay $10, even if they have a $100 worth of usage."
 {% endtable %}
-
-### Usage discounts
-Usage discounts apply **only to usage-based line items** (not flat-fee prices).
-
-The discount can be consumed across multiple invoices.  
-The discount is applied until the total available discount amount is fully depleted.
-
-For example: 
-
-A line has a 500-unit usage discount, and usage is billed in three parts:
-
-* 300 units  
-* 250 units  
-* 100 units  
-
-The discount is applied progressively:
-
-1. Invoice 1 
-   * Usage: 300  
-   * Discount applied: 300  
-   * Billed quantity: **0**  
-   * Remaining discount: **200**
-
-1. Invoice 2 
-   * Usage: 250  
-   * Discount applied: 200  
-   * Billed quantity: **50**  
-   * Remaining discount: **0**
-
-1. Invoice 3  
-   * Usage: 100  
-   * Discount applied: 0  
-   * Billed quantity: **100**
-
-

app/_includes/konnect/metering-and-billing/tax.md

@@ -1,4 +1,4 @@
-{{site.metering_and_billing}} automatically uses external services to calculate and add taxes to invoices. Currently, {{site.metering_and_billing}} supports [Stripe Tax](https://stripe.com/tax).
+{{site.metering_and_billing}} doesn't calculate taxes itself. Instead, it configures external services to do so with Product Catalog. Currently, {{site.metering_and_billing}} supports [Stripe Tax](https://stripe.com/tax).
 
 {{site.metering_and_billing}} supports the following tax settings:
 

app/konnect-platform/teams-and-roles.md

@@ -201,7 +201,7 @@ columns:
     key: description
 rows:
   - role: "`Ingest`"
-    description: "Ingests events only (intended for the {{site.konnect_short_name}} access token level only)."
+    description: "Ingests events only (intended only for machines)."
   - role: "`Admin`"
     description: "Can read and write every resource. Includes billing apps, billing profiles, and notifications."
   - role: "`Viewer`"

app/metering-and-billing/billing-invoicing-subscriptions.md

@@ -129,9 +129,9 @@ rows:
 {% endtable %}
 <!--vale on-->
 
-### Gathered invoices
+### Gathering invoices
 
-To enable threshold billing scenarios, {{site.metering_and_billing}} creates gathered invoices with upcoming charges for the next billing cycle. These invoices show current pending charges for the user's current billing period in real-time when fetched or viewed, providing visibility into accruing usage before the final invoice is issued.
+{{site.metering_and_billing}} gathers invoices with upcoming charges for the active running billing cycle. These invoices show current pending charges for the user's current billing period in real-time when fetched or viewed, providing visibility into accruing usage before the final invoice is issued.
 
 Gathering invoices are automatically deleted when the last item for a subscription has been billed for.
 

app/metering-and-billing/discounts.md

@@ -51,7 +51,6 @@ Each generic meter is comprised from the following attributes:
 * Value type: The JSON path to the property that contains the value to be metered. This is optional when the aggregation is `COUNT`.
 * Aggregation type: The [aggregation type](#aggregation-types) to use for the meter.
 * Group by: (Optional) A map of JSON paths to group the metered data by.
-* Window size: The size of the time window to use for the meter. This is optional and defaults to `MINUTE`.
 
 ## Aggregation types
 
@@ -66,12 +65,12 @@ columns:
   - title: Description
     key: description
 rows:
-  - aggregation_type: SUM
-    description: "The `SUM` aggregation type calculates the total sum of the metered values for a specific time window. This is useful for accumulating metrics like total API calls made, total data transferred, LLM tokens used or total time spent on a service."
   - aggregation_type: COUNT
-    description: "The `COUNT` aggregation type counts the number of events that occur within a specific time window. This is often used for metrics that are inherently countable, such as the number of transactions processed. The COUNT aggregation type does not require a valueProperty to be defined."
+    description: "The `COUNT` aggregation type counts the number of events that occur within a specific time window. This is often used for metrics that are inherently countable, such as the number of transactions processed or API calls made. The `COUNT` aggregation type doesn't have the `valueProperty`."
+  - aggregation_type: SUM
+    description: "The `SUM` aggregation type calculates the total sum of the metered values for a specific time window. `SUM` aggregates over the events `valueProperty`. This is useful for accumulating metrics like total LLM tokens used, total data transferred, or total time spent on a service."
   - aggregation_type: UNIQUE COUNT
-    description: "The `UNIQUE_COUNT` aggregation type counts the number of unique events. This is useful when events are unique by a specific field. The valueProperty defines the field that makes the ingested event unique. The property's value in the ingested event must be a string or number."
+    description: "The `UNIQUE_COUNT` aggregation type counts the number of unique events. This is useful when events are unique by a specific field. The `valueProperty` defines the field that makes the ingested event unique. The property's value in the ingested event must be a string or number."
   - aggregation_type: LATEST
     description: "The `LATEST` aggregation type returns the latest value for a specific time window. This is useful for when you track the size of a resource on your own and report periodically the value of it to {{site.metering_and_billing}}. For example disk size, number of resources or seats. The latest aggregation takes the last value reported for the period."
   - aggregation_type: MIN

app/metering-and-billing/metering.md

@@ -23,7 +23,7 @@ related_resources:
 {{site.konnect_short_name}} {{site.metering_and_billing}}'s Product Catalog lets you centrally define the different plans and plan features that make up your offering—so you can manage pricing, entitlements, and packaging in one place. 
 
 Each Product Catalog plan consists of:
-* [Features](#features) that are associated with a meter
+* [Features](#features) that you want to price or govern. Can be metered or static.
 * [Rate cards](#rate-cards) that determine which features ([entitlements](#entitlements)) and how much of the feature a subscriber can access ([pricing models](#pricing-models))
 * Optional [add-ons](#add-ons) that allow customers to purchase additional usage or features on demand
 
@@ -65,7 +65,7 @@ flowchart TB
 
 Features are part of your product offering and the building blocks of your plans and entitlements. They are the resource you want to govern and invoice for. For example, LLM Models, tokens, storage units. Features are associated with a meter, so that you can connect usage to a feature that you can then charge for.
 
-Features are the building blocks of your product offering, they represent the various capabilities of your system. Practically speaking, they typically translate to line items on your pricing page.
+Features are the building blocks of your product offering, they represent the various capabilities of your system. Practically speaking, they typically translate to line items on your pricing page and show up on the invoice.
 
 The feature set between plans can vary in terms of what features are available, what configurations are available for a given feature, and what usage limits are enforced.