Why do agencies find it so hard to sell support contracts?
It’s all about expectations
The right time to promote the importance of maintenance and support contracts is when customers approach agencies to inquire about working on a new software project or to purchase website maintenance services.
Ask any project manager and they’ll tell you that setting expectations early is what you do before any delivery starts. It pays dividends down the track when things inevitably change and course corrections are needed.
But be careful not to over-promise. When that happens, the pressure is on the agency to maintain what could become an unsustainable effort over the relationship’s term. It then becomes quickly obvious that slowing down or reneging is all but commercial suicide.
Under-promising on the other hand gives agencies some wiggle room, but only when the intention is to improve. With respect to website maintenance services, it’s the agency’s responsibility to flag its importance proactively - it is the domain expert after all.
Who should be suggesting a maintenance contract anyway?
Whenever a customer has a strict set of security, performance, and maintenance requirements of their own is the ideal time to play any trump cards you have, and to wrap an eventual contract around them:
24x7 or round-the-sun support
Standardized Recovery Point Objective and Recovery Time Objective (RPO and RTO)
Repeatable maintenance workflows for mitigating security vulnerabilities
Documented pricing (or pricing ranges)
Boilerplate plans to underscore end of life software best practices when end-of-life (EOL) dates hit (upgrades, LTS, or NES licensing)
For those less technically savvy customers, it behooves agencies to be pragmatic and to ensure that both entities are covered from a business perspective with auto-renewing support contracts, because without one:
Ad-hoc maintenance work means unpredictable income and inconsistent risk mitigation
Incident response takes longer as there’s no documented process
Customers’ production applications are left vulnerable for longer
Tooling investments become harder because sufficient revenue isn’t available
Smoke and Mirrors vs Actual Process - The Fine Line
As an agency, you’re most qualified to understand maintenance and contractual shortcomings.
Everyone knows maintenance isn’t sexy, that developers will complain, and convincing customers to spend money on work they and their own stakeholders won’t be able to see, remains very challenging.
But if in sales pitches and RFP responses, agencies find themselves needing to stretch the truth in order to win work, that’s a strong “smell” that it’s only a matter of time before being approached for similar work and having to repeat the effort, while the rest of the team again fails to navigate what’s been promised - absent themselves.
There is an intermediary state which agencies can sometimes adopt. While “approximating” their actual capability in a pitch, the business may decide prior to allocate internal time - noting it as an investment, and not another internal cost - to actually use what’s been pitched as a guide for exactly what needs to be done better, when compared to current state:
Named: Specific AppSec and ASPM tools used in day-to-day maintenance
Documented: Steps followed in security vulnerability and incident responses
Specified: Incident response times, RPO, and RTO calculations
Planned: Deliberate software EOL upgrades, budgets, and license timelines
Going one step further, agencies can augment existing website copy and sales material with these - their principles of maintenance excellence.
Such self-promotion is a valid point of difference worthy of consideration by prospective customers which may not immediately invoke an understanding of its value proposition. But by virtue of its inclusion in promotional material, should cause customers to pause to consider.
Follow the Money
In business, everything boils down to money. Agencies are no different and repeat, predictable income is king. Even the most well-intentioned and process-driven agency still needs to profit enough from its activities to stay in business and to build amazing software.
So it shouldn’t be too revolutionary to concede that effort-in equals revenue-out with respect to developing and promoting customer support contracts.
Revenue earned from support work can be reconciled with upgrade, re-licensing, and decommissioning projects from those same customers. With the right analysis, marketing and sales material becomes more targeted, as do your customer conversations.
Why is it so difficult?
There are a few possible reasons for the existence of customers and their web applications - sans any sort of maintenance contract.
The History Factor
There are 15+ year old Java and PHP monoliths still chugging away out there with little more in the way of a support contract, than a promissory note for maintenance services rendered.
The situation is unlikely to change until something forces the hand of an agency or its customer - say a state sponsored DDOS attack on key government web infrastructure for example.
The Invisibility Factor
Some customers will justify not paying for something if they cannot see it. Precisely because of this, an agency’s hands are tied, unable as they are to provide a satisfactory reason for work the customer is technically correct in saying no-one will ever see.
What can be seen though is data from governments around the world describing the downstream effects and costs to business of security vulnerabilities found in commonly used software.
Log4Shell - 2021 (Global): 100+ million affected applications and devices
Medicare - 2024 (Australia): 12.4 million individual (people) affected
Shai Hulud - 2025 (Global): 700+ popular JavaScript packages affected
The Implausibility Factor
Humans are awful at accounting for things which haven’t occurred yet. Some go further and adjust mental models and end up believing that something awful will never occur - the commercial equivalent of burying heads in sand.
The irony of this attitude isn’t lost on security practitioners. Data-breaches, zero-day exploits, and other internet malfeasance with the potential of harm at a national level now occur every single day to somebody, somewhere in New Zealand and globally.
No matter how much agencies - and even customers - might wish to rationalize away the potential of something “bad” happening to them, forewarned is fore-armed.
So, what’s an agency to do?
Irrespective of your agency’s maturity with respect to its ratio of customers to valid maintenance contracts, consider the following as a summary:
Talk to customers: Support plans aren’t needed on day one, but an intent to get one is. Design one together with your customers
Know your portfolio: Update it often. CRMs, wikis and spreadsheets get stale quickly
Understand threat landscapes: Armed with some knowledge of popular modes of attack, find real world examples featuring similar technologies
Implement security tooling: Some application security tooling is better than none but not if only a subset of a portfolio is covered
Push back: Contrary to popular belief, customers will respect you more. Agencies have the domain expertise, so armed with context, experience, and knowledge - argue your position
In our previous post Why SCA, SAST, and SBOMs don’t equal EOL planning for digital agencies, we put forward the case that there’s a need for maintenance and security tooling which represents the business of agencies better.
If you or your agency wants to be the first to know when agency orientated security tooling finally lands, join the waitlist.
You can also level-up your agency’s approach to end of life software best practices. Get the 1-page EOL Survival Guide for agencies.