By [Author Name] · [Date] · [X] min read · [Table of Contents]
TL;DR
- Equipment as a service means paying a recurring fee for devices and the work around them, instead of buying hardware and running the work yourself.
- If your approvals, budget and offboarding already work and you have one office, you don't need this and switching will create work.
- Four internal things have to change: how spend is approved, how budgets are built, what offboarding triggers, and who owns the record.
- Three operating models exist: fully outsourced, a hybrid with internal ownership of the record, and a service used only for the awkward markets.
- Choose on which internal process is currently failing, not on which vendor demos best.
- Done right, the equipment part of a joiner or a leaver stops appearing on anybody's to-do list.
The vendor is signed. The implementation call went well. Six weeks later the first leaver goes through the new process and nothing happens, because offboarding still sends an email to an internal address that used to be a person's inbox, and nobody rewired it. The laptop stays with the former employee for five weeks. Everyone assumed the vendor's process had replaced the internal one. It hadn't, and nobody had switched the internal one off.
That's the characteristic failure of this category. It has nothing to do with the vendor. Buying equipment as a service changes who performs the work. It doesn't, on its own, change the thirty small internal assumptions built up over years of owning things: that a purchase needs a requisition, that a budget line is capital, that a leaver's manager chases the laptop, that the spreadsheet is the record.
Best tools for Device Management
So the real issue isn't vendor selection. It's that your internal processes were designed around ownership, and a service model breaks several of them in ways that only appear on the first real transaction. The vendor comparison is the easy half and it gets most of the attention. This article is about the other half.
When You Don't Actually Need Equipment as a Service
When owning and running it works. One or two offices, everyone reachable, a cupboard with spares and somebody who knows where things are, and your processes match your model, so there's nothing here to fix. Introducing a service here means rewiring approvals and offboarding to gain nothing you were missing.
When the friction starts showing. The tell is not cost. It's that equipment work keeps landing on people whose actual job is something else entirely, and none of them has been told it is now part of their role. A hiring manager arranging a courier. A finance analyst chasing a laptop. An office manager storing machines for a team two time zones away. None of it appears in a budget, and all of it is real work that somebody isn't being measured on.
When it becomes a liability. Two triggers. Equipment work becomes a dependency for hiring, so a start date slips because nobody could get a machine to a city. Or a leaver's device is unaccounted for and the question reaches somebody senior. At that point the informal arrangement has become a business risk rather than an annoyance.
The edge case that breaks everything. Simultaneous volume. Twenty-three joiners and eight leavers in the same fortnight, across six countries, which is the shape of a good quarter and the shape of a broken month. An owned and self-run model degrades gracefully right up until it doesn't. The breaking point is almost always concurrency rather than total headcount. I've watched a perfectly adequate process fail in one busy month and never recover, because the backlog it created was never cleared.
What Teams Actually Need from the Operating Model
> "Who does the equipment part of onboarding now?" > A named party for each step, with the internal steps explicitly retired. > Half-migrated processes are worse than either end state, because two parties each believe the other is handling it.
> "What triggers a collection?" > A system event, not a person remembering, and ideally the same event that ends somebody's access. > Retrieval rates depend almost entirely on how early the collection is triggered, and a human trigger fires late or not at all.
> "Which budget line does this come out of?" > An answer agreed with finance before the first invoice, because the shape of the spend has changed. > A recurring service charge landing in a capital hardware line produces a reconciliation problem every month until somebody fixes it.
> "Where is the authoritative record now?" > One system, named, with the others demoted to references in writing. > Two systems that both believe they are the record is the most common cause of a fleet count nobody trusts.
> "What happens to the devices we already own?" > A decision per device cohort, made deliberately rather than left to drift. > Most of your existing fleet should stay exactly where it is, and knowing that in advance prevents a pointless migration.
The Three Operating Models
Fully outsourced. What it is: the vendor handles procurement, delivery, swaps, retrieval and storage, and their platform is the record. Your internal process becomes a set of triggers into theirs. When it's right: no internal IT function, or a small one with better things to do. Also right when you are distributed enough that no internal arrangement could cover your markets. When it fails: on the devices outside their scope. Anything bought before the arrangement, bought locally, or bought by an individual is invisible to the vendor's platform, and if that platform is your only record then those devices have left your fleet on paper while still existing in reality.
Hybrid, with the record held internally. What it is: the vendor does the physical work. You keep an asset register as the authority and feed it from the vendor plus your other sources. When it's right: when you have a mixed fleet with history, or a compliance position that requires you rather than a supplier to hold the inventory. This is the most common steady state in companies above a few hundred people. When it fails: when nobody owns the register. The vendor's data is accurate about what they handled, your register is accurate about what somebody updated, and without an owner the two drift apart quietly over about two quarters.
Service for the awkward markets only. What it is: you continue to run your own equipment process where it works, and use a vendor for the countries where it doesn't. When it's right: a company with a strong home market and a handful of distributed people. It is cheap, it is low-risk, and it fixes the actual pain without touching processes that work. When it fails: when the awkward list grows and nobody notices it has become the majority. At that point you are running two models with one process, which costs more than either model alone.
How to Choose: Five Questions Before You Talk to Any Vendor
Which internal process is currently failing? Name it. Approvals, delivery, retrieval, storage, the record, or budgeting. Vendors sell against delivery because it demos well, and in my experience the process that is actually failing is retrieval or the record. If you buy against the wrong one you will get a smooth onboarding flow and the same unaccounted devices you had before.
What triggers equipment events today, and will that survive? Walk through a real joiner and a real leaver and write down every trigger: who sends what to whom, and what system event starts it. Then check which of those triggers still exists after the change. The ones that don't are your implementation work, and they're the ones nobody budgets for.
Who will hold the record? Decide before you sign. If the answer is the vendor's platform, accept that your record now covers only what they handled and plan for the rest. If the answer is an internal register, name its owner and work out the feed. Leaving this undecided is the single most reliable way to end up with two half-records.
What is finance expecting? Talk to them early, because the spend shape changes and that matters more to them than the amount. A recurring service charge behaves differently in a budget from a capital purchase, the forecasting method changes, and the depreciation picture changes for anything you stop owning. None of that is difficult. All of it is annoying when discovered in month three.
How much of your existing fleet moves? Usually much less than people assume, and the right default is almost none. Machines in people's hands should stay in their hands, with the vendor picking them up when that person eventually leaves. Moving working hardware to put it under a new arrangement is weeks of disruption for no operational gain, and a vendor who suggests otherwise is optimising for their own record rather than for your quarter.
The Four Internal Changes, in Detail
This is the practical core of the article, because this is the work that determines whether the arrangement delivers anything.
Approvals. Under an ownership model, approvals gate a purchase. Under a service model there may be nothing to purchase: the kit follows the role and the cost follows the headcount. So the approval moves upstream, to the hiring decision, which is where it belongs. Practically this means retiring the equipment requisition for standard kit and keeping an approval only for exceptions. Teams that keep the old requisition alongside the new flow get both the overhead and the confusion.
Budgets. Hardware spend was lumpy and is now smooth, which sounds like an improvement and creates one real problem: the forecast method changes. You used to forecast purchases and now you forecast headcount multiplied by a unit. Agree the unit with finance, agree what happens to the existing capital assets, and agree the treatment of anything you still own. Then rebuild the forecast on the new basis rather than translating the old one, because a translated forecast carries assumptions that no longer apply.
Offboarding. This is the change that matters most and gets the least attention. The collection should be triggered by the same event that starts the rest of offboarding, and it should fire before the last working day rather than after it. That single sequencing choice does more for recovery rates than any contract clause. Write it into the offboarding checklist, name the owner, and then test it on one real leaver before you trust it.
The record. Name the authority. Then write down, for each other system that holds device data, what it is still good for and what it is no longer the source of. This takes twenty minutes and prevents about a year of confusion, because the systems you demote will keep producing numbers and somebody will keep quoting them.
| Process | Under ownership | Under a service model | The thing that breaks |
|---|---|---|---|
| Approval | Gates a purchase | Follows the hiring decision | Keeping the old requisition as well |
| Budget | Capital, lumpy | Recurring, per head | A translated forecast, not a rebuilt one |
| Delivery | Internal or ad hoc courier | Vendor, per country | Nobody retires the internal route |
| Repair | Warranty plus your time | Vendor, with a stated turnaround | Assuming a turnaround nobody agreed |
| Offboarding | A person chases the device | A system event triggers collection | The old email trigger left running |
| Storage | A cupboard | A warehouse, sometimes charged | Discovering storage is a separate line |
| The record | A spreadsheet | The vendor platform, or a register | Two authorities, neither trusted |
The First Ninety Days, and What to Test When
Treat the first quarter as a set of tests rather than a rollout, because the things that fail are specific and each one is cheap to find deliberately.
Days one to thirty. Do not migrate anything. Wire the triggers, agree the record authority, and tell finance the unit. Then run exactly one joiner through the new process end to end, in an easy market, and watch every step. One transaction surfaces more than any amount of planning, and the problems it finds are almost always internal rather than vendor-side.
Days thirty to sixty. Run one leaver, deliberately choosing a hard country. This is the real test. Does the collection trigger fire before the last day, does packaging arrive, does the device reach the warehouse, and does the record update without anybody typing anything. If any of those four needs a manual step, decide now whether it's got an owner or whether it needs fixing, because by month six nobody will remember it was supposed to be automatic.
Days sixty to ninety. Reconcile. Take the vendor's list, your own register and your identity provider's user list, and join them on serial number and person. You will find gaps, and finding them now while the arrangement is new is much easier than finding them during a security review next year. Record the gap count, because that number is your baseline and you will want it at the first renewal.
One thing to resist for the whole quarter. Resist the temptation to move devices that are working fine. The pull is strong, because a complete record inside the vendor platform is tidy and the incomplete one is irritating. But collecting and re-shipping a working laptop costs the user two days and gains you a row in a table. Let the fleet convert naturally as people leave and join, and accept a mixed record for two or three years, with the pre-service cohort clearly flagged.
What Does Not Change, and Why That Matters
A fair amount of the disappointment in this category comes from expecting the service model to absorb things it never touches.
Your security obligations do not change. A device managed by a vendor still needs enrolment, configuration and proof of wipe, and the vendor handling the logistics is not the same as the vendor managing the endpoint. These are separate purchases from separate suppliers, and conflating them is how companies end up with well-shipped machines in an unknown configuration state.
Your software spend does not change either. Not one equipment vendor manages software licences. Workwize, Firstbase, GroWrk and allwhere all do hardware logistics and none of them touches seats or subscriptions, and the same is true of RemoAsset. If your recurring IT cost problem is subscriptions rather than hardware, this entire category leaves it untouched.
And the hardware you already own stays yours. A service arrangement does not retrospectively convert your existing fleet into a service, so you still have a disposal question, a depreciation schedule and a residual value for every machine bought before the change. That isn't a problem, it's just a second thing to run for a few years, and plenty of companies forget to plan for it and then rediscover it when the first pre-service cohort reaches end of life.
One more thing that does not change. Discovery. No vendor in this lane does network discovery, so a device nobody recorded stays invisible. RemoAsset publishes $1,499 a year for its Subscription tier, with procurement and retrieval stated across 80+ countries and a 60% reduction on retrieval charges at that tier. Disclosure: RemoAsset is our own product. It does no network discovery, it does no software licence management, and only the Subscription tier publishes a figure because the pay-as-you-go side is quoted. If finding unrecorded hardware is your problem, buy a discovery tool and not this.
Who Owns This Internally, and What That Job Actually Is
Every arrangement in this category needs an internal owner, and the job is smaller and more specific than people assume, and it is not a full-time role. It is about four hours a month, and naming the wrong person is the most common reason the arrangement underdelivers.
The work has four parts, and all four are supervisory rather than transactional, which is the property that makes four hours a month realistic. Watching the exceptions, because the standard flow runs itself and the exceptions are where the value leaks. Holding the record authority, which means being the person who answers when two systems disagree. Running the quarterly sample of 25 rows. And owning the vendor relationship, including the renewal date and the written record of what was promised.
Notice what is not on that list. Processing requests, arranging couriers and chasing leavers are precisely the tasks the arrangement exists to remove, so an owner who finds themselves doing those has a broken implementation rather than a busy month. That distinction is the useful test at the three-month mark: if the owner is doing transactions, something in the trigger map did not get wired.
Who should it be? Somebody in people operations or IT operations who already touches onboarding, rather than somebody in procurement, and that cuts against the instinct. Procurement owns suppliers well and has no visibility of the joiner and leaver flow, which is where the exceptions live. The person who already sees every start date and every resignation will catch a problem in week one that a supplier-focused owner would catch at the quarterly review.
And one structural point that costs nothing. The owner should not be the person who ran the purchase, or at least should not be only that person. Handovers from a buyer to an operator are where ownership evaporates, so name the operator during the evaluation and let them be in the vendor calls. They will ask better questions than you will, because they are the one who has to live with the answers.
The Vendor Questions That Only Matter Once You Think in Processes
Most vendor question lists are about capability. Once you are thinking about the operating model, a different and shorter set of questions becomes the useful one, because these are the answers that determine whether your internal rewiring will work.
"What can trigger an action in your system from outside it?" Ask this one first. It is the single most important question in the list and it rarely gets asked at all. If a collection can be triggered by an event in your HR system, offboarding fixes itself. If it requires somebody to log into a portal, you have inherited a manual step and should design an owner for it. Ask what the integration actually is rather than whether one exists.
"What does your platform do about devices you did not supply?" Every company has a pre-existing fleet and most vendors can hold records for hardware they never touched. The quality of that varies enormously. Find out whether those devices can be collected, whether they appear in reports on the same footing, and whether there is a charge, because the answer determines whether you can run one record or two.
"What is the earliest point you can act on a leaver?" Days before, not days after. You are looking for an answer measured against the last working day, and the direction of that answer is the whole point of asking. A vendor who can only act once a device is confirmed as released is a vendor whose recovery rate will match your old one, and recovery is usually the whole business case.
"What do your reports not cover?" A generous question that produces unusually honest answers. The gaps that matter are typically software, devices outside the arrangement and anything about configuration state, and a vendor who names those gaps readily is easier to plan around than one who implies full coverage.
"Who do we call, per market, and what is their escalation?" Not a support email. A named route per region, with a stated response time and a second line above it. This is the question whose answer you will use most often and the one least likely to appear in a proposal.
The Decision Table: Which Model Fits You
| Situation | Scale / Size | Setup | Primary Pain | Recommended Starting Point |
|---|---|---|---|---|
| One or two offices, everyone reachable | Under 80 people | In-office | None, honestly | Keep owning and running it |
| Strong home market, a few people abroad | 50 to 200 people | Mostly one country | Only the awkward markets hurt | Service for those markets only |
| No internal IT function | 20 to 150 people | Distributed | Nobody owns any of it | Fully outsourced |
| Mixed fleet with years of history | 200 to 1,000 people | Distributed | Record accuracy and compliance | Hybrid, register held internally |
| Retrieval is the failing process | Any | Distributed | Devices never come back | Service, with the trigger rewired first |
| Hiring blocked by equipment delays | 50 to 400 people | Distributed | Start dates slipping | Fully outsourced in the slow markets |
| Software spend is the real cost | Any | Any | Subscriptions, not hardware | Not this category at all |
Most companies above a few hundred people land on the hybrid row, and the reason is almost always compliance rather than preference: somebody needs the inventory to be theirs.
Measuring Whether It Worked
Nobody sets a measure before signing, and then the renewal conversation is a matter of impressions. Four numbers settle it, and all four are available without any vendor reporting.
Time from offer acceptance to device in hand, measured per market, and this is the number hiring managers care about and the one most likely to improve visibly. Capture it for a quarter before you change anything, even roughly, because a baseline collected afterwards is not a baseline.
Recovery rate, as a percentage of leavers whose device came back within thirty days, and this is the number that pays for the arrangement, and it's the one most often not measured at all. Count the last two quarters before the change from whatever records you have, however imperfect.
Internal hours spent on equipment. Count them for two weeks and extrapolate rather than trying to be precise, and the point is the order of magnitude: whether equipment work is consuming two hours a month or two days.
Record accuracy, sampled. A sample of 25 rows, physically confirmed, every quarter. The trend matters more than the absolute figure, and a sample that takes an hour is the only measure in this list that an auditor will ever ask to see.
| Measure | How to get it | Before you change anything | What good looks like |
|---|---|---|---|
| Acceptance to device in hand | Per market, from offer dates | Pull last quarter, roughly | Predictable, not just fast |
| Recovery within 30 days | Leavers whose device returned | Count last two quarters | Rising, and measured at all |
| Internal hours on equipment | Count for two weeks, extrapolate | Do this first, it takes an hour | Falling, and owned by somebody |
| Record accuracy | Sample 25 rows, confirm physically | Establishes the baseline | Stable or improving, with a known rate |
The Conversations to Have Internally, and in What Order
The implementation work is mostly conversations, and the order matters because each one changes the inputs to the next. Four of them, in sequence.
Finance first, before any vendor call. You are proposing to change the shape of a cost, and finance cares about the shape far more than the amount. Bring three things: the current hardware spend by quarter for the last two years, the forecast method you would use afterwards, and a question about what happens to the capital assets you already hold. That last one you cannot answer yourself and should not try, because it depends on reporting standards and on how the existing fleet was recorded.
Then whoever owns offboarding. This is the conversation with the highest return in the whole project. The ask is specific: can the event that removes somebody's access also trigger a device collection, and can it fire some days before the last working day rather than after it. If the answer is yes, the rest of the project will go well. If the answer is that offboarding is an email to a shared inbox, you have found the thing to fix first and it is fixable without buying anything.
Then security, early rather than late. Not for approval, for requirements. Find out whether the inventory has to be held by you rather than by a supplier, whether there are markets where a third party cannot hold devices, and what evidence of wipe they need and in what form. Those three answers change the shortlist, and discovering them after signature is how companies end up running a hybrid model they did not choose.
Then the hiring managers, last and briefly. They do not need the operating model, and they need to know what to tell a candidate about when equipment arrives, and who to contact when it doesn't. Two sentences and a name. Over-communicating the mechanics to this group produces questions about the mechanics, which is not a good use of anybody's week.
One note on sequencing that is easy to get wrong. Do not start with the vendor demos. A demo seen before those four conversations will anchor your requirements on whatever the vendor is strong at, and you will find yourself arguing internally for features rather than for outcomes. The conversations take about a week in total and they make every subsequent vendor call shorter.
Running a Mixed Fleet Without Pretending Otherwise
For two or three years after a change like this, you will have two populations of hardware, and the honest approach is to label them rather than to blend them.
The pre-service cohort is hardware you own. It has a purchase date, a depreciation schedule, a residual value and a disposal question, and it is not covered by the vendor's arrangement unless you deliberately moved it. The post-service cohort is covered, recorded by the vendor and handled on exit by them. Those two populations need different answers to almost every question, and a register that does not distinguish them produces averages that describe neither.
So add one field. A flag on each asset saying which arrangement it belongs to, set at the point the record is created. It costs nothing, it takes a few minutes to backfill if your purchase records are reasonable, and it makes every subsequent report answerable. Without it, the first time somebody asks how many devices are under the service arrangement you will be counting by date and guessing at the boundary.
Two reporting habits that follow from this. Report the two cohorts separately in anything that goes to finance, because the capital and the recurring halves behave differently and blending them hides the trend that matters. And when the pre-service cohort starts reaching end of life, treat that as a scheduled event rather than a surprise: you know roughly when those machines were bought, so you know roughly when the disposal work arrives, and the companies that get caught out are the ones who stopped thinking about the old fleet the day the new arrangement started.
The Cost of Getting the Model Wrong
The expensive failures are internal, which is the whole argument of this article.
The half-migrated process is the most common. Two parties each believe the other handles collections, so collections stop happening, and nobody notices for a quarter because nothing visibly breaks. The devices are simply still out there. When somebody finally counts, the gap looks like a vendor failure and is actually a trigger that was never rewired, and by then several months of leavers have gone through.
The second failure is the record authority nobody named. The vendor platform is right about what the vendor did. The internal register is right about what somebody typed. Both produce a fleet count, the counts differ, and because both are partly right neither can be discarded. I've seen this consume a day a month in reconciliation that existed only because a single decision was never made at the start.
The third is the budget mismatch. Least serious, most irritating. A recurring service charge arriving against a capital hardware line produces a monthly question from finance, a monthly explanation from you, and a year of small friction. It costs nothing to fix in advance and cannot be fixed cleanly in arrears. Because the first few months are already recorded on the wrong basis.
So the diagnostic worth sitting with: are you changing who does the work, who holds the record, or how the money is shaped? A service arrangement changes all three, and only the first one is on the vendor's side of the line.
When You're Ready to Move Beyond Running It Yourself
The signals are specific. Equipment work is landing on people whose job is something else, and not one of them has it written anywhere in their objectives. A start date has slipped because of a device. A leaver's laptop is unaccounted for and somebody senior asked about it. Twenty joiners in one month would break your current arrangement and you know it. Any two of those and self-running has reached its limit.
Start with the trigger map. Write down every equipment event in a joiner and a leaver, name what starts it today, and mark which of those triggers will still exist after the change. That page is both your implementation plan and your best question set for a vendor call, and it takes an afternoon.
RemoAsset covers the distributed joiner and leaver cycle with a published annual figure and the three limits named above, and the honest framing is that buying it will not help unless the offboarding trigger is rewired. That part is yours, it is the highest-return hour in the whole project, and no vendor can do it for you.
One Thing Worth Knowing Before the First Renewal
A note for twelve months from now, because this is where these arrangements are either confirmed or quietly regretted.
The renewal conversation will be about price unless you make it about performance, and you can only make it about performance if you kept the four measures. So keep them. A quarterly note in a document, taking fifteen minutes, recording recovery rate, time to device in hand, internal hours and the sample accuracy. Four numbers, four times a year.
What that gives you at renewal is unusual and valuable: a specific conversation rather than a general one. You can say that recovery went from a measured figure to another measured figure, that two markets consistently underperformed the stated window, and that the exception rate was higher than expected in one region. A vendor faced with that will negotiate on the things you care about. Because you have given them something concrete to respond to.
And if the numbers went the wrong way, you will know early rather than at the point of commitment. That is the real reason to measure. Most arrangements in this category are broadly fine and a few are quietly not working, and the difference is invisible from inside without a baseline. Fifteen minutes a quarter is a small price for knowing which one you have.
Frequently Asked Questions
What is equipment as a service?
It's a recurring fee covering devices and the work around them. That work means procurement, delivery, replacement, collection and storage across a stated list of countries. The fee replaces a purchase. The distinguishing feature against a lease is that somebody other than you performs the physical work, and the distinguishing feature against buying is that you stop owning the hardware.
How is equipment as a service different from leasing?
A lease moves the money. A service moves the work. Under a lease a funder owns the device and you still arrange the shipping, the repairs and the collection at end of term, which is the part people most often misread. Under a service the fee is meant to include that handling, so the question to ask directly is who books the courier when somebody leaves.
What has to change internally when we switch?
Four things. Approvals move upstream to the hiring decision, budgets move from capital and lumpy to recurring and per head, offboarding needs a system trigger for collection instead of a person remembering, and somebody has to name which system is now the authoritative record. The fourth is the one most often skipped and it causes the most lasting confusion.
Should we move our existing devices onto the service?
Usually not. Machines in people's hands should stay there and be collected by the vendor when that person eventually leaves, which converts the fleet naturally over two or three years. Collecting and re-shipping working hardware costs the user time and gains you a tidier table, and a vendor who pushes for it is optimising their record rather than your quarter.
Does equipment as a service include device management?
No, and this is worth confirming explicitly in any proposal. Logistics vendors move and track devices as physical objects. Endpoint management enforces configuration, pushes updates and proves a device is in a known state, which is a different product from a different supplier. In a distributed fleet you will normally run both, and the handover between them at enrolment is worth designing deliberately.
How do we measure whether it worked?
Four numbers, and collect three of them before you change anything. Time from offer acceptance to device in hand per market, recovery rate within thirty days of a leaving date, internal hours spent on equipment work, and record accuracy from a sample of 25 rows. A baseline gathered afterwards is not a baseline. So the hour spent counting now is the most valuable hour in the project.
What happens if we want to stop?
Ask before you sign. Get the answer in the agreement rather than in an email, because the email will not be findable in two years and the person who sent it will have changed jobs. The useful question is specific: if we leave in month fourteen, who holds the devices, who ships them where, what does that cost and what can we export including custody history. A vendor who answers all four cleanly is telling you something reassuring about the preceding thirteen months.
A last word on expectations. Because this category is sold on relief and bought on hope. Equipment as a service will not make your fleet record perfect, will not find the devices you have already lost and will not reduce your software bill by a penny. What it does, when the internal wiring is right, is take a recurring piece of physical work off a team that was never resourced to do it, and convert an unpredictable weekly annoyance into a line in a budget. That is a genuinely good outcome and it is worth buying. It is just a narrower outcome than the proposals tend to imply, and knowing the boundary in advance is what separates a team that is satisfied at renewal from one that is disappointed.
Rewire the offboarding trigger before you sign anything, because that is the change that actually pays.
