Highlights
00:32 – Managing Several Client Requests
02:56 – Distributing Hours for Cloud Development
04:36 – Handling Delays In Client Feedback
06:56 – Charging Clients and Pre-Establishing Payment Calendar
10:55 – Working With Local vs International Clients
Transcript
Hey guys, it’s Mario Peshev here. I’d like to share some thoughts based on questions in my mentorship group. Essentially we do have a bunch of people who have signed up for my group available at devwp.eu. (now https://advice.mariopeshev.com/) And asking various questions about WordPress, freelancing, running a business, lead generation, so forth.
One of the folks has asked a bunch of nice questions related to the way that we do business at DevriX, and asking for some advice for consulting freelance and running other forms of business as well, in terms of selling services.
Managing Several Client Requests
So with that in mind, the first question is how do you manage several client requests in a specific timeframe? This is a valid question and a lot of people do have problems with that. Now, it’s complicated when you get to fixed-fee projects with specific time frames that don’t really get executed at the end. Let me put it this way: essentially, there’s a lot of back and forth. They’re dragging projects down.
There are some delays that are caused by waiting for assets and things like that with one-off projects, especially the smaller ones. For those projects, we have established a process where we can get 100% for all requirements and all dependencies upfront so that we don’t have to wait for the client at the end. Sometimes there may be a thing or two that are having to wait on or so forth, but that’s usually not the case.
Additionally, we do have a lot of clauses in our contracts that state what’s the acceptable response time for customers, and how soon do we have to go through iterations and through milestones and so on in order to avoid those kinds of delays.
Even if customers do have a specific reason for a delay, we usually have some clauses that let us expand the project or charge an additional fee for these changes and whatnot, simply because we cannot afford to drag them for too long.
Moreover, our main business model revolves around WordPress retainers. So we do have retainers from 30 hours a month up to 150 hours a month, usually dealing with back end development, front end development, some creative, every now and then some dev ops, system administration, even marketing, and business development.
How do you manage several client requests in a specific timeframe?
Click To Tweet
But through these retainers, we can actually afford to work on specific projects with an allocated amount of time every single month. So this kind of lets us establish a ballpark of hours that we have to invest on a monthly basis and say, “Okay, we have, for example, 600 hours every month that we have to invest. We have that amount of manpower, so this is how we are going to distribute our resources.”
Again, it’s worth noting that our retainers do provide different types of services, which means that different people may be working on the same project different months depending on their requirements. And we also get specific feature requests every single month depending on what the customer really needs.
Distributing Hours for Cloud Development
The second question is how do you distribute hours for cloud development through the workday? And that’s also a great one. We do try to keep the focus of our developers in one place.
This means that we don’t want them to work on 50 projects at the same time. But simultaneously, with that in mind, we do have specific projects that really require a certain set of expertise and we do charge them 30 or 40 or 60 hours a month.
So if you do the math, 30 hours a month is roughly one day a week, or four days a month or whatever it is. And the 60-hour retainer again is just two days a week. But having that math in place doesn’t necessarily mean that one person can have a specific day allocated because sometimes there’s maintenance. Sometimes there are specific features that need to be done the next day or the day after, or so forth.
Sometimes the work has to be implemented by different people, which means a back end developer, a designer, a QA going through all this, a front end developer applying those, a marketing person helping with the copy and so forth. So in practice, we do have people working on average two projects a day.
Sometimes it’s only one, sometimes it’s a little bit more, especially if they’re minor fixes or front end issues, or something else that could be fixed easily right away without too many distractions and without the need for too much context. So essentially working this way also lets us allocate resources in cases of emergency or in case something else needs to be handled as well.
Handling Delays In Client Feedback
The third question is how do you manage client feedback delay? Now client feedback may be interpreted in two different ways. The first one is you not being able to comply with sending feedback to a client early enough.
The second one is essentially waiting for the client to respond in a long amount of time, in a matter of weeks or a month. So the first case shouldn’t happen that often. Simply because you have to be responsive and you have to reply to all of your clients and so forth.
We do try to respond to every single request or email over the course of 24 hours, or one business day in case we are talking about weekends. Most of the time it’s in a matter of few hours, but we do try to have some visibility and some transparency and also have internal conversations with the team sometimes before getting back to the customer.
But other than that when we are waiting for feedback from the client, again, there are two different cases that we discuss. The first one is the one-off projects, the single time product and so on. For those projects, we do have clauses in the contract.
For example, customers should respond in three days or five days, taking a look and reviewing a specific milestone. And we don’t really let them take a longer amount of time simply because it’s postponing our projects. And again, this is set in our contract, and it’s there for a reason.
The second case is with our retainers, so with them usually we do try to, again, solve all of our clients’ problems within the number of hours that we do have allocated per month, which also includes emergencies, maintenance, specific fixes or something else that needs taking care of.
Moreover, we do have a list of features and ideas and improvements and whatnot that we have put in specific labels in our project management system. We do have feedback, we do have good ideas for the future, we do have icebox for features that have been started but we haven’t really gone through them.
And we also do have a bunch of other activities such as maintenance, refactoring, cleaning technical debt, performance optimization, security reviews and so on that we can invest every single month. This helps us fill out the buffers and at the same time provide additional quality for our customers.
Charging Clients and Pre-Establishing Payment Calendar
The fourth question is how do you charge clients after, before, during development or pre-establish payment calendar before starting work? As I said, the vast majority of our work is essentially retainers, and that’s what we believe in. We do believe in agile development. We do believe that the project changes multiple times across its development and implementation cycle.
With that in mind, we can’t really work on large projects with a lot of features and expect the end result to be exactly what the client imagined with every single feature that they asked for. That doesn’t really work in practice. We’ve had several of those projects and almost exclusively they have at least doubled the number of features or changes that they want to get implemented after the delivery. And it’s all out of scope. It’s not the fixes.
It’s not, ““`this isn’t working or something.” It’s, “Hey, I wanted the project to also do this.” Or, “It would be great if it does this.” Or, “Our competitors do have this feature now. What should we do?” And it’s all out of scope. It’s all scope creep. It’s all additional features.
And we’ve actually had some clients that came with us with a $15,000 project which turned out to be a $50,000 project at the end simply because they thought about so many other features that are missing. And the moment they had a chance to play with the product, to test it out, to check specific features, it became apparent that it simply needs more work that hadn’t been planned upfront.
This is something that we prevent by working on WordPress retainers and agile, simply because on a month by month we have iterations, we have progress. We work toward MVPs, minimum viable products, something that has the core essential feature for the product without having all of the other bells and whistles, right?
So this is really helping us out with charging clients simply because we do have monthly installments and monthly payments that occur, again, on the first of the month or middle of the month or so on. For fixed-fee projects. It really depends because we don’t do many of these, but when we do, we usually have something like 30% upfront, 40% somewhere after a major milestone, and the remaining 30% before the delivery.
Before handing off the code base, before deploying everything on a customer server, that’s what we usually do. Again, it may depend on different cases, but we do think it’s fair, and we do want to get the incentive to actually work with the client even if we have a contract without having to stalk them and ask for what we claim is ours.
Additionally, when it’s broken down into specific payment installments, be three or four different sections, it helps you get some bootstrap budget, which gets your client committed to working with you. Because essentially your client may be working with five or 10 freelancers at a time.
In fact, we have done it ourselves. Back in the day when we were outsourcing some R&D features, we were hiring at least three or four freelancers for the same job, simply because we weren’t sure of the quality. Now we had paid all of those freelancers, but again you know that some clients are not really feeling this way and so forth, which is why getting an upfront payment is fine.
Receiving the last payment right before the actual deployment to production and handing over the code base is also fine. Again, it’s simply a showcase of your work, everything that you have done for the client. And you say, “I’m done here. I have everything. You had the chance to test it, yada yada.”
So simply let’s finalize the payment before just shipping everything to your hosting account. Right? And then in the middle, you may have one or two different payment iterations for different milestones that you may want to deliver.
Working With Local vs International Clients
And the fifth question is, should you emphasize on your location country or is it better to aim for a more global service? Now, I assume that the question actually states: Should you focus on your own country, and should you say that you are living in a specific country? Or you would rather sell something internationally?
Now, ideally working with local clients is great, right? You have the opportunity to have meetings. You can actually exchange ideas, speak in your local language, understand the local culture, and pretty much everything else in the local business and economical environment.
Depending on the type of services that you offer, and on the type of economical environment that you have locally, you can decide what works best and what doesn’t.
Click To Tweet
Because again, selling digital goods online in the States and in Nigeria are two different things. Selling clothes in Bulgaria, in Pakistan or Bangladesh, and in Russia, it works in a completely different manner. And I say that as someone who has seen different ways of working in different cultures.
So working with local clients is great and it’s something that may help you out as well. Now the problem is in certain cases you may not find the best clients for your type of services or your business on a local level. It may be too expensive, it may be something that doesn’t have a lot of demand on the local level, or you may profile in a specific niche or in a specific type of services that, again, are not that needed on a local level.
For example, our headquarters are in Bulgaria. We do have people in seven different countries or so, but the vast majority of our clients are in the States. Or we also do have clients in Switzerland, in the UK, Netherlands, India, Thailand, and other countries as well. Right?
But the types of services that we offer are not something that the Bulgarian market needs. Simply because we scale large websites, and we build high scale platforms. Some of our customers do serve 15 million page views a month or 20 million page views a month and so on. And that’s not the amount of traffic that most websites locally get.
So that type of expertise requires us to work on a global level because there aren’t many service providers specializing in profiling and performance or security. And at the same time, there aren’t many clients who want that on a local level. So again, depending on the type of services that you offer, depending on the type of economical environment that you have locally and so forth, you can decide what works best and what doesn’t.
So again, thanks for the questions. I’m going to post that video on YouTube and to my mentorship group. And if you do have any other questions, don’t hesitate to reach out. Send me an email and also follow me on Quora.
The post WordPress Sales and Project Management Advice appeared first on Business Advisor.