Prior to the introduction of Billing Accounts and migration to a new billing system ( https://feedback.equinixmetal.com/changelog/new-kill-bill-billing-engine-live ), users had the option to pay their Project level invoices manually instead of being enrolled in auto-charge by default. Metal should re-introduce an option for manual payments, giving users the ability to review and pay their invoices themselves via the Customer Console.

Large companies, with established procurement processes, require a structure to manage POs and match them to invoices. Equinix Metal should support customers creating and updating a list of Purchase Orders and some basic rules to assign them to invoices (e.g. by Project) or support manually matching and update an invoice with a PO entry. A good example of this can be found at AWS here: https://aws.amazon.com/aws-cost-management/aws-purchase-order-management/

We currently do not display the renewal or cancellation dates for respective hardware reservations in the Console consistently. Customers would love to be able to see this data to keep track of when their Reservations are slated to renew or be cancelled.

Currently, instance types must be defined as "on-demand" or "reservation" at build time and built through different workflows. If you try to build a reserved instance and no reservations are available, the build just fails. Would like to see a single workflow where if a server reservation is available, the instance deploys to that reservation. Perhaps something like a tag in the on-demand workflow such as "use_avail_reservation: true"? Where false (default) will act as it currently does and true will check for available reservations before building an on-demand instance and false will just build the on-demand instance without checking for reservations? and/or possibly the reverse scenario for the reservation workflow with a tag like "ondemand_allowed: true" Where again false (default) will act as it currently does and when true, instead of failing when no reservations are available, the workflow will auto-switch over to use an ondemand instance type. Though this 2nd option is understandably "riskier" from a business perspective as a customer might think they're building a reserved instance and get an on-demand one at a higher bill rate instead.

Currently, the feedback experience located at https://feedback.equinixmetal.com includes ideas for all digital products, but the domain leads you to believe otherwise. Update the domain to be inclusive of all digital products more clearly.

As a customer, I want the ability to identify and manage which beta / early access programs I or my org is participating in directly from the portal

Enable customer to have a single global billing account with a single currency (in USD) to buy all Network Edge services such as Virtual Devices, DLG and VCs

Users are currently only able to contract through the US-based Equinix Services Inc. when creating their Billing Account. There are use cases where companies want (or need) to contract through a non-US based entity. In an effort to expand supporting global use cases for all industries, we should operationalize non-US based contracting entities for customers in the EMEA and APAC regions. Customers should be able to choose these entities (or have it chosen for them, based on their billing address) during Billing Account creation.

With the introduction of Billing Accounts, user invoices were consolidated as detailed here: https://metal.canny.io/admin/feedback/usability/p/support-consolidated-billing Though a single, consolidated invoice benefits the large majority of Metal customers, adding flexibility for customers interested in separating out their invoice based on Project is very nice for a variety of use cases. We should support the ability to generate multiple invoices with Project as the common denominator.

Instead of considering a device successfully provisioned according to the Metal API, await a custom user-state, e.g. user-data-successful, before continuing with the rest of a TF script. Captured here as well: https://github.com/equinix/terraform-provider-equinix/issues/214