Guides
Review plans, usage, and billing before go-live
Launch with a clear view of plan language, invoices, and usage limits—not with surprise account questions on week one.
Store teams stall when billing is unclear. The person who owns the WardrobeIt account should read the live billing documentation before the widget faces shoppers. This is not because pricing is the most interesting part of a fashion launch. It is because week-one surprises about invoices, seats, or usage stop merchandising work that should already be live.
This guide tells you what to review and where the source of truth lives. It does not copy plan prices into the article. Prices and plan language change; Help Center and Pricing are the pages that must stay current.
Who needs to read what
- Finance: invoices, billing contact, and how usage is described on the published pages.
- Ecommerce lead: what is included in the current plan language versus what is documented as planned.
- Operator: what happens if a limit is reached, and where to get help.
- Founder or GM: that unpublished package math from a conversation is not an internal price list.
If those four people are the same person in a small brand, still read both pages. Confusion usually comes from mixing a remembered number with a live page.
Use the published sources only
Verified plan language lives on Plans, Usage and Billing and Pricing. If a contractor quotes a number from a pitch deck, ignore it until it matches those pages. Do not put remembered prices into a launch email to your team. Do not paste a screenshot of an old proposal into a Notion wiki and treat it as current.
What “usage” means in operator language
Usage language on the public pages is the only usage language you should brief internally. Do not invent a consumption metric because a dashboard in another tool uses a similar word. If you need to explain WardrobeIt to finance, send the billing help URL, not a paraphrase that quietly adds seats, SKU caps, or conversation packs the page does not list.
If something is labeled planned or post-V1 on product pages, do not brief it as included. Label shipped versus planned honestly. This article will not add a roadmap.
Access is part of billing readiness
Go-live fails in boring ways: nobody can sign in to the merchant portal, the billing email is a departed contractor, or the person who connected Shopify has left and nobody else has admin context. Confirm the account owner, the billing contact, and who can complete Merchant Portal tasks after launch.
- Confirm the account owner and billing email.
- Read the billing help page end to end.
- Confirm you can sign in to the merchant portal.
- Know where Troubleshooting and Contact live if access fails.
- Confirm finance knows not to copy prices from this article—because this article contains none.
Before you publish the widget
Treat billing review as a launch checklist item beside catalog and embed. A storefront widget that shoppers can use while finance cannot explain the invoice is an operations incident waiting for the first calendar month. Complete the catalog and widget work from Getting Started, but do not skip this review because it feels non-creative.
A short internal brief you can actually send
“Plan language is on /pricing/ and /help/billing-usage/. We will not quote numbers in Slack. Owner is [name]. If access fails, we use Troubleshooting and Contact. We will not describe unpublished packages as our plan.” That brief is more useful than a reconstructed price table.
Failure modes
- A freelancer enabled a trial-like path the live pages do not describe, and the team assumed it was the plan.
- Someone copied a competitor’s public pricing page into an internal doc and labeled it WardrobeIt.
- The widget went live on a theme while the billing owner was still “to be confirmed.”
- A board update included a cost assumption that did not match Pricing.
After go-live
When invoices or usage questions appear, return to the same two URLs. Do not let a month of informal Slack answers become the new source of truth. If the live pages and your invoice appear to disagree, use Contact rather than inventing a reconciliation rule in merchandising.
Go-live is an operations event, not only a theme event. When billing and access are boringly clear, merchandising can spend its attention on catalog truth and knowledge instead of tickets. Do not mix WardrobeIt plan language with product offer rules on Margin-Aware Offers—those documents answer different questions.
Related: Book a Demo if you still need a product conversation, Resources for the rest of the operator library, and Product Updates for capability notes that are not billing documents.
A thirty-minute finance and operator huddle
Open Pricing and Plans, Usage and Billing together. Confirm account owner, billing email, and portal login. Confirm nobody will paste deck numbers into Slack. Confirm planned versus shipped labels on product pages are not treated as included. This huddle is the guide.
If login fails, stop widget go-live until access is boring. Troubleshooting, Contact, Merchant Portal.
Do not mix these documents
- WardrobeIt plan language versus product offer rules.
- Usage analytics versus invoices.
- Unpublished packages versus Pricing.
- Competitor price pages versus this product.
Offer capability, if used, is Margin-Aware Offers—still not a price list. Launch sequence: Getting Started.
Widget go-live depends on this review
If the billing owner is unconfirmed, do not publish the launcher. Invoice surprise will pause merchandising work that should already be live. Read Plans, Usage and Billing and Pricing in the same sitting as theme QA.
Still do not copy prices into this article, a Slack huddle, or a board appendix. Send the URLs. Access failures: Contact.
