This really isnít a programming tip, but it is vital if you are a programmer. How you should talk to a client. I have learned this the hard way many times. And though all these tips may be good, USE YOUR JUDGEMENT! All clients are different; donít do something you believe will be bad.
Probably my worst, I donít know where I would be with out MS word. You will not be taken seriously unless you spell everything correctly and your grammar is good. Most people you work with are not English scholars, so perfect grammar isnít completely needed. Just make it the best you can.
2. Donít engage in small talk unless they start.
Business is business, personal talk is personal talk. They generally should be kept separate. It just seems odd to have your programmer ask you how your day is going. Though, if the client wants to have a quick chat, do so if you have time. If you donít have time or donít want to, politely inform them you have work to do.
3. Donít over-mention payment.
The price of the item you are working on was agreed upon when you started. The fact that you will be paid is implied. Try to stay away form mentioning it or it will give the client the impression you only care about the money. When the end comes and it is time to ask for payment, donít use phrases like ďPlease pay meĒ or ďPlease send me my moneyĒ. Better to use ďPlease send funds to [place]. I will send you the files as soon as receive themĒ. It sounds less focused on the money and changes the focus to giving the client his files asap. Leaving a good last impression can mean a return client.
4. Donít play the blame game.
It is not uncommon for a client to misinterpret what you say. When it was harmless I apologized for not being clear and continued. Was I unclear? I donít think so, but to quickly resolve the harmless conflict I took it and went on. When the misunderstanding is of some significance, it becomes purely circumstantial. Donít take the blame for what isnít your mistake, but donít blame them for your mistake. More not taking the blame for what isnít your fault later.
5. Donít use too many large words or complicated sentences.
Not to call clients stupid, but coming at your client with a barrage of large words that are sure to send them to dictionary.com is a bad idea. They will instantly take it as you trying to manipulate them into something. Or they will just think you are an idiot compensating with large words. For instance, you would not want to message them
Salutations appreciated consumer of extravagant commodities. It is with the greatest regrets I am obligated to inform you that I am endeavoring to abstract a remaining delinquency in the application so I may discharge it. I require additional portions of time for the acquisition of the location of this problem. I will not misappropriate any additional authorized time; rather I will use to improve this product in a substantial way. I am prepared to compensate additional authorized time with the building of a component of miniscule to intermediate voluminosity for free or a significantly reduced price.
ďHello, Iím afraid I need another day to remove a bug. I know this would be going passed the deadline, could I offer you an additional component for free or highly reduced price?Ē
6. Speak to them according to their tech knowledge.
Different clients have different knowledge of how programming works. Some of my clients are less experienced programmers and want to know how I am building it. Others donít even know what a database is. Generally, donít tell them the inner workings of the program unless they want to know. They hired you to make a good program, they should trust you. You arenít a teacher, if they donít know how anything works; politely inform them you donít have the time to explain it. If they know what they are doing and want some insight into the program, just tell them.
Off of the polite tips, here are some tips for realistic communication in the event that blind politeness with get you ripped off.
7. Donít take the blame for what you didnít do.
If you make a mistake, take the blame for it. But if the client misread something that was clearly his mistake, it is his fault. If it has no impact on anything, just take the blame to avoid conflict. But if it affects something (another feature, something works different, ect), politely inform them the error is on their part and you cannot fix it for free. This is purely circumstantial, there is no formula to say if it is your fault or not. Decide objectively and fairly. Also include a clause in your policies that leave you as the decider of where things go in lack of detail.
8. Be as assertive as you have to, when you have to. But not more.
If a client is doing something that is wrong, inform them of that. I had a client some time ago that wanted something that he simply didnít specify earlier. He was insisting it was implied; I eventually had to reply ďNo offense intended, but a reasonable person would not expect that to be implied. Since it was not clearly specified, I will not program that feature for free.Ē He was mad, but the project worked out and he did return later for more work.
Excellent article in regards to proper communication etiquette when working with clients.
I'd just like to comment on certain points you've brought up, since I go through this daily as a Consultant.
1. Grammar / 5. Large Words and Complicated Sentences:
Grammar, word choice, and overall presentation of information you're trying to convey to your client, is the stepping stone into an established client to programmer relationship. Without taking thought of what you're saying, how the client would view what's been said, or not having the professional sense of grammatically correct structure, any potential clients wouldn't see the value of having you work on their project.
2. Engagement in personal talk:
In reality, there's nothing wrong with engaging in personal talk. Keeping client interest, showing that you actually care to possibly get to know the client for future endeavors, and general personality, helps keep the above stated client to programmer relationship.
3. Payment mentions:
Agreed. The more you talk about "I need my money soon," "Where's my payment," and so on, the more your relationship with the client will spread apart. Knowing that you're only in it for the money, they'll have second thoughts on whether or not you're focused on the actual project requirements. As he stated, other ways to convey that you haven't been paid yet, are much more understanable and professional.
4. Blame game:
The "blame game" is easy to slip into. One mistake, one flaw, or one comment, could cause you a whole works load to fall out of place. If not handled correctly, future contract work will be difficult to recieve, as the client would most likely spread poor reviews, that you don't admit certain problems that were your fault.
6. Speaking in a less technical manner:
Depending on the client, and what you know about the client, you wouldn't have the faintest idea of whether they were technically knowledgeable or not. It's perfectly fine to discuss some key parts of what you've done in a technical manner, but if you do so, indicate to the client that if they have any questions you'd be willing to answer them if you have time, or you would point them in the correct direction for a suitable understanding of the certain term used.
Again, your article was one of a kind, and if all today's programmers would actually tune into what you've discussed, there would be less drama.