The contract is signed, the invoice is paid, and the system is live. On the floor, a supervisor is copying orders into a spreadsheet because the new picking rules don't handle part of the business. Those orders ship. The workaround keeps the problem out of the vendor's reports.
This is one way an implementation can look finished before the customer has received what they bought. Customer success is the work of finding and resolving that gap, then checking whether the product continues to be worth paying for. In subscription software, the customer gets to reconsider the purchase at each renewal.
Warehouse management software, usually shortened to WMS, makes the gap unusually tangible. It directs receiving, storage, picking, packing, and shipping. A mistake in the setup can send a worker to an empty bin or leave a packed order waiting for a label. The warehouse post explains how those processes work. Here, the question is how a software company helps a customer run them reliably and gets paid again.
What did the customer buy?
"Implement the WMS" describes a project. It leaves out the reason someone funded it. The warehouse may need to ship before the carrier cutoff without overtime, stop overselling inventory, or open another site without hiring someone to reconcile spreadsheets all day.
That reason changes the implementation. If the customer needs fewer missed cutoffs, a successful picking demo tells you little until you know where orders actually wait. They might be sitting at packing because labels arrive late. They might be waiting for replenishment because the pick locations keep running empty. Configuring faster picking won't fix either delay by itself.
Before kickoff, write down the operating problem, the result the customer expects, and how both sides will know whether it improved. Also record what was promised during the sale. A required integration, an unsupported workflow, or a promised feature date becomes the implementation team's problem whether it appears in the handoff or not.
The outcome needs to survive changes in personnel and scope. When a new module or another building is added, check it again. A customer who bought inventory accuracy at one site may now need consistent stock records across several. The old success plan won't answer the new question.
How much revenue actually stayed?
To measure retention, take the customers you had at the start of a period and follow only them. Leave new sales out. Annual recurring revenue, or ARR, is the annualized value of their recurring subscriptions, excluding one-time implementation fees in the example below.
Suppose that group starts with $1 million in ARR. Cancellations remove $80,000 and downgrades remove another $40,000. That leaves $880,000, so gross revenue retention (GRR) is 88 percent. The remaining customers buy $100,000 of additional subscriptions. Net revenue retention (NRR), which includes that expansion, is 98 percent.
Now raise expansion to $240,000 in the calculator. Net retention reaches 112 percent. Gross retention stays at 88 percent. The existing customers are spending more in total while the original subscriptions have still lost $120,000.
GRR = (start - churn - contraction) / start × 100%NRR = (start - churn - contraction + expansion) / start × 100%Count customers as well as dollars. Losing a small account and losing your largest account each count as one cancellation. Their revenue effects are very different. Conversely, a large expansion can make the revenue result look good while many smaller customers leave.
Retention losses also accumulate. In a simplified calculation with no expansion, 90 percent annual retention leaves about 59 percent of the original recurring dollars after five years; 95 percent leaves about 77 percent. Those figures are 0.905 and 0.955, rounded. They describe the original revenue base, not the size or valuation of the whole company.
For context, SaaS Capital's 2026 survey reports median GRR of 91 percent and NRR of 103 percent for bootstrapped private B2B software companies with $3 million to $20 million in ARR. The full survey covers more than 1,000 companies; those medians come from that narrower group. They aren't warehouse-software targets.
Definitions matter when comparing companies. In a 2025 response to SEC staff, Commvault explained that its ARR and SaaS NRR measures lack standardized definitions and may not be comparable to similarly named measures elsewhere. Write down your own treatment of price increases, currency changes, pauses, and reactivations. Keep it consistent from one report to the next.
Keep the before picture
You can't demonstrate a labor saving if nobody recorded the labor before the change. Once the new process becomes routine, the old one is hard to reconstruct. Capture a baseline while it is still observable, using a measure the customer trusts.
Consider an illustrative warehouse shipping 600 orders a day. Its picking process uses five paid labor minutes per shipped order, and the project aims to reduce that to four. At the same volume and order mix, the difference is ten labor hours a day: 600 orders multiplied by one minute, divided by 60.
| Measure | Before | Target | Current |
|---|---|---|---|
| Paid picking minutes per shipped order | 5 | 4 | 4.5 |
| Orders missing the carrier cutoff | 5% | 2% | 3% |
| Daily orders, for the calculation | 600 | 600 | 600 |
At the current result, the measured improvement is five hours a day. That is capacity the operation may be able to use. It becomes a cash saving only if paid hours or another expense actually fall. If the same people work the same shifts and ship the same volume, payroll hasn't changed.
Check what else changed. Easier orders, different staffing, or a quieter week can improve the rate without the software causing it. Agree on the source and measurement period with the operations lead, and use finance's labor cost if converting hours into dollars. Keep picking errors and missed cutoffs visible so a faster process doesn't get credit for work that later needs fixing.
A useful customer review can be this simple: here's the original problem, here's the comparable result, and here's what still needs attention. In this example, the labor target remains unmet and some orders still miss the cutoff. That's enough to have a specific conversation about where they wait.
Find what is holding up the launch
A warehouse implementation depends on customer work as well as vendor work. Someone has to confirm item records, units of measure, bin locations, starting inventory, and the rules for handling orders. Connected business systems must agree about what the records mean. Training can happen while an integration is being built; a valid inventory test has to wait for usable inventory data.
The important delay may be waiting for a decision. In a sample project, correcting an item file takes one day but the file sits unassigned for two weeks. Buying a better import tool saves little. Getting a customer owner and a deadline for that file changes the schedule.
Record active work and waiting separately. For each blocked task, name the missing input, who can provide it, and what it prevents. "Data incomplete" is hard to act on. "The customer item owner must confirm case-to-each conversions before allocation testing" tells everyone what is needed.
Speed still needs exit conditions. Run real workflows through the connected systems, including the exceptions the warehouse sees in ordinary work. Test labels on the devices people will use. Reconcile inventory. Check permissions and expected volume. Microsoft's go-live guidance requires signoff on integration, user acceptance, and performance testing, along with migration, cutover, and training preparation. The exact tests depend on the product and operation.
The customer's calendar can set a harder limit than the project plan. Ask which weeks are available for cutover and when the operation freezes changes for peak season. If preparation slips past the agreed window, show the new date and its consequences. Keeping the original date on the slide doesn't recover the lost time.
What counts as first value?
Time to value is the elapsed time from a defined starting event to a result the customer can verify. For warehouse software, several results are worth recording. They answer different questions.
| Milestone | Evidence | What remains unproven |
|---|---|---|
| The connection works | A valid order arrives from the customer's order system. | Whether the floor can fulfill it. |
| The first real order ships | The agreed production workflow completes, including the shipment record. | Whether it works at normal volume. |
| The operation is stable | Users run normal work and handle agreed exceptions without constant project-team help. | Whether the business result improved. |
| The bought result appears | The agreed measure improves against a comparable baseline. | How much of the improvement the software caused. |
Choose the first useful milestone with the customer and keep measuring the later ones. A first shipment is a reasonable early result for an outbound implementation. It doesn't prove inventory accuracy or a labor saving. An inbound-only first phase needs its own milestone.
Use the same starting event across a cohort, the group of customers whose implementations you're comparing. If the clock starts at kickoff, report the wait between signing and kickoff separately. Otherwise a backlog can make the customer wait longer while the onboarding metric appears to improve.
Include unfinished projects. Suppose six of ten customers reach first shipment quickly and four are still blocked. Reporting only the six completed times makes the process look faster than it is. Show completion counts and the age of the waiting projects beside the completed times.
After go-live, keep an implementation owner until the agreed operation is stable. Record open issues, temporary workarounds, and who will handle them after the project team leaves. A peak week provides another useful test later; the customer shouldn't need to wait for it to receive ordinary support.
Watch the work, not the logins
A warehouse employee may log in every day because the job requires it, while a supervisor spends the afternoon repairing what the system gets wrong. Usage alone won't distinguish that account from one running smoothly.
A short pick is a useful example. The system directs a worker to a location for more stock than the worker finds there. In Dynamics 365, that event can create a work exception. A single short pick is something to resolve. Repeated exceptions at the same location are a reason to investigate inventory records, replenishment, or how work is being performed. The event identifies where to look; it doesn't establish the cause.
| Signal | Check next |
|---|---|
| A workflow moves into a spreadsheet | Which cases the product can't handle, and how many orders bypass it. |
| Picking exceptions repeat | The locations, items, shifts, and reasons involved. |
| Support tickets disappear | Whether problems stopped or users stopped reporting them. |
| The person who led the purchase leaves | Who now approves the spend and whether they understand the result. |
A health score summarizes your judgment about the account. Keep the evidence and the action visible beside it. An account with a shipment-blocking defect needs a responsible technical owner and a restoration plan. An account whose new buyer is reviewing all software needs a conversation about the purchase. Calling both "red" doesn't make them the same problem.
Check whether the score was useful later. Did it flag the customers who left or reduced their subscriptions while there was still time to act? Did it repeatedly flag customers who were simply asking for help during a rollout? Revise the signals when they mislead you. A more elaborate score can still be a poor forecast.
Give the next task to someone
Customer success managers spend too much time chasing other teams when responsibility is vague. If shipping labels stop printing, support needs to establish the impact and coordinate restoration. Engineering owns a defect fix. The customer needs to know who is handling the incident and when the next update will arrive.
The customer success manager checks the wider effect: how much work was delayed, whether the workaround is safe to continue, and whether a repeated incident has changed the customer's willingness to renew. They also make sure the customer gets an answer. Forwarding a ticket and waiting isn't enough, but asking them to personally fix every technical problem won't work either.
Sales should hand over the buying reason and specific commitments. The implementation team should leave a record of the production setup, accepted scope, and unresolved issues. Support should keep the incident history. Whoever owns renewal needs the contract dates and the customer evidence. These records can be short. Their value is in sparing the customer another explanation of the same problem.
Customer work needs owners too. The vendor can't clean inventory that only the customer can verify or make the customer's supervisors enforce a new process. Make those dependencies explicit when agreeing on scope and dates.
Size the service to the operation
Small and midsize businesses are often grouped as SMB; "mid-market" usually describes larger customers below the enterprise tier. Those labels don't tell you how much implementation work a warehouse requires. A small third-party logistics provider may handle many clients with different rules. A larger distributor may have one straightforward building.
Look at sites, process variants, connected systems, customer project time, and the consequences of failure. A standard setup with one site may work well with reusable templates and a shared specialist. Several sites tied to finance and order systems may need a project manager, technical owners, formal testing, and a staged cutover. Use the work required to choose the approach.
Then check the cost. A low-priced subscription that needs continuing custom services can be a poor sale even if the customer stays. Track implementation effort, support effort, and exceptions to the standard offer alongside revenue. Decide whether a complex requirement belongs in a paid service, a later phase, the product roadmap, or outside the offer.
Keep expert help available when the standard path fails. A small customer can need close attention during cutover, and a stable larger customer can need little routine contact. Scheduling more meetings is useful only when there is something the people in them can resolve.
A renewal needs more than a reminder
The person approving the renewal may never use the product. They need an account of what it does for the business, what it costs, and what is still wrong. Keep that account current through the term, especially when the original buyer leaves.
Work backward from the customer's decision process. Record the renewal date, notice deadline, budget timing, approver, and any purchasing or legal review. Check the intended scope before producing an order. A customer can be ready to renew while the purchase order is delayed; another can be processing paperwork while considering a replacement. Forecast the decision and the administrative steps separately.
Be careful about interpreting the signature. Replacing a WMS requires another implementation and a change to live warehouse work. A customer may renew to avoid that disruption while remaining dissatisfied. High retention can coexist with persistent workarounds and a buyer investigating alternatives.
Expansion needs the same scrutiny. Another site or module can be useful before every issue is resolved, but the old issues need an explicit plan. Adding scope to an unstable implementation can increase both the subscription and the amount of work required to keep it running.
When an account leaves, trace what happened using project records, incidents, usage, and customer conversations. Identify the earliest evidence the company could reasonably have acted on. An acquisition that mandates another system calls for a different response from a failed rollout. "Budget" on a cancellation form won't explain whether the product ever delivered the result.
What to review together
Keep revenue results beside the customer work that might explain them. Review gross and net retention by the groups you actually serve. Look at unfinished implementations, time to the agreed milestones, recurring incidents, and whether customers have a verified business result. A company average can conceal a service model that works for one group and fails another.
The review should reach a decision. An overdue data file needs someone to obtain it. A recurring picking defect needs a product decision. An account whose buyer has changed needs a new conversation. Record who will do the work and when you'll check it again. Urgent operational issues need attention as they happen, without waiting for that review.
For the illustrative picking customer, the next review starts with the half-minute still separating the current process from the target, and the orders still missing the carrier cutoff. The subscription renewal is a separate fact. Until those delays are understood and the customer agrees on the measured result, you can't claim the purchase has delivered what it was meant to.