The typical work of software agencies, consultants, and freelancers is project-based. You win the project, provide the service, and receive the agreed payment. But project work can be feast or famine, and a large cause of stress within agencies.
Your pipeline can be full, but then some projects get delayed or fall through. You can have zero work scheduled, but then within a week you have triple the amount you can handle. This makes forecasting difficult, and results in very lumpy payment schedules.
Recurring revenue brings reliability to your bank balance and longer-term scheduling. It can help shed the limiting mindset of “project-based work”, and get you (and your client) thinking more of a long term partnership.
What is recurring revenue? 👩💻
Recurring revenue is income you receive from a client after recurring time, e.g. monthly. This is different to project payments which generally occur after a certain delivery or milestone is complete.
Some recurring revenue streams such as retainers and maintenance contracts rely on you completing a set amount of work in a specific period. But others, such as ongoing support, are payments that take place irrespective of whether any support work took place within the period.
Below I run through some of the more common forms of recurring revenue I implemented within my agency. I also mention a couple of types that may be common, but I never implemented, and why.
Ongoing support ☎️
“Just remember that when nobody was there for you, I was. And when nobody else gave a damn, I did.” – Drake
Software isn’t as easy as “build it and forget it”. Bugs happen, third-party APIs change, and customers have unexpected urgent requests.
A ongoing support agreement is a contract between you and your client outlining how you will providing future support services for them.
You agree to terms such as:
- Your availability to support their system in a certain timeframe – e.g. Monday to Friday, 9am to 6pm.
- Your response time and medium for any issues they report – e.g. get back to them within 4 hours after reporting an issue, contact via email.
- Your rectification time, or ideal rectification time – e.g. 24 hours.
The specific variables (timings) depend on two things. What your client requires, and what you are willing to provide. I had support agreements requiring 24 hour support, 365 days per year, with a 15 minute response time. I recommend avoiding that if possible as it’s a big commitment!
Be clear whether you are supporting the application software, the infrastructure/system, or both. You may be happy supporting all components, but have clear written expectations. If infrastructure is not your thing (and you didn’t set it up), then supporting it may not be in your best interest.
Why would a client pay a recurring fee for ongoing system support?
An issue with a system is never good news for a client. It could mean loss of income or customers, as their business may not be functioning. A support agreement provides the client with confidence that you have the time to help them.
They pay for you to be available to them at the time they need. Like car insurance, they most likely won’t need it, but if they do you will be there. So it’s money well spent.
Why would you offer system support?
As your business and client base grow, it’s hard to drop everything when something goes wrong. You don’t want to delay
