When a small internal tool goes live, the project ends but the need for care does not. Something will break after a software update, a colleague will leave and someone new will need access, or a form will need one more field. Without an agreement, each of these becomes a negotiation: the company is unsure whether it can ask, and the supplier is unsure whether it is being paid.
This article is for an owner or operations lead who has just had, or is about to have, a small tool built and wants a simple support arrangement. It is also useful for a supplier writing one. The aim is a single page that both sides can read in five minutes.
What the monthly fee includes
Write the inclusions as short, concrete statements. A typical small-tool agreement covers:
- Fault fixing. If the tool does not do what was agreed at handover, the supplier corrects it at no extra charge.
- Keeping it running. Applying security and platform updates, renewing certificates and checking that backups work.
- Small adjustments. A fixed allowance, for example up to two hours a month, for changes such as a label, a dropdown value or a report column.
- Access changes. Adding and removing users when staff change.
- A named contact. One person or one mailbox, so requests do not get lost.
Say what "agreed at handover" means. If you wrote down what the tool should do, as suggested in first-line support for an internal tool, the agreement can point to that document. A fault is a difference from it; a wish is not.
Response times
Promise what can be kept. Two or three levels are enough:
| Situation | Example | First response |
|---|---|---|
| Tool unusable | Nobody can log in or save | Same working day |
| Part of the tool affected | One report is wrong, one user is blocked | Within two working days |
| Question or small request | How do I export last month? | Within five working days |
Measure in working hours and state the hours and time zone. Define "response" as a human reply that confirms the problem and says what happens next. It is not a promise to fix the problem in that time, and the agreement should say so. If you want a fix target, set it separately and only for the top level.
The company has a part to play too. Ask that requests come to the named mailbox with a short description, what the person expected and what happened instead. A request that says "it doesn't work" takes longer for everyone.
What costs extra
This is the section most often left vague, and the cause of most disagreements. Be explicit:
- New features or new screens
- Connecting the tool to another system
- Training for new staff beyond a short call
- Work caused by a change on your side, such as moving to a new accounting system
- Support outside the agreed hours
- Recovering from data that was entered or deleted incorrectly
For these, agree a routine rather than a price list. For example: the supplier gives a written estimate within five working days; work starts only after a yes by email; the small-adjustment allowance can be used first. The intake rule in handling change requests after launch works well as the front door for this section.
Decide what happens to unused hours. The simplest and fairest rule for a small tool is that they do not carry over, which keeps the arrangement easy to explain; if you prefer a carry-over of one month, write that down.
The monthly summary
Once a month the supplier sends a short note, five lines at most:
- Requests received and closed, with the response time for each
- Faults, with the cause in one sentence
- Updates applied
- Allowance hours used
- Anything the company should decide, for example a request that needs an estimate
The note keeps the agreement honest. The company sees what it pays for, and the supplier has a record when someone asks whether support is worth the fee. If a log exists, as described in what to log in a small internal tool, most of the summary can be written from it in ten minutes.
Price and term
Keep the price a fixed monthly amount for the included items. A fixed fee is easy to budget, and it gives the supplier a reason to prevent faults rather than bill for them. Review the amount once a year, and say how much notice is given before a change.
Run the first term for three months, then monthly. A short first term gives both sides a chance to see whether the allowance and response times fit the real volume of requests.
Ending the agreement
Agree a notice period, usually 30 days, for either side. Add three practical items so that ending is not a crisis:
- The company keeps access to its data and can export it in a usable format
- The supplier hands over the documentation, credentials for the hosting and any scripts needed to run the tool
- The last month ends with a short handover call
Without these, "ending the agreement" can mean a tool nobody knows how to run.
Common mistakes
- Promising a fix time for every request, and then missing it
- Leaving "small adjustments" undefined, so any request is either free or a dispute
- Counting a question as a fault, or a wish as a question
- No named contact, so requests arrive in several inboxes
- No summary, so the company forgets what the fee covers
- No exit terms, so the tool is held hostage by the paperwork
Checklist
- A list of what the monthly fee covers, in plain words
- Two or three severity levels, with first-response times in working hours
- A definition of "response" that does not promise a fix
- A list of what costs extra and a routine for estimating it
- A rule for unused allowance hours
- A five-line monthly summary
- A fixed monthly price, a three-month first term and a 30-day notice period
- Exit terms for data, documentation and access
Sources
- Common practice for support and maintenance of small custom software, offered as a practical guide. The response times, allowance hours and notice period are starting points to adapt to your own tool and supplier. This is not legal advice; have the final text reviewed before signing. No client results or market figures are claimed in this article.