Let’s say something obvious - in any good client-vendor relationship, it’s important to define who is responsible for what.
Great. I assume this is why a lot of contracts simply read: “Vendor agrees to generate digital products. Client is responsible for final sign off.”
Sure, this makes writing contracts easy, but the ease and relaxed attitude comes with a cost. Before writing another generic contract, let’s take a look at a couple of possible, and likely, confusions that a lack of clarity can lead to.
Vagaries can lead to a false sense of security
One group can simply assume the other group has ‘got it covered.’
Take for example a pretty common ask - “Have proper SEO on our website.” From a developer’s perspective this is proper semantic structure, correct meta tags, and a handful of other important technical tasks. However, in the back of the dev’s mind, they may be thinking, “This is good, but what is most important will be the linking strategy and the content generation, which of course isn’t my responsibility.”
Perhaps everyone involved is SEO savvy, perhaps they are not, and so when the dev in question offhandedly mentions his thought above as the client’s job, there is likely to be a few questions, namely: “I thought you were handling the SEO?”
The definition of digital is too broad
Everything is managed digitally now, so while it may be clear to a developer that they are only supposed to handle Wordpress theming, in a client’s mind “building a website” may include logo design because, after all, it’s part of the website, right?
What’s ideal for both groups may be in conflict
While in the past, developers could put together a site that was easy to code and impossible for the client to modify, these days non-tech people are quite comfortable with complex interfaces and content management. So discussing beforehand what the client would like to control gives the vendor scope on how elaborate the project may need to be.
Consider - how often do logos change? Surprisingly often, so hard coding the header may not be appropriate for a project. It’s a mistake on the vendor’s part to assume that they are completely responsible for everything on the site just because it may have a technical solution.
Finally, Be Wary of Favors
Even when responsibility is properly divided, favors can be nice, but they are not always the best idea. For example, a developer may be happy to throw out a couple design suggestions for a sidebar; a client may have no trouble checking how the site looks on the Android phone that the vendor doesn’t have on hand; or maybe every one collaborates on a digital strategy report intended for upper management.
While these are all great, the size of favors can quickly escalate. Site needs a new section? Sure - let’s just have the dev throw together some wireframes, interactive comps and so forth, as they did so well previously with the sidebar. Vendor is pushing through dozens of changes each week, so let’s send the client thirty emails to double-check changes on Android. And did we mention that the boss wants a few more paragraphs on digital market penetration in the Canadian market?
It’s nice to do favors, but make sure favors don’t turn into obligations.
Overall, these details can be made clear up front and that’s why it’s important for both sides of the table to not only explicitly state their responsibility, but discuss with some detail what each side plans to do with said responsibility. This can be as detailed as outlining what each side perceives as an SEO strategy to being clear that developers are not designers or to only send emails at random times if they are urgent.
None of this discussion has to be harsh or defensive, and it may actually be a good start to better understanding, and heck, even liking each other.