Moveworks pricing: what the public numbers show, and what they leave out

The short version

• Moveworks' own AWS Marketplace listing prices the product per user per year, on a 12-month contract.
• Moveworks' AWS Marketplace listing has a single pricing band, 1,000 to 2,500 users, and gives no rate outside it.
• Vendr shows a range of $89,500 to $271,333 across 31 Moveworks purchases, without saying which years they cover.
• The top of Vendr's Moveworks range is roughly three times the bottom, so the midpoint is not a budget.
• The Moveworks licence is not the whole cost: integration, content cleanup and an owner after launch sit on your side.

How much does Moveworks cost?

There is no single public price, but there are two public reference points. Moveworks' own listing on AWS Marketplace prices the product per user per year, on a 12-month contract. Separately, Vendr shows a low-to-high range of $89,500 to $271,333, based on data from 31 Moveworks purchases made through its procurement platform.

Neither is a quote. The marketplace listing covers a single band of 1,000 to 2,500 users. The Vendr range does not say which years its purchases come from. Together they are enough to tell you whether you are in the right conversation, and not enough to set a budget line.

The rest of this guide covers what each source says, what it leaves out, which costs sit outside the licence, and when the product is not worth buying at all.

What does the Moveworks AWS Marketplace listing tell you?

It tells you how Moveworks sells through that channel: a vendor-set 'price per user per year', on a 12-month contract, in a band of 1,000 to 2,500 users. That is the only row in the pricing table. There is no smaller band and no larger one.

Two things follow. First, the pricing unit is the user, so headcount is the main multiplier on whatever rate you are offered. Second, the listing is built for deployments of at least 1,000 users. It does not say whether Moveworks sells below that, or what the rate becomes above 2,500. Volume pricing is common in per-user software, but this listing shows no figure for it, so do not invent one by extrapolating.

This guide does not repeat the per-user figure itself. Vendor-set marketplace prices change, and a number copied into an article outlives the listing it came from. Read it at source on the day you need it, and write the date next to it.

It also helps to know what a public marketplace price is for. AWS Marketplace supports private offers, where a seller sets terms for one buyer, so the list price is a starting position rather than the price every buyer pays. If your organisation has a committed spend agreement with AWS, ask your AWS account team whether a marketplace purchase would count towards it. That changes which budget pays, which can matter as much as the rate.

What does Vendr's data say Moveworks costs?

Vendr shows a low-to-high range of $89,500 to $271,333, based on data from 31 Moveworks purchases made through its procurement platform. The page was last updated in February 2026. Vendr does not say which years those purchases cover.

That last point matters more than it looks. A range built from purchases across several years can mix contracts signed under different list prices and different product scope. From the range alone, you cannot tell whether the low end is an old deal, a small deal or a well-negotiated one.

The spread is also wide: the top of the range is roughly three times the bottom. Something differs a lot between those purchases, whether seat count, term, scope or how hard the buyer pushed, and the range does not tell you which. So do not take the midpoint and call it a budget. Use the range to check you are in the right order of magnitude, then get a quote against your own numbers.

Thirty-one purchases is a small sample. It is real data, and much better than a guess, but it describes the buyers who happened to use Vendr, not every Moveworks customer.

Public Moveworks pricing reference points

What drives the price of Moveworks up or down?

Headcount first, because the AWS listing prices per user. After that, the levers are the ones that move most enterprise software contracts: how long you commit for, how much of the product you take, which channel you buy through, and how prepared you are when you negotiate.

The definition of a user deserves its own question. 'Every employee' and 'every employee who used the assistant this month' can be very different numbers in an organisation with a large frontline or seasonal workforce. Find out which one the contract counts, and what happens if headcount moves during the term.

Term length comes next. The AWS listing shows a 12-month contract. Longer commitments are a common trade for a lower rate, but they move the risk to you: if adoption is poor in year one, you are still paying in year three. A one-year term may cost more per user, and it buys you the option to leave.

Scope is the lever buyers forget they control. If you only need the assistant for one department in the first year, say so and price that. Expanding from a deployment that works is a stronger negotiating position than paying up front for teams that are not ready.

What costs sit outside the Moveworks licence?

Mostly your own people's time. An employee assistant is only as good as the systems it connects to and the knowledge it reads, and both of those are yours to prepare and maintain. The licence pays for the product. It does not make your knowledge base accurate.

Integration is the visible part. The assistant needs access to your identity provider, your ticketing system and wherever your policies and how-to articles live. Each connection needs someone who owns that system, can grant access safely, and can say what the assistant should and should not be allowed to do.

Content is the invisible part, and often the larger one. If your intranet holds three versions of the expenses policy, an assistant will find all three and answer confidently from one of them. Most organisations discover how stale their internal documentation is the week they point an assistant at it. Budget time to fix that before launch, not after the first wrong answer goes round the office.

Then there is ownership after launch. Somebody needs to read the questions the assistant failed on, fix the content behind them, and decide when a new workflow is worth adding. That is a part-time role at the very least, and it is easy to leave out of the business case.

Permissions belong on this list too. An assistant that can read HR documents must respect who is allowed to read them. Ask any vendor, Moveworks included, how access rights are enforced when content is retrieved, and how quickly a permission change in the source system takes effect.

How do you get a useful Moveworks quote?

Arrive at the first call with your own numbers, so the vendor prices your situation rather than a generic one. These are the questions worth settling before you compare any quote with the public reference points.

1. Count users the way the contract will: total employees, employees with access, and expected active users, as three separate numbers.
2. List the systems the assistant must connect to on day one, and the ones that can wait.
3. Decide which department goes first, and ask for a price for that scope alone.
4. Ask for 12-month and multi-year pricing side by side, so you can see what the longer commitment is actually worth.
5. If your headcount falls outside the 1,000 to 2,500 band on the AWS listing, ask what the per-user rate is at your size.
6. Ask whether buying through AWS Marketplace or directly changes the price or the terms.
7. Ask about renewal: whether increases are capped, and what happens if your headcount falls.
8. Ask what your team must provide during rollout, in roles and hours, so the internal cost is visible before you sign.

When is Moveworks not worth paying for?

When your problem is smaller than the product. The only band on the AWS listing starts at 1,000 users. If you have 200 staff and a support inbox one person can handle, a per-user enterprise assistant is the wrong shape, whatever the discount.

It is also not worth it yet if your knowledge is a mess and nobody owns it. No assistant, bought or built, gives good answers from bad documentation. Fix the content and name owners first. You will need to do that whichever way you go, and it makes every later option easier to evaluate.

It may not be worth it if your need is narrow: one workflow, one system, one team. A focused tool for that workflow can be cheaper to run and easier to change than a platform licensed across the whole organisation.

The reverse also holds. A large organisation with a high volume of routine internal requests, standard systems and no appetite for running software is often better off buying a mature product. Building your own to avoid a licence fee is a false economy if you then have to staff it.

Should you buy Moveworks or build your own assistant?

Buy if your needs match what the product already does and you would rather pay a licence than employ people to run software. Build if your knowledge, permissions or workflows are specific enough that you would spend the contract working around a general product, or if you need control over where data lives and which models handle it.

Be honest about what building costs. A custom assistant is not free once it ships. It needs hosting, model usage, evaluation, and someone to maintain the connectors when the systems on the other end change. The real comparison is licence plus internal time, against build cost plus running cost plus internal time. Internal time appears on both sides, which is exactly why it gets forgotten.

We build custom knowledge assistants, so we have an interest in this question, and you should weigh our view accordingly. That view is simple: before pricing any assistant, find out whether your documentation can support one. That answer is cheap to get, and it changes which option makes sense.