I listen to podcasts every day. Many of them focus on business in a number of capacities, many of them don’t. I found it interesting that two podcasts I listened to nearly back-to-back discussed client onboarding. It wasn’t the focal point of either episode, they each touched on the topic for just a few minutes, but the opinions expressed were nearly opposite.
The first podcast was a recorded mastermind amongst entrepreneurs. They were discussing ways of optimizing their workflow and one participant brought up the idea of modifying his onboarding process to set up a number of requirements for clients before their project could begin. They didn’t get into much detail but essentially the speaker was trying to streamline his involvement in the initial stages of a project by outlining exactly what he would need from his clients as a prerequisite for the project beginning. The requirements were completely reasonable: have your materials organized in a certain way so as to maximize the efforts of both the client and the service provider. He was aiming to create a situation that would allow him to sit down with a new project with all of the materials he needed to get working straight away. He felt this was a better approach than the back-and-forth that usually results from requesting these materials when the project kicks off.
This suggestion was met with pushback from everyone else participating in the podcast. They all felt that when it comes to client work you should make the inquiry process and project kickoff as ‘easy’ as possible for the client, reducing friction wherever possible. They said that by outlining requirements for a project to a client you’re simply making more work for them and therefore making it harder to work with the service provider as a result. The participants continued by explaining that reducing friction in no way means absorbing the associated costs, but instead to charge for services rendered as a result of reducing that friction. Of course these charges wouldn’t be pitched to the client in this way, it’s just the level of service they’re provided so as to make the project as easy as possible by offloading a number of tasks to the service provider.
The second podcast also brought up onboarding, but paid specific attention to project inquiries and how to design something that will be most effective for your business. On this side of the fence the host felt that an inquiry form should find out quite a bit about the project so as to get context for the job. The focal point of this critique surrounded the ever-popular budget field. The host of this podcast was adamantly against a budget field, stating that the inclusion of a budget field immediately puts a focus on money. It puts a focus on you being a cost instead of an investment. According to the host the overarching goal of an inquiry form was to find out about a potential project to see if it was interesting to you, and also find out how you can immediately shift into a value-based pricing mindset.
He went on to explain that a budget is never really a budget, it’s an arbitrary number that never truly reflects what the project could be, so it’s essentially pointless (even problematic) to speak about it so early in the inquiry process. The explanation went on to describe the process of taking the project goals as stated by the client and use that to dig deeper, to find out the reasons why the client wants to make these changes or have this thing designed and/or built. From there, the idea is to extrapolate and generalize their request into something that can be translated into either money saved or revenue earned, thereby equating that figure to the value of the project. At this point you have determined what the project is worth to the client and that’s what the budget should be. The short narrative was ended with the host indicating that if the client doesn’t see the value of the project at your deciphered price point, the project is a bad fit.
Opinions are like…
… a lot of things. Everyone has one and we can usually find a way to disagree about it. I too have an opinion, and it actually has to do with client onboarding as well. In my opinion, I disagree with the advice offered in both podcasts. I don’t wholeheartedly disagree with every single point brought up in both discussions, but I have a different feeling about the project inquiry process.
I agree with the first podcast in that removing friction is important; you don’t want to bombard prospective clients with an inquiry that resembles their tax return. I also think scaling it back to fields for name, email, and project description is taking it too far in the other direction. If a client isn’t prepared enough to present their project with enough detail to give you what you need, you’re setting yourself up for more work. The podcast mentioned that explicitly, but with the response of charging for that work thereby increasing your margins. But what if you hate doing that type of work? What if you don’t enjoy poking and prodding clients for this, that, and the other thing, and you really don’t like sifting through every piece of marketing material from the company’s inception and plucking out a few things that might prove to be useful? It comes down to whether getting paid to do it is worth it for you, I suppose.
The overhead of having to deal with additional services outside of your core offering feels dangerous to me. What if after taking on this project you find yourself inundated with material only to discover that the project is just the idea of a project, that you need to help flesh it out into something that has a definable scope? What if through this process you realize that the client was forced into this project against their will and they have a number of other higher priority items they spend the bulk of their time on? At this point you’ve already
- Handled the inquiry
- Gone through the introduction process
- Had some back and forth about the project
- Outlined what materials/details you needed from the client
- Waited (likely twice as long as you planned) for said materials/details
- Had to clarify a number of things
- Waited for feedback on clarification
- Organized everything you think you need for the project
Now you can begin the project. Even if you’re charging for the above, how would you go about it? If you bill hourly I suppose you can just keep the clock running, but if you bill project based (as we do so here is some bias from me) how do you roll that into the cost estimate? Do you pad the project cost to cover this process? If so, when do you share the project cost with the client (before or after this initial phase?) and how do you know what will be involved in this material acquisition phase of the project? The questions spiral out of control for me.
These questions and thoughts are founded on the idea of building websites for clients. I recognize that we are the professionals, we are providing a service to clients and that service is building a website that meets their needs. People have been using the Web for decades now. They use websites every day. They use their website every day and the check out competitors websites all the time. They know what websites they love and they know what websites they hate. I don’t expect clients to design their own website, but I do expect them to put in time and effort up front to outline what problems need to be solved prior to inquiring with a service provider.
The truth is, though, that not many potential clients do that. Many of them do just shop around for Web agencies with a good reputation and a nice looking portfolio. They inquire saying that they want their website redone because it’s old and they’d like it done as soon as possible. “How much will that cost?” scatter-shot approaches like these do not work for us. Our process is very hands-on and our inquiry form reflects that. We don’t ask for much but we ask for enough to indicate that you are serious about your project, that you have put some thought into it and you’re willing to partner with us on finding the best solution.
I think that all too often service providers manipulate the idea of partnership into “we’ll handle everything for you and you don’t have to worry about it and it will be awesome!”. I’m not sure why this has caught on so much but show me any other partnership with that relationship and I’ll show you (at least) one unhappy partner. A partnership means an equal division of labor and in this case client’s legwork is based on respective industry expertise. It doesn’t mean that we as the service provider will just build something beautiful and as a result it’s going to work great to solve your problem(s).
[Tweet “If you’re in client services: don’t pursue a bad fit.”]
Requiring items like a site map and content breakdown in Iron to Iron’s inquiry form surely does introduce friction, but it also raises a big green flag when those materials come though. A prospective client that’s serious about a project will likely have at least a shadow of those two documents prepared even if an hour of thought was put into the project. If that’s too much to ask up front, we feel that can be accurately extrapolated to paint a picture of what the full project would turn into, making it a bad fit for our process. We don’t like bad fits and we don’t like spending time pursuing bad fits.
Budget and the discomfort of talking money
The second podcast focused on one issue that appears to irk the host each time he sees it: a budget field. If you revisit our inquiry form you’ll note that we have a budget field, in fact it’s huge. I agree with the podcast host that talking about money up front can come off as a bit weird in certain situations, but I also feel that not talking about money opens up too many doors to wasted time that’s much better spent elsewhere.
We live in a world where cost of the service we provide defines a wide spectrum. We have websites dedicated to facilitating jobs for five dollars and other agencies doing projects for millions of dollars. My hyperbole is strong here but even when comparing an ‘average’ website (as impossible as that is to define) you will get a huge range in price depending on who you ask. If we put ourselves in the shoes of our potential clients, the people submitting our inquiry form, we should know that there is a preconceived cost already in their mind (if not explicitly dictated by a marketing budget). This issue is compounded by the fact that websites can range in cost for a myriad of reasons:
- Custom development costs
- Elaborate hand-made illustrations
- Immersive interactions
- Internal requirements
Just to name a few. Every project has a specific set of requirements that must be met, and there’s a budgetary limit (of some sort) to make that happen. We don’t ask the budget so as to maximize it and get every cent we can, we ask the budget so as to maximize the project and make it everything it can be.
Maximizing the project is essentially where value-based pricing comes in. I wrote a lot about value-based pricing recently and don’t want to reiterate it here but the short version for the sake of explaining a budget field on an inquiry form is this: speaking about budget up front provides grounding within the inquiry process. It is another gauge of the client’s perception of both the project at hand as well as the service being provided. Without it the inquiry is a rudderless ship that can meander everywhere except a logical conclusion ending in a signed contract.
The feasibility of a project stands on three legs at Iron to Iron:
- The scope
- The timeline
- The budget
That order is intentional. Knowing the budget is a necessity but it’s not something we lead off with nor is it something we focus on. It acts as a method of orientation for the entire proposal. We’re able to custom tailor everything yet remain feasible. Do we suggest areas of improvement that will exceed the budget? Sometimes. Do we explain that certain items cannot be designed or built due to budgetary restrictions? Definitely. Does the budget submitted on the form always equal the cost of the project at the end of the day? No. Through the inquiry process the budget may adjust to the requirements of the project, and clients are open to that when they have some context.
[Tweet “Serving clients is more than profit sharing”]
Of course budgets are not set in stone, but that doesn’t mean it shouldn’t be discussed for fear of limitation. Inquiring about having a website built is an intimidating concept, especially websites that cost tens or hundreds of thousands of dollars. Clients are putting up their hard-earned money to get something in return and talking about it can be nerve racking, but we feel that the benefits far outweigh a few moments of (what doesn’t need to be) awkward. Value-based pricing would say that we leave money on the table, but we are here to provide a service to our clients not a profit sharing relationship.
My opinion is terrible, trust yours
We’ve heard time and time again that no one knows what they’re doing, that we’re all winging it every day when it comes to business. That’s true. We’re also told that when we talk about business we should speak with confidence, with experience. That’s also true. No one knows what they’re doing yet we speak as though we do. I feel that although the general idea of that is an oxymoron, there’s still truth to it. I’m doing it right now. I feel that even though we’re all doing much of the same things (even those of us in client services doing what many would consider the exact same job in the same way) there are so many nuances to the implementation and execution of our processes, the outcome is vastly different.
I think that even though I may disagree with two points made in two different podcasts that we can all agree that wasted time is bad, that we should minimize our efforts and maximize our returns by working smarter. As one of the podcast hosts outlined: that means saying no way more than you say yes. I fully agree with that, and I fully agree with custom-tailoring as much of your process as you can to that end. At Iron to Iron we’ve found that building an inquiry form that reflects our working process and our client vetting process has done well to act as a tool, as something to help us not waste time going down rabbit trails of unfounded projects. There are too many great potential projects out there to spend time on inquiries that have no legs.
The participants in both podcasts fully stood behind their positions, that’s awesome. The only reason they were able to do that however was due to past experience. My opinion is also fully based on my direct experience and note taking from 10 years of client work. When you stand behind your decisions, when you know how well the process can work, when you can smell a terrible project from a mile away, it’s easy to fall into the trap of thinking “that’s the way everyone should do it!” but I caution that notion. It’s terribly easy for us to become blind to other ways of doing things. This doesn’t apply only to client services in the form of Web design & development, it can blanket everything we do. I want to encourage you to base your conclusions on trial, on error, on refinement; not someone else’s conclusion.
Podcasts, articles, books, classes, and other forms of learning are fantastic ways to level up. They’re a terrific way to shake off comfort in your own decisions, to challenge yourself. Don’t be easily swayed though, remember that we’re all just sitting down every day trying to make the best decisions we can, and that plays out in many different ways for many different reasons. Keep talking to others, keep encouraging their proclamations of what’s working or not working, we’re all better for it.