Nothing beats kicking off a project with a new client. You might think pausing to talk legal contracts would suck some of the fun out of it, but a well-crafted MSA can set the stage for a solid working relationship.
Nothing is more fun than kicking off a project with a new client. With only opportunity and blue sky ahead, pausing to talk legal contracts can suck some of the fun out of it. But I’m here to tell you that a well-crafted MSA, with clarity and agreement from both parties, can set the stage for a solid working relationship. Ensuring that everyone is aligned in their expectations at the beginning of a project saves all kinds of potential headache and heartache if challenges arise down the road. This not only protects all parties legally, but it allows you to start your relationship grounded in transparency and honesty, setting the foundation for healthy communication workflows throughout the engagement.
While some organizations treat their legal documents as an opportunity to gain some advantage, or to create inequities between parties, we use them to ensure that everyone knows what they’re getting into and is satisfied with the terms. We’ve taken our standard MSA and boiled it down to a basic template. If you’re engaging with an agency, compare their MSA to this one. If there are dramatic differences, ask “why?”. If you’re an agency in need of a template, this is a great starting spot.
Before we dive in, we need to begin with a meta-level understanding about legal agreements. We are not lawyers. We hired lawyers and CPAs, of course, and they’ve looked over this document many times. We’re sharing this out of the goodness of our hearts, and we hope that you’ll benefit from the lessons we’ve learned. Please check with your lawyer and accountant to ensure that our MSA is a good fit for you and your business.
When you work with the enterprise and their procurement teams, one of the first things on which to align is verbiage. This is basic basic, but I had to learn it at some point. So I don’t want to assume everyone reading this knows the lingo, too.
A Statement of Work (SOW) describes what a customer will receive in exchange for their money: we’ll do this (scope), on this schedule (time), for this amount of money (budget).
A Master Service Agreement (MSA) is the governing document for your entire relationship. It establishes agreements and sets expectations for how you’ll operate and interact—how you’ll get paid, who owns what, how taxes work, how you’ll communicate, and what happens when people disagree.
Typically you’ll have an MSA in place for the duration of your relationship, and you’ll have an SOW to cover individual projects and engagements.
Most MSAs share common DNA. They define boundaries and the approach to work, pay, communication, ownership, limits, liability, and legal terms. We ultimately end up using our MSA on about two-thirds of our projects; for the remaining third, we use the customer’s.
That doesn’t mean either party signs blindly. I nearly always find myself working through specific terms and adjusting them to meet the needs of the organization. When using customers’ MSAs, we almost always have to negotiate terms around certain items:
Negotiating MSA terms can feel stressful both both parties, but it doesn’t have to be. If both parties are entering into the agreement with the common goal of building a healthy working relationship, talking about the terms of that relationship is totally normal. You just worked so hard to come to an agreement on the project, and everyone wants to get started. Even if a customer has drawn up their own MSA, I’ve found that most companies expect you to read it and ask for changes. So they’re rarely surprised when you do.
Over time, our MSA has evolved and continues to change. In fact our Agency Director, Carly, and I just did a major edit in July 2019. I’m going to walk you through some of the thinking that goes into each section.
Scope of Services
Instead of outlining the work in question in the MSA, we simply refer to the accompanying statement(s) of work—in essence, under this agreement, we will complete the work outlined in the SOW(s), and all work performed under any SOW is subject to the terms of this MSA. This approach allows us to add new projects and work without reopening conversations around terms.
Statement of Work is an Estimate
The SOW represents our best informed estimate. A customer comes to us and asks to build a thing, and we make an educated guess about how much time and money it will take to build that thing. That guess can and will evolve as we learn more—so we’re not committed to the dollar amount in the SOW. That is, unless it’s a fixed bid / fixed scope job and we are beholden to a fixed dollar amount (in which case we remove this section).
Customer Deliverables
Customers are always responsible for bringing some things to the table—when it comes to building websites, that typically includes brand guidelines, media files, logos, imagery, and other content. Customers play a critical role in strategy as well as execution. This item in our contract makes it clear: certain deliverables (outlined in the SOW) are on the customer. If they don’t deliver them on time, project timeline and budget will be affected.
We staff project managers and digital strategists on our teams to identify key dependencies and coordinate collaborative work. At the end of the day, projects like ours are very collaborative. We rely on our customer partners to contribute, but it’s important that we clearly outline roles and responsibilities throughout the project. By clearly identifying what is and what isn’t our client’s responsibility up front, we can set the stage for healthy project flow.
Customer Sign-off
There are many organizations that do not have extensive experience in procuring digital solutions. We’ve found that it helps to articulate what the sign-off process looks so that our clients understand how and where they review the work. In our experience, it’s critical to have the customer dedicate an internal resource for quality assurance and actually put the work through it paces before it hits the user. It goes a long way to set up the customer for a confident project sign-off. By articulating what sign-off looks like in your MSA, you can avoid conversations like “I didn’t know you were done.” Or “I didn’t understand that I was supposed to give you final feedback.” Both parties want to launch with confidence. Aligning on the sign-off process helps instill that.
Project Timing
We estimate cost and allocate resources based on a given timeframe. Changing project timelines can affect cost and resourcing. No shocker there. The reality is that navigating this is actually really complicated. We tend to lean towards goodwill, and we acknowledge that a lot of what we do is hard and that customers are people too.
If a customer’s circumstances cause a delay of two weeks or more and our team is truly blocked with no quick resolution in sight, we freeze the project and put down our figurative pencils. We then try to reassign our team to other customer work. There may be a delay in getting the project going again, as well as a fee to offset those costs. In Tribe’s case, our contracts typically account for 2-5% of the project total or the cost of a single sprint, but you should find your own sweet spot. This happens rarely, and in fact, we often waive these fees if we’re able to reallocate resources to another project. But the reality is that there is a real cost to project delays, and we need to be transparent about it for our health.
Maintenance & Support
What happens after we deliver the thing? For how long do we take care of it, and under what circumstances? Who is doing maintenance? Support? What about Service Level Agreements? Let’s align on terminology first:
Maintenance: The tweaks you make on a system to make sure it operates as intended. These include basic security patches and updates to code libraries and systems. Maintenance is not driven by human demand but is typically on a pre-established schedule. Think of this like an oil change for your car.
Support: Human-driven updates. If someone tries to use something, and it doesn’t work the way they imagined it should, or if something broke, that requires support.
SLA: A service level agreement is a contractual obligation to respond and resolve an issue in a specific period of time. 95% of our projects do not have SLAs, but every so often we take on a high-touch project that requires rapid response. In those cases, we add our SLA clause.
Warranty
Full disclosure: this section isn’t perfect yet.
The biggest question we struggle with is this: when does the warranty truly start? If we finish our part of a project, but a customer delays and doesn’t launch it for a month beyond the established timeline, does the warranty timer start when we deliver or when they launch?
We don’t typically offer a “warranty” for work that is contracted on a time and materials basis. We handle the reality of post-launch bugs by always planning and budgeting for a post-launch sprint for this purpose. While most customers are comfortable with this approach, it has its challenges, like in cases when the project scope changes and eats into the budget.
These continue to be pickles for us. If you have some wisdom to share on this topic, we’d love to hear it!
Payment Terms
When are payments due? If the customer is late paying, what happens? In our case, the invoice incurs a monthly late fee, and work may be suspended until payment is received. A number of companies have early payment plans, typically offering a couple percent discount for payments in under 10 days. This is not something we offer, but it could be a clause that both parties appreciate — saving money and getting paid quickly.
Hourly Billing, Fixed Billing, Retainer
This item covers various payment models and how they work. We have included a few different types of engagements, and we remove the sections that don’t apply to that customer relationship. A note about volume discounts: we recommend putting criteria for volume discounts—for example, an expiration date and/or a minimum to qualify. So if you offer a discount based on at least $200,000 in annual billings, you should explicitly state that the discount will not apply if billings fall below that threshold. You don’t want to be stuck with a costly discount long-term or on projects that are smaller than anticipated.
Materials
If we have to pay for things in the course of doing our work—for instance, licenses for third-party software or images—do we get reimbursed for those expenses? Is there a mark-up? Will we be compensated for the time spent making those purchases? In Tribe’s case, yes, sometimes, and yes.
Travel
If staff have to travel to meet a client, we invoice customers directly for those costs. This section covers how we pass on those expenses, and how much we charge for that travel, including our team’s time and out-of-pocket expenses.
Deposit of Funds
It’s pretty typical in our industry to require a downpayment before starting a project. At Tribe, we do things a bit differently. The problem with a downpayment is that once the client uses up that deposit, you as a service provider no longer have a safety net. That’s why we instead charge a security deposit—kind of like paying the last month’s rent before moving into an apartment.
At the beginning of a contract, we invoice an amount equivalent to a month’s worth of work. The amount for each project is specified in the SOW and varies based on the size and velocity of the project. The deposit funds are then put into an escrow account. If at some point there’s any disagreement about payment or scope, we have a small safety net to protect the business. Worst case scenario, we have that deposit to cover any lag in payment as we’re figuring things out—or if work stops completely. No matter what, we at least have a last payment.
Once we get to the final invoice, we give the customer the option to apply the security deposit to the invoice or have those funds returned to them.
If you decide to go this route, you need to have a separate account for the deposit. Do not under any circumstances co-mingle the deposit with your other accounts. Don’t report the deposit as income—it isn’t. Instead, report this money as held debt. Include it on your company’s balance sheet, but not its income statement. If you ever end up applying the deposit to an invoice, declare it as income then and only then. If you’re hiring a vendor that collects a “downpayment,” make sure everyone is clear on how that money is held.
Annual Minimum Billing
We love delivering great work and pleasing people. We know that very small budgets often get the short end of the stick. When someone is paying you a half-million dollars to build their platform, it is easy to deprioritize a $5,000 project. To guarantee our own availability for turnaround times and quality of service, we’ve set a minimum for annual customer revenue. That number changes based upon service types. We have a lower minimum for design / brand projects than soup-to-nuts (definitely a technical term) web platforms. And to be totally transparent, that minimum also shifts based upon the health of our pipeline. We are usually very selective because we’re typically booked out 3-6 months, but market forces can make us consider smaller opportunities. We are super transparent about this number. In fact, it is stated in the first reply to each and every opportunity. E.g. “Thank you so much for reaching out. We would love to work with XYZ! We have a project minimum of $XX,000, and we’re starting new projects in November. If that works for you, let’s jump on a call…”
Sales Tax
Sometimes tax law changes—as we saw in 2018, with the South Dakota v. Wayfair case. You are obligated to follow current law when it comes to charging sales tax. When you have a multi-year project, you definitely don’t want to be on the hook to make up the difference if tax law changes and you suddenly have to charge sales tax. This clause makes sure everyone is nice and clear about who owes taxes when.
Payment Information
Many of our larger corporate clients want to mail us physical cheques—paper trail!—but it is always our preference to arrange for a bank transfer. We include a form to collect wire transfer details and hope that our clients fill it out. At the very least, it prompts a conversation about a customer’s method of payment. If a customer insists on using cheques, we charge a handling fee of $45 per cheque. Make sure to include any terms and fees like that in your MSA.
We find it most efficient when we have one person who is our go-to—our client-side mission control. And this person needs to have enough authority to make decisions and provide approvals on behalf of the organization. While we often work with committees, our most successful projects have someone with ultimate say-so.
During what days and hours can a customer typically expect a response from our team? Via which channels will we communicate? Whose project management software will we use? This section sets boundaries and expectations around communication. If possible, we always prefer to use our own project management software because it maximizes efficiency for our team—and means we control the stored data should we ever need it down the road.
Setting business hours when you have a multinational labor pool is an odd choice. Our teams are required to have a minimum of three hours of overlap per day, and that is flexible for each team. Our project leads make a point of establishing a standard communication cycle and setting availability with each customer. So why the business hours? Frankly, we mostly do it for our customers and to help focus communication. While we may actually have someone who is working during their evening or night time, we don’t want there to be mismatched expectations at the contract level.
Who owns the intellectual property when we create a website? We often get hired because of our domain expertise. That includes the tools that we’ve created to efficiently solve common challenges that customers hire us to address. I frequently refer to this analogy: the car belongs to the client, but we own the IP for the machinery used to make the parts and put them together. As a service company, we’ve built a huge library of code over the years. These assets are adapted and used time and time again, for the cost and time benefit of all of our customers. This clause makes that distinction clear.
We also do a significant amount of work in open source, often using other established libraries. It’s important to make sure everyone is complying with copyright in the correct fashion and respects other people’s ownership.
The longer you are in business, the more likely you are to have developed assets that allow you to offer greater value, move quicker, or scale your solutions. Those assets don’t belong to the individual customer, but rather they get permission to use them based upon the needs of the project. It’s important to maintain clarity around ownership and set expectations about the long term. Are you maintaining those tools in perpetuity? Does the customer need to renew licenses? How do they get support?
There are also sales tax implications that come with different types of offerings, and we’ve learned that it’s best to separate contracts for custom offerings from pre-canned software.
We work with some pretty big names, and we want to be able to use those names in our marketing materials, like in case studies on our website. Rather than waiting until a project is completed, we prefer to establish this permission up front.
For each of the items in this section, I could use the same explanation: Sh*t happens. The world is a rapidly moving and complex ball of mud and water, and we are not always in control of other people. So we try to set reasonable expectations and establish limits for all parties.
The bigger our projects get, the more people and departments tend to be involved outside of our own organization. These people are outside our control, so if they miss a deliverable deadline, we reserve the right to renegotiate the timeline budget based on the impact of those changes.
If the project uses a third-party API or service that breaks or goes down, we’re not responsible for those interruptions. This is really important these days. Modern web development is about amalgamating many platforms rather than hand-crafting one from scratch.
On the rare occasion that one of our web projects gets delayed, it typically stems from a customer team underestimating the effort and internal approval process for creating their own content. We’ve been evolving our content strategy practice and workflows, and we’re always looking at project dynamics to find new opportunities to further empower our customers. We’d be delighted to hear anything that has worked well for you in the past.
Copyright is a pretty big deal, and we don’t control the content our customers put into the platforms we build. We are responsible for adhering to copyright laws for any code bases we’re using, but our customers are responsible for ensuring that they have the rights to any copy or images used throughout the site.
Compliance is required for all government-funded work, but legal battles are also holding global corporate giants like Target and FedEx accountable for equal accessibility. While we hold ourselves to high standards in this area, we should all be careful to consider our approach and limit the liability involved in our web work.
We require all our customers to own their hosting infrastructure or their contracts with their hosting partner of choice. If the web host blows up, or if a shared server gets hacked, that liability remains with the hosting provider. We offer Devops consulting and will do a fair bit of support and make tweaks as needed, but the customer is responsible for their own hosting service.
Back up your stuff! We do our own backups while we’re working on a project, but once a customer’s site has been handed over, it’s their responsibility (along with their hosting provider) to make sure everything is backed up regularly.
There are bad people out there. Grumpy teens. Professional miscreants. Swarms of bots. We do everything we can in our power to build a secure and stable platform. But sh*t happens. Our contract protects us from this liability.
Building technology means we need to build our teams with the right skill sets. Some of those people are US W-2 employees, and in our case, many aren’t. Customers need to allow us to build and scale those teams as our business requires. At the end of the day, Tribe is responsible for the work we generate and the people we count on to deliver it.
Don’t steal my people! They’re my greatest asset. Besides, stealing isn’t nice.
Basically, if you’re not happy with the finished product, you can’t sue us or otherwise come after us for more than you paid us in the first place.
The legal mumbo jumbo that our lawyers make us say. Like what jurisdiction this contract falls under. =)
And finally…the dotted line. Make sure you get customers to sign the thing. Ideally they read it first, but the signature? Pretty important.
So that’s it. It’s a big doc, and there’s a lot to dig into. This probably won’t work out of the box for you, but hopefully it’s a good start to setting up a solid relationship.
The template is free. Grab it. Tweak it. Share it.
I lead an amazing team of UX, UI, Web + Mobile Design professionals. I have the most fun in the loosely defined space between ideas and execution and have a gift for noticing patterns.
