What is a Retainer?
Retainer is an ongoing agreement with a client to perform ongoing work for them. Typically these are used for website support, but they are also used for ongoing consulting and design arrangements, or when we act as a subcontractor under a separate agency partner.
Why Are Retainers Important?
Retainers represent ongoing business relationships with a client.
- They provide steady, ongoing income for Cantilever.
- They provide reliable work for our employees on an ongoing basis.
- They allow us to refine and manage the visual identity and code base of the website over time, keeping it consistent and clean.
- They represent some of our best relationships with clients, that often lead to referrals as clients that enjoy working with us recommend us to others or bring us with them when they change jobs/roles.
How are Retainers Structured?
Every retainer has:
- Term - A recurring period in which work occurs and budget is allocated. Currently we have Quarterly, Monthly, Yearly, and hourly retainers.
- Hourly Rate - A dollar value that dictates how much the client is currently paying per hour of work done by Cantilever.
- Budget - A dollar value OR number of hours outlining how much work should be done in a term.
Roles in a Retainer
- DRI: a responsible person at Cantilever who manages the retainer, associated work, schedules, communication and related issues.
- Technical/Creative Lead: This is the person who is deeply intimate with the technical or creative side of the client’s project. They can help the DRI answer any specific questions the client may have. On a project including both design and development, there may be two separate people playing these roles.
The Harvest Project
Harvest is our mechanism for tracking costs against a project and billing the client. Each retainer has a project in Harvest for that given term and budget. This project gets archived and remade every term. Harvest tracks both employee work, on the timesheet; and project expenses, on the Expenses page.
The Harvest project Timesheet should include:
- Specific Line items for each large task (4+ hours of work)
- General Line Items to absorb smaller recurring tasks
- Assigned Team Members who will work on the project.
An active Harvest project could look like this:
Include unbillable tasks for:
- Client Relationship Management
- Complementary Work
If an new team member or new consultant is learning while working on a retainer team, make sure their time is logged in the Complimentary work section for any training/learning times they log while figuring out their tasks. When they are working on the actual task and getting stuff done they can bill their time to the task in harvest up to the amount allotted for that task. Any overages would then go back into complimentary work since they are just learning.
Sometimes there are costs associated with doing retainer work, such as print costs, software costs or other things. All expenses related to a project should be tracked in Harvest's expenses. If an expense is billable to the client, ensure the billable checkbox is checked.
A Basecamp Project
While Harvest tracks the costs associated with a project, Basecamp tracks pretty much everything else.
Each Retainer Project should have at least 4 tools associated with it:
- Message Board - For posting meeting notes and other discussions
- Todos - For tracking the things that need doing, by whom and when.
- Docs & Files - For holding retainer documentation.
The most important part of a Basecamp retainer project is the Todo List. The Todo List outlines what needs to be done during a given term, who should be working on it, and when it's due.
Work should be broken up into lists for each term, with that term's list being triaged and archived at the end of each term.
There are 3 primary lists associated with a retainer:
The Term List
The Term List shows what items are supposed to be completed during the active term, who's working on it and when it's due. Every item in a term list should have an assigned team member and a due date. Without these things, the items on the term list don't get done.
The Backlog represents work that is not currently active, but could be considered during later terms. Items in a backlog can have an assigned team member, but shouldn't have a due date, as they aren't currently active.
The Forecast Board
This list allows us to add any tasks that were not agreed to at the outset of the term. Some clients have an issue or a last minute change they would like us to work on for them. Or they have a new idea they'd like us to flesh out and complete. We categorize these requests by Urgency level so that we can ensure we are getting the most important tasks completed first.
Managing a Retainer
The DRI should act as a communication hub and monitor. Most of the time, the client will interact only with them. Sometimes, the client will work directly with a different Cantilever team member, but with feedback and outcomes reported back to the DRI. The DRI is responsible for:
- Coordinating all work to be done
- Maintaining an organized schedule and task list for the month
- Tracking and distributing reports on hours
- Memorializing decisions that have been made, taking and distributing notes
- Providing answers quickly
Correspondingly, we request that the client provide a primary contact who can act in much the same manner. We need this person to take responsibility for:
- Communicating with Cantilever
- Retrieving assets and logins as needed
- Distributing information within the client's organization
- Providing collated feedback and formal approvals
- Coordinating content creation and other client responsibilities
- Ensuring that bills are submitted and paid in a timely fashion
We want to flex to the client’s workflows as much as possible and are happy to work directly with other parts of the organization but will request that communication be logged and reported back to the DRI so that a clear paper trail is available for any decision.
If there are delays in receiving feedback, assets, logins or approvals, deliverables will be delayed. But with these roles clearly defined, projects can be delivered quite quickly and with minimal error.
We bill for all time spent on retainer tasks including calls, meetings, and email time related to project work. We do not bill for time spent discussing our business relationships with clients, creating monthly retainer reports, traveling to their offices, etc.
We bill for true, focused work time, not approximations. We value transparency and share our time reports down to the minute.
As a courtesy, we “roll over” hours from period to period. So if we really want to push to launch a certain feature this month, we may use extra time to get it out, and remove that time from the next month. Or if the client doesn’t have much for us to do in a given month, we’ll let them have some extra time in a future month. Since the goal of the retainer structure is stability for all parties, we try not to do this, and always immediately “true-up” the hours in the following month. If more than one month in a row contains significant deviations from the retainer level, it’s probably time to change the retainer level. We typically go over our time by a few percent per period which we do not charge for, which is a perk of being a retainer client.
Our retainers are currently non-binding agreements which are severable at any time. In the unlikely event that the client chooses to end the agreement, we keep payment for any periods we have started work. In the unlikely event that we choose to end the agreement, we refund them their payment from the current period.
Billing in Advance
We bill for retainer agreements at the start of a period, not the end, so that we can confidently reserve retainer time in our schedule in advance and avoid booking other work during that time. We formally mark our bills as Net 30.
Tweaks, Maintenance and Refactoring
For a website support project, we expect to use around 25% of our retainer time each monthly period keeping the codebase up-to-date, bug free, and optimized. This involves:
- CMS and plugin updates
- Third-party script or library updates
- Refactoring: Optimizing and consolidating parts of a codebase without causing a visible change. Think of it like the Oil Change of web development. We like to refactor older parts of a codebase on a rolling basis especially as newer techniques become available to optimize them.
- Fixing miscellaneous bugs that crop up
- Making small tweaks as requested
In periods with a significant goal to accomplish we may suspend this work to focus on the goal. But we find this regular maintenance vital in protecting the client's site and extending its lifespan. As with all our work, our monthly report will account for time spent on these endeavors.
While working within retainers, we will provide estimates of every single task to clients. These are merely guesses, and should not be taken as budgets, but since they are important for planning, we are sure to keep clients apprised of any significant guess changes as we go about our work. If there are any tasks that look like they might take longer or shorter than expected. In those cases, we can decide how to adjust the month’s plan accordingly.
Proper management of retainers is critical. They typically deal with small amounts of work at a time, and clients want to see tangible results. One mistake – not paying attention to the number of hours something takes, for instance – can erase the company’s margin entirely.
Throughout the retainer period, the DRI should reach out regularly to the client to keep them apprised of the status of their work and the hours spent so far. Clients should never be surprised at the end of the period. The DRI must regularly check in on hours spent in the various tasks.
Never use hours in excess of the retainer amount without approving an overage with the client. It is the DRI’s responsibility to manage our usage of the client’s time inform the team when they should stop work on a given retainer.
The DRI is also responsible for managing the task list within the Basecamp and Harvest during the period. It is not uncommon for clients to ask to shuffle priorities mid-retainer, and the DRI must react properly to that and make the right adjustments for the team to continue working fluidly. If we run out of time for the period, inform the client and stop work immediately.
Sometimes we will we decide to proceed anyway and eat the time, but we must stop and discuss it first.
End of Period
At the end of each retainer period the DRI must:
- If the client likes calls, arrange an end of term/beginning of term call with them. Use this time to understand what their priorities are for the new term. This will help guide any estimates needed or work to be scheduled during their next term.
- Send an end of quarter email detailing the hours used. We send weekly update emails as well so the client should be well versed in how much time is left and what items have been completed throughout the term.
- Create a new Harvest project for the next retainer period, matching the estimates from the email, and archive the prior project.
- Archive the previous period’s term list in Basecamp and create a new term list.
- Double-check that all invoices for this client are paid. If by the end of a given period we still have outstanding invoices from a prior period, we should not start more work, unless we get strong assurance from the client and an explanation of why things are behind.
Project Lifecycle Within Retainer
During the term meeting, the DRI will discuss the details of each of the period’s tasks with the client. Sometimes, the team will want a secondary meeting with the client around a particular task within the retainer. Since we bill for meetings, these calls can get expensive, so as much as possible, the person doing the work should conduct the meeting with the client. They should take good notes and report back to the DRI on what was discussed, via Basecamp.
Every particular task will vary greatly in how we execute based our comfort level with the client and what we are doing. Consulting-style tasks usually culminate in an email to the client or a shared Google doc. Design tasks usually involve mini-reviews and a final delivery of files according to the request.
Significant development efforts will typically involve a QA process. Whoever has done QA for that specific client before should be tapped to do any QA in the future. This will be less intense than a new build project but is just as equally important.
For the most part, retainer tasks feel like micro-projects and follow the same practices and patterns as discrete projects. They just don’t have the same formalized structure much of the time.
After a retainer relationship ends, the DRI must:
- Archive Basecamp projects
- Archive any remaining Harvest projects
- Archive Invision prototypes
- Archive Github repos