Project Management

Post-close requests from clients: When is enough too much?

Read advice on how many hours you should eat on clients' post-final invoice tasks, and how to avoid these requests in the first place.

I received a request a couple weeks ago to convert a batch of mock-ups my client had already signed off on to the PDF format, so that its Dev team could more easily port marketing page copy into their page-coding project.

Due to some versioning issues on my end, the chore took about an hour. No big deal. You always want to keep your client happy, and in addition to being a promising customer, my contact also happens to be a long-time professional associate and a good friend. So, I knocked out the little request with no thought of an extra billing for the time. Obviously, it was the thing to do.

However, the situation got me thinking: How much time on post-final invoice tasks like this can you afford to absorb before you must let your client know that you need to bill them for your troubles?

It's a little trickier than simply putting in a change order; theoretically, the project is closed. You've got sign off, and you've sent your last invoice. Most Accounting departments get a little irritable over invoices for a couple hours work, and even more irritable for additional billing for a line they think should be closed. So, that argues for just eating a few hours here and there, assuming you want to hold onto the client.

On the other hand, a few hours here and there can quickly mount to a sizeable chunk of lost billables. And once you give in a couple times, it's like you've fed a stray cat - the requests keep on coming. It's not just a question of a few bucks. Hopefully, you've moved on to a new project and have something better to do than re-wrangle a few details you thought (and been assured by your client) were already locked down.

I've found this phenomenon is most common if you are working on a component of an overall project that then gets passed on to another consultant or client team. As a VP of product development, I used to torment our outsourced design shop with after-close requests for color changes and other nominal tweaks. I thought the SOW was closed; my consultant thought the SOW was closed. But some new voice in the project (often C-level) suddenly sprouted a passion for "hot" colors, so back to the design shop I went. Often.

So, how many hours should you eat on these little requests, and how can you avoid them in the first place?

My rule of thumb is that if you are billing more than 40 hours on a project, you should build in at least an hour (on you, most likely) for a detailed close meeting before sending that final invoice. Although you can't envision every quirky request a client might make, take the lead in anticipating weird little afterthoughts that might not have been covered. Experience will be your guide here.

After the close meeting, be ready to eat about three hours max of trickle-in requests gratis before you tell the client that you will need to open a new billing cycle for the effort. If your team has delivered a 300-hour soup-to-nuts solution, this hour count will vary. And you should already have built a shake-out and maintenance schedule into your agreement that, hopefully, will cover any unexpected events without raising Accounting's ire.

But regardless of project size, you can't let small "favor" requests continue to drag on forever. Because they will.


Ken Hardin is a freelance writer and business analyst with more than two decades in technology media and product development. Before founding his own consultancy, Clarity Answers LLC, Ken was a member of the start-up team and an executive with TechRe...


If you work in a manufacturing plant on the line, would you be willing to go in and spend "just a few more hours" without pay to keep a job, or would your employer even expect it? If you value your "extra" time at zero, you send one of or all of these or similar messages to your client: 1) "I billed you too much for the job so I feel guilty enough to give you my time for free." 2) "I don't think my project was worth what I charged so here's some make up for free." 3) "I don't have anything else to do so why not." Your client then begins to think that this is the norm, finish the job then keep on getting free information and time. When the final billing has been rendered, keep a follow up project open and bill for anything that requires your time. This is unless you really did bill too much, provide a sub par service, ory want to provide free services on every job.


A proposed solution in the article is to do a project close meeting prior to sending the final invoice. These meetings are often necessary for other reasons in order to obtain project closure in the first place, however if the customer is already expecting to receive and pay the invoice then fort $(* sakes don't slot in an opportunity for all kinds of real and perceived 'show-stoppers' to come up especially if that meeting may contain additional people on the customer side who weren't previously closely involved in the project. Getting paid on time is the far bigger issue here: yes, the customer's accounting department could get irked by a small bill here and there for some ad-hoc post-close service. But that's nothing compared to how irked MY accounting department and senior management gets for not getting paid on time. ;) So by all means do a 'post closure' meeting in which also new requests, new phases and new projects can be discussed in addition to reviewing or proposing a maintenance agreement that includes X hours of effort which also covers post-close requests, but have this AFTER getting paid. ;)


"My rule of thumb is that if you are billing more than 40 hours on a project..." My metric is 20-30% (obviously depending on the client). Some clients are very fair, some are complete gits and keep pushing until you say "no more". There's no easy solution to this because it depends so much on the personality of who's pushing the extra work. Some people see it as a dominance game and the ONLY outcome they're prepared to accept is capitulation.

Editor's Picks