We had them export to pdf, then imported them. Our system stored pdf objects for display. Since it was a migration, backwards compatibility was irrelevant.
Another was version control for bom/assembly processes. They wanted a visual tool for showing the differences. Sort of like a diff tool, but all the files were shown instead of just two at a time. Also, who made the changes.
As an engineer currently migrating decades old paper records to an entry level ERP, this would be an amazing killer feature that would blow my non-engineer co-workers away.
Basic version control on product data without shelling out for a massive overkill PDM/ERP/CAD integration would make me pant with hot joy.
ERP features that always amaze: kit demand; click a button, get a colored report with charts; click a button, see who and when changes were made to a part/order/entry.
Answering the phone when it rings. Not so much old clients, but new clients are consistently impressed with this. A lot of our competitors don't answer and some don't even have voice mail.
I like this one. I'm a bit biased because I run a customer service business so that's a big deal for us, but even I am impressed when someone just picks up.
I'll add one here from my own business, which is customer care outsourcing. The outbound call. Basically it comes with the territory when things go wrong. But when you call the customer before they realize things have gone wrong they are always, always grateful and impressed. Same thing goes for a "just checking in to see you are enjoying the service" call. Since we have agents sitting around all the time anyway this is time that can be used to call up customers and impress them.
Yep. we do this too. Whenever we develop a web service for a customer, we set up uptime monitoring on the server where the app is hosted, but I also set up ping uptime checks on most of their other server infrastructure as well.
Just last week, I was alerted at 5am that a client's email server had gone offline. Nothing to do with us, we don't look after their emails at all, but I immediately texted their IT guy to let him know.
He texted me back at 6am - their own uptime monitors somehow failed to detect the DNS issue. He managed to fix it before their staff got to work that morning, and was extremely grateful that I had given him advanced heads up on something that was totally outside the scope of what they had engaged us for.
Context: We've worked with this client for 10+ years, I know their IT team really well. They are not a super huge organisation, and we are a tiny (read: 3 man) operation too, so the reliance on each other's services is something we consider important to keep everything moving forward.
I used to work for Rollbar and their "person tracking" feature really super powered this. I was a customer of Rollbar before I worked there, and would regularly catch and fix bugs for our clients before someone had the chance to notify us about it.
A lot of the time, when a client has a request, they are thinking out loud in the moment.
Even if I can't pick up the phone, I'll send a short email straight away to let them know that
1. I got the message
2. Timeframe when I can action
These are a few things that have gotten me praise over the years:
1) Keep emails short. I set a 200 word max on all emails. If you can't say what you need to say in 200 words, schedule a meeting to discuss. If you have to send long documents, send a 2-3 sentence summary. Tell them what you're going to tell them, tell them, tell them what you told them... in 200 words. (=
2) Keep detailed time records and make them available to the client on-demand. They paid for it, might as well show them what they are getting. Be honest... if your team wasted 4 hours trying to make sense of a BS email from the client... make sure they understand that.
3) Being on time and inclusive; inviting them to daily standup meetings with the team, and posting notes from those standup meetings in case they (or anyone else) can't be there. Easy with a Google Sheet to just type a few notes each day during standup. I don't have any tools for the team that the client can't access, or hasn't been given a rundown on how we utilize it.
Lower their prices, without prompting. At Flexport we sell logistics services. The price of ocean freight is highly variable (less dynamic than, say, the stock market or airline seats, but still fluctuates a ton). We make money by brokering these services. In some cases, the price of freight drops in the time between customers when contract us (and agree to a price) and the service gets executed (when we contract with the asset owner). We pass those savings on to the customer and let them know. This usually results in big joy, all around.
Depends on the situation. Our rates have expiration dates attached to them, so if the price went up before our negotiated rate expired, we will eat it. If the rates expired, we leave it to the judgment of their account manager on what to do.
just out of curiosity - the value that your customers see...is it actual cost + your fee? (hence you can collect the fee even if the actual cost reduces?)
Here's an internal facing one: We send an automated greeting from the CEO as part of onboarding, but he actually sees and replies to every customer response, in both english and spanish, and forwards the more heartwarming ones on to the entire office.
It's pretty cool to get a handful of emails every day from actual customers who are very grateful for the work we do.
It also changed my opinion on the "canned CEO greeting". As someone who knows how those are built, they always struck me as annoying and disingenuous sales gimmicks, but our customers are significantly less tech savvy, and a huge number take the correspondence at face value and actually start a real conversation with the CEO.
I generally respond rather negatively to automated emails or chat messages that seem human but are not, and I've been thinking of how I would approach this if I had a company big enough that automatic greetings are 'necessary' (or desirable, at least).
Perhaps one solution is to use a clearly non-human company 'avatar' character specifically for some of these interactions? A robot or pet character?
I did the same for new account registrations on my site. The humorous side effect was actually LinkedIn. That whole thing where you can auto invite everyone on your contact list... led to me getting several connection invites a day from users I had never personally met.
Tell them the truth, even if it means fewer projects/billable hours for me.
Every single lead I've talked out of working with me, has referred me to another customer and/or came back weeks-years later with a bigger project that did make sense to pursue.
i would say about half of the leads i talk into trying someone else send a referral, but that isn't why i do it. Our field is so large. It's important to not get distracted. Of course, this assumes you have a plan.
I never disagree with a client. Even if I internally feel it won't work in reality, I always start my response with "That's an excellent idea you proposed, let me try if it works and get back to you". I come back after a day or two as to why the proposal won't work (if it was a bad idea to begin with) with sufficient data. Client is happy you that you considered his proposal and you've avoided a potential standoff that could've existed for the same duration !
Depending on the context in which you do this, you've also just wasted 2 days of billable time.
If you know it won't work from the start, you're not providing value to your customer by fake considering it.
You assume that your customer values things like you do. If the customer is happy he'll feel better; the fact that is happiness is economically viable is an entirely different matter.
Interesting. We usually say that a good consultant should be senior enough to stand up to the customer and at least be able to inquire the basis for something. And also disagree when the customer is clearly wrong. But your way of doing it clearly removes the initial head-on.
One could always reason about things. But to promise to investigate (and then deliver) looks (and is) professional.
But I will never say yes when a customer suggests to "encrypt dsta using the cipher md5". Yes it has happened. More than once.
Consultant: "I will investigate the feasibility of this."
... two days pass ...
Consultant: "I have considered your proposal. I believe we should encrypt your data with SHA-256. md5 is insecure, here's several references. SHA-256 is much more secure and more popular. It is a NIST standard, and just as cheap."
Client: (probably) "OK, if it costs the same and is more secure, sounds good to us."
I once saw that particular confusion in a security audit report that a company was using as part of their sales materials.
I did flag it up as indicating that there might be something a bit fishy about the security audit if they made such an elementary error but I suspect the CEO (multi billion pound company) had already made the decision so what I thought was irrelevant :-)
This might be "fix my plumbing with a wrench", you can't, you also need a replacement pipe, but that wan't what was meant, more like "utilise a wrench in the fixing of my plumbing"...
Actually you can use a cryptographic hash function such as SHA-256 (or MD5, but lets not go there) as the core of a stream cipher. Basically stick a seed (key) combined with a counter as input to the hash functiom. Use the output as the keystream. Stream ciphers such as ChaCha are basically block based PRFs that operates like this.
Of course the performance would be silly compared to dedicated functions. ChaCha20 has less than a third the number of iterations compared to SHA-256. And each iteration is much faster.
Ignoring the encryption/hashing problem, what happens if your client is moderately technical and also researches the problem, and finds the same answer in 5 minutes? You look like you're incredibly slow (or over-billing) if it takes you two days to come back.
I think that, often, there's confusion between someone's position and their interest.[0] It's easy to think that if they asked for "MD5", they must want "MD5", right?..
An easy illustration of this is someone with a runny nose asking you for a "Kleenex". You have tissues of another brand, so you tell them you don't have a Kleenex. This is being an asshole who hasn't done any Physics but watches too much Big Bang Theory and wants to be "like logical/analytic". That kind of stuff is only cool when Paul Dirac does it, whom the asshole knows nothing of. Of course we laugh because "nobody" would act like that..
"MD5" is "Kleenex". The runny nose is their concern for security. "Tissue" is "something to clean that runny nose.. or shine their shoes". They might want the tissue to do something else than clean their nose, because they have a handkerchief for that.. So our assumption they want to use it to clear their nose is wrong.
If their only options are "no password-hashing" and "that crypto thingy, what was it? DM5, MD5 or something?", choosing MD5 is actually a sane decision and request.
The underlying interest here is "security", communicated with a request for "MD5" (position) which makes them seem clueless to someone with a broader view and who must, in my opinion, recognize their request for what it is.
One could ask for the specific reason they chose MD5 and not something else? They may be unaware of other options, or give constraints they were trying to satisfy with that choice.
Someone who says the site must be in PHP might mean they want a "dynamic site". Someone who specifies "Bootstrap" might mean "responsive", etc.
We clear assumptions by asking questions, and noses by blowing them.
Exactly. To me a senior consultant should be able to spot the obvious error and then focus on trying to understand what the customer need and move the solution to something that meets the intent.
If it is confidentiality the customer need, provide good solutions to that. But check if confidentiality is really the thing needed. Quite probably, authentication and integrity protection is what is really needed. So AES in CTR mode might not be what the customer should want instead of MD5, but possibly AES-GCM, AES-CMAC or even a Ed25519 signature mechanism using public key.
In the events that this have happened I have directly, as diplomatically as I can be, explained that (1) MD5 is not a cipher, but a hash function that does not provide confidentiality. And (2) It is not a hash function one should use . Ever. Never. In a million years. Or more.
And at this stage start to enquire what security the customer think their system/product/service needs and try to move forward from that point. And we usually also talk about MD5 and its brokenness. Than if a secure hash function is needed, there are several good ones to choose from. And if they really don't need a secure hash function, there are others, much faster hash functions to use.
The point is that sometimes things need to be handled directly and up front. This for me is one of those things.
I was just thinking about this an hour ago. I work in more of a visual design field, but the issue of customers "being wrong" seems pretty universal.
There's a sentiment that, if you hire an expert, you should do what they tell you to do - why hire them in the first place if you don't trust them - and that's valid in some ways. Still, if an expert can't communicate to their clients why they think an approach is good or bad, it seems to me something's very wrong with the process.
> We usually say that a good consultant should be senior enough to stand up to the customer and at least be able to inquire the basis for something.
Totally, but there are good and bad responses. I usually go with something like, "It seems we're not capturing or making some important information available, so can you describe the core problem that your suggestion solves so we can better understand how to implement it?" Usually a better solution arises from the ensuing back and forth.
Everyone solves problems by drawing on their domain of knowledge, and customers' knowledge is simply more limited than a software developers' when it comes to computing. The software developers' domain knowledge is much more limited when it comes to the customers' business though, so some humility on both sides is warranted.
That might be better than what I do. I disagree, perhaps not often, but there are bits of functionality that I think just aren't justifiable/cost-effective. So I try and dissuade them. Although sometimes I might be a bit too vocal. That said, I do try and say that, at the end of the day they can definitely just say "shush... Just build it" and I will. But I'm honestly trying to help them build the best product we can, as effectively as possible.
I'm not sure that this blows the client away tbh. I had much more success with being critical but within reason. If a client suggests a feature I do not believe will work or is not worth the time, my approach is to agree that this is technically possible and it will take X amount of time with Y drawbacks (e.g. harder to maintain in the future, manual effort later on). And then I'll tell them my opinion about it from a business perspective. I don't push in any direction and make it clear that if this is what they want, I'll get to work right away.
But then again, I only work with clients who appreciate feedback and don't think of me as a person turning coffee into code ;)
I'm with you. I view my clients as partners with whom I can speak openly--without sugarcoating, dumbing things down, or worrying about their feelings.
It may feel uncomfortable to say "no" or "that's a bad idea" to the person who's paying you, but in the long term it's better for the relationship. After all, they're paying you for your expertise, not to fulfill their every wish.
I caught my Macro professor doing this and it works wonders. It really encourages people to ask questions, even if they might think they are inane. He always started with a ~sincere~ "X, that is a really good question." It makes everyone feel really welcomed to give their input no matter how small. Even though it might not be "sincere" at all it still feel like it is. How would you feel if you asked a question in class and the professor said: "That's actually a really stupid question but I'll answer it anyway."
My biology lab instructor (she was a grad student at the time) started the first day of class saying "don't worry there are no dumb questions." About 30 minutes into the lab someone asked a fairly unintelligent question and the instructor goes "well that was a dumb question.." I think she learned her lesson after that though. You gotta start somewhere!
In my experience, the _stupid_ questions are the best ones, provided they are on topic. They hint at an edge case or something not covered deeply enough.
That's a classic. While working on the David, Michelangelo had the unwelcome visit of Piero Soderini (statesman, sponsor, etc) who suggested that the nose was too thick.
Michelangelo feigned reworking the nose and some say sprinkled a handful of marble dust to make the trick credible, then asked Soderini if he liked it now. He said it looked better.
So disingenuously humor the client for a day or two before shooting their idea. Honestly, if I was your client and this happened a few times, I would start to wonder why you lack the expertise to immediately know ideas won't work.
The client is not talking for the sake of talking.
They are expressing a desire, a need or a want
Almost always you can dig down to their motivation and get a better idea of what they are _really_ after, even if the clients proposed "solution" is technically impossible.
I'm not sure if you understood me. I don't think it's a good idea humor your clients. In fact, I think if could hurt you if they ever get wise to you bullshit.
If someone recognizes an impractical or suboptimal idea, I prefer it to be called out immediately for discussion so we can move past it to a better idea.
It helps if clients think like Darwin:
"I have steadily endeavored to keep my mind free so as to give up any hypothesis, however much beloved, as soon as the facts are shown to be opposed to it."
Anticipate their emergency procedures, and ship them a binder wrapped with dire warnings should it be removed from the data center. Multiple customers have said this has saved their bacon.
Emergency procedures for administrating the network gear. There's two sections: 1) symptom->fix procedures, and 2) how to rebuild everything in the network from scratch in case it got wiped.
The reason it's in hardcopy is because you can't look stuff up on the Internet if the Internet is down.
My business develops mobile apps for clients. They love when I analyze major announcements from Apple / Google and explain how the new features may apply to their apps. They feel they have a partner, and it typically results in new development for us.
One thing we did a few years ago when we found that a customer didn't use revision control was to bring in a server. A small PC with Linux, Subversion and Trac. We not only could explain the benefits of RCS, but the customer could see changes, att issues, get them resolved etc. When the job was done, the customer kept the machine.
I occasionally bump into old customers and many still run the same server. All of them are today using revision control systems.
So basically we didn't just provide a tech solution, but also brought in methodology and free tools to implement that methodology.
I run The Human Utility (formerly the Detroit Water Project) and we help folks with their water bills. When they reach us, they're used to dealing with other social service agencies that aren't very responsive and don't do something as basic as ever calling them back. We do and we find that people are grateful even for that.
Edit: People are happy to hear from us regardless of whether we actually help with their bills. If we say we can't, at least they know to try elsewhere and can do so fairly quickly.
I have to +1 this. Whilst I have never specifically dealt with Human Utility. A couple of times when I had an inquiry or an issue, I have been offered to be called back later rather than wait and eventuall call back myself. Each time I appreciated the phone call.
Look at how many of the answers in this thread are simply about communicating effectively.
That mirrors my experience when I was on the service provider side, and as someone who is now consuming those same services, I can confirm that I am most impressed by my providers when the communications are focused, helpful and timely.
I discuss wit a client about some data they collect using an Excel form. Prototype quickly under one hour a small CRUD app based on Django and set Django Import-Export [0]
Get an easier Excel sheet containing data. They're gaga about that. I've won contracts just by showing them that they will get all the data in an Excel sheet.
When I did freelancing, I charged a bit more than I felt I should... but went above and beyond. My hourly rate may have been high, but I spent many "non-billable hours" making sure everything worked great and any changes (their fault or mine) were accounted for.
I did a few jobs where someone else controlled the billing, and kept us on a tight schedule. Every hour was billed. We were "fired" (AKA contract not renewed) every time. Yet when I went above and beyond, I had no problem getting and maintaining awesome clients.
As someone on the opposite side now (hiring freelancers), I've realized the thing I value most: the freelancer gives me less work, not more. It may seem obvious, but when I was on the other side, it wasn't. When I hire freelancers now, I value one overarching quality: to make my life easier. I don't care about price or hours (within reason), I care about not having to think about it.
I do bespoke personal support. I always solve their oddest problems. There's always a way, somehow. I'm available 24/7, for those 4am calls from Singapore. In return, they are very loyal.
Most of these seem to be very on the side of "I'm a company", so as a sole developer what I like to do for clients is implementing sockets into their apps.
Adding sockets for, say, the 3 newest logs they get in real time. Or if they have anything that maps to a graph/app-overview just make sure that will always update in real time. It's not a huge time investment for me. Customers usually never request it specifically. But I've found they are blown away when they see how everything is updated in real time. It just makes the whole thing feel 'alive'.
Another thing which I don't personally love, but I do because I understand industries have differences is just exporting whatever can be exported into .csv files or .xls files where applicable.
All in all, I work in consulting. The code I write is meant to make the life of people easier, I want to make sure they get that when possible. A big part of why I'm able to do this is that I have a lot of creative freedom to do whatever I want so long as I'm getting stuff shipped. So huzzah for comprehensive management as well!
> Another thing which I don't personally love, but I do because I understand industries have differences is just exporting whatever can be exported into .csv files or .xls files where applicable.
Working on an in-house application, this has been one of the most common types of requests. "Can we add this field here to the CSV export?" It's a three-minute task for me, but a huge time-saver for the manager of the team using the application and thus highly appreciated.
You can't stop it. If you don't have export then you will hear about your clients copying and pasting to Excel. Much better to add a csv export and high-res download button for all charts and graphs.
By the way, I've had lots of success with chart downloading by simply copying the svg element into a request to an svg to png converter.
It's also much more efficient for me as a developer to offer an export interface instead of having to implement all the reporting functionality myself.
quite nice yes, you always have to think people that will monitor statistics etc and how long it will take them to do so. If you can make their life a lot easier thats a + and of course they'll appreciate it.
Oh gosh yes. Companies love their CSV exports! I think the reason is that it lets them make glue - they can take data from something, play with it, analyse it, produce graphs, using tools they understand (almost invariably Excel), and sometimes then import into another system.
Yes, my employer's customers like their CSV imports too. If you're looking at a big data entry feature and they ask you how the interface works and you say "you give it a CSV file with these columns", they're happy.
But CSV isn't a mostly clean format. It's a collection of dozens of formats, some of them clean, some of them not, and with no way of labeling which one of the dozens you have in the file itself. Whereas XLS and XLSX, for all their binary cruft, are at least capable of unambiguously (AFAIK) representing, say, a string with a quote and a newline in it. (If there are encoding issues, well, same with CSV.)
I suspect you're thinking of something like "CSV as outputted by Excel with the default settings", which may be clean and unambiguous, but is far from the only CSV in the world.
For that reason (and I'm just saying this generally, not targeted at the comment I'm replying to), always use the most mature CSV output library you can find for your stack. Never write your own CSV export code by bashing strings together unless you have no other choice because you're working in some stack that doesn't have or can't use existing CSV libraries.
(You can ignore the RFC for CSV too; it's not "wrong", it's just one particular flavor that was declared long after the horses had left the barn, learned to form a horse civilization, discovered the atom bomb and bombed themselves back to being plain horses again. It barely rises to the level of being "advisory" in practice.)
XLS and XLSX are neither clear nor unambiguous and I would take 12 CSV formats over either any day. I actually haven't ever met anyone who seriously had to extract data from XLS/X frequently that didn't revile it for its ambiguities. Not to mention the ways that the application munges the user input prior to saving it, leaving the biggest ambiguity of all, what the heck is ACTUALLY in that cell.
EDIT: I will add that EXPORTING to XLS/X is usually quite straightforward and makes users happier than getting a CSV often times. Until they start wanting to get crazy with template design and then you get into Excel styling application and you're back to hating it all over again.
Actually, there are some commercial libraries that make working with even complex Excel spreadsheets pretty straightforward. I've used Aspose.Cells a lot and was very happy with it:
The single biggest problem is date / time formats.
Excel encodes dates and times as floating point numbers. The date / time-ness of a cell is encoded in its format. Some of the formats are hard-coded, some float depending on locale, and some use explicit format-pictures embedded in the styles.
But of course there's no guarantee that the user has formatted a cell with a date as a date. Sometimes the user has pasted a US-format date into a copy of Excel running in a UK locale, so dates that fit have day and month swapped, while dates that don't fit show up as strings. This is non-trivial to handle in the general case. I've had to add customer-specific workarounds for this case in particular.
Let me create a headache for you: there is no "CSV as created by Excel with the default settings". There are a lot of different ones for each language setting of Excel, and they are incompatible. So if you're going to work anywhere but the US or even have just some foreigners in the US as your users you're in for a total nightmare doing "Excel CSV"
The worst thing Microsoft ever did to Excel was even translating the formula functions in different languages. So SUM() isn't actually called SUM() in half of Europe...
Evil pro-tip : you can output a csv file and name it "foo.xls". Excel will open it fine, with just a click-thru complaint dialog that no one will read anyway.
For anyone using Ruby I'd recommend the (open-source) axlsx gem, I've had great results being able to treat Excel generation like I'm rendering a view.
tablib[0] is one option for Python. There are quite a few libraries that handle export. Excel files (and other Office) file formats are just zip files containing XML. For a while now, this has been an open standard[1].
Most reasonably popular languages will have platform-independent open source read-write libraries for Excel. I've used the Python version of this with minimal pain.
Newer versions of Excel will warn the user of possible file corruption if they try to open an .html file that has been renamed to .xls. The file can still be opened but the warning is bothersome.
I've used openpyxl a lot for these kinds of tasks, and found it really useful.
One nice feature with openpyxl is that it can work together with excel template files. So I can create a template in excel with whatever looks and features I want and then use openpyxl to populate those templates with data.
One useful trick is that you can rely on the headless version of LibreOffice to do the conversion, here on Mac for instance (but also work on Ubuntu with a slightly different call):
PHPExcel for, you guessed it, PHP. An order of magnitude less hassle than CSV ("the files you generate are wrong, but only on some computers! Fixitfixitfixit!!!"), and surprisingly powerful.
Depends on the amount of data, calculations, and formatting. For "output this array of arrays as XLSX instead of CSV", I find its current performance acceptable.
I'm thinking about starting a consulting company next year. I've been in an engineering role for over 10 years, but I really want to move into a role where I'm not selling my time in exchange for code, but rather selling the value my code creates.
I'm curious how you got your first few "gigs". What should the sales process actually look like? Did you cold call, or did you have enough established relationships first? How do you typically agree on a contract, has the customer come to you with needs, or did you ask them for problems first and propose some solutions, and they agreed to them?
The first gig came to me. The second was a result of the first. And it goes on from there. If you network then someone will approach you to help them with some code. Do a great job and the second will start. After you do a few, then worry about sales and marketing.
Can you say a little-more about the "sockets"? How do you implement this? I'm not even sure exactly what you mean, do you have an example? It sounds like a fun feature to implement so I'd love to hear more. Thanks
Have a look into websockets. They are used to create an always open connection between the client and server. Meaning your application will not need to continually poll the server for updates.
For notification type stuff (i.e. predominantly one way, server > client) Server Sent Events/EventSource is IMO a simpler, more appropriate solution:
It works over regular HTTP and has a built in method to tell the server the last seen message (i.e. to allow replaying old messages), and exposes the event type (i.e. the event: field in the event block sent from the server) for use with addEventListener in the browser.
It's supported by all non-MS browsers, and because it works over regular HTTP, it can be polyfilled in IE/Edge using long polling XHR.
are you talking about websockets for web apps? It's not always easy to implement and it requires some extra libraries and deployment setups. Is it really that easy to add for you as giving client extra candy in post order?
Consistent updates(mostly daily) on email with screenshots and quick short screencasts. A lot of times a particular feature takes more than a day to complete and be pushed to some server for client to actually see what it looks like. But if I create in progress screenshots and videos from my dev machine it always impresses my clients.
287 comments
[ 2.8 ms ] story [ 255 ms ] threadBasic version control on product data without shelling out for a massive overkill PDM/ERP/CAD integration would make me pant with hot joy.
Just last week, I was alerted at 5am that a client's email server had gone offline. Nothing to do with us, we don't look after their emails at all, but I immediately texted their IT guy to let him know.
He texted me back at 6am - their own uptime monitors somehow failed to detect the DNS issue. He managed to fix it before their staff got to work that morning, and was extremely grateful that I had given him advanced heads up on something that was totally outside the scope of what they had engaged us for.
A lot of the time, when a client has a request, they are thinking out loud in the moment. Even if I can't pick up the phone, I'll send a short email straight away to let them know that
1. I got the message 2. Timeframe when I can action
1) Keep emails short. I set a 200 word max on all emails. If you can't say what you need to say in 200 words, schedule a meeting to discuss. If you have to send long documents, send a 2-3 sentence summary. Tell them what you're going to tell them, tell them, tell them what you told them... in 200 words. (=
2) Keep detailed time records and make them available to the client on-demand. They paid for it, might as well show them what they are getting. Be honest... if your team wasted 4 hours trying to make sense of a BS email from the client... make sure they understand that.
3) Being on time and inclusive; inviting them to daily standup meetings with the team, and posting notes from those standup meetings in case they (or anyone else) can't be there. Easy with a Google Sheet to just type a few notes each day during standup. I don't have any tools for the team that the client can't access, or hasn't been given a rundown on how we utilize it.
It's pretty cool to get a handful of emails every day from actual customers who are very grateful for the work we do.
It also changed my opinion on the "canned CEO greeting". As someone who knows how those are built, they always struck me as annoying and disingenuous sales gimmicks, but our customers are significantly less tech savvy, and a huge number take the correspondence at face value and actually start a real conversation with the CEO.
Perhaps one solution is to use a clearly non-human company 'avatar' character specifically for some of these interactions? A robot or pet character?
I've seen way too many companies implement this where any replies are actually just sent into normal support channels.
Maybe I am overly used to this; but customers are astonished seeing that kind of stuff...
Every single lead I've talked out of working with me, has referred me to another customer and/or came back weeks-years later with a bigger project that did make sense to pursue.
Choice quote: are you allergic to money?
And I don't think the parent comment suggested to fake work and bill for work not done.
We should always be honest.
One could always reason about things. But to promise to investigate (and then deliver) looks (and is) professional.
But I will never say yes when a customer suggests to "encrypt dsta using the cipher md5". Yes it has happened. More than once.
Client: "Encrypt our data using the md5 cipher."
Consultant: "I will investigate the feasibility of this."
... two days pass ...
Consultant: "I have considered your proposal. I believe we should encrypt your data with SHA-256. md5 is insecure, here's several references. SHA-256 is much more secure and more popular. It is a NIST standard, and just as cheap."
Client: (probably) "OK, if it costs the same and is more secure, sounds good to us."
I did flag it up as indicating that there might be something a bit fishy about the security audit if they made such an elementary error but I suspect the CEO (multi billion pound company) had already made the decision so what I thought was irrelevant :-)
Of course the performance would be silly compared to dedicated functions. ChaCha20 has less than a third the number of iterations compared to SHA-256. And each iteration is much faster.
Good thread: http://crypto.stackexchange.com/questions/48/is-it-feasible-...
Don't assume your client is an idiot.
An easy illustration of this is someone with a runny nose asking you for a "Kleenex". You have tissues of another brand, so you tell them you don't have a Kleenex. This is being an asshole who hasn't done any Physics but watches too much Big Bang Theory and wants to be "like logical/analytic". That kind of stuff is only cool when Paul Dirac does it, whom the asshole knows nothing of. Of course we laugh because "nobody" would act like that..
"MD5" is "Kleenex". The runny nose is their concern for security. "Tissue" is "something to clean that runny nose.. or shine their shoes". They might want the tissue to do something else than clean their nose, because they have a handkerchief for that.. So our assumption they want to use it to clear their nose is wrong.
If their only options are "no password-hashing" and "that crypto thingy, what was it? DM5, MD5 or something?", choosing MD5 is actually a sane decision and request.
The underlying interest here is "security", communicated with a request for "MD5" (position) which makes them seem clueless to someone with a broader view and who must, in my opinion, recognize their request for what it is.
One could ask for the specific reason they chose MD5 and not something else? They may be unaware of other options, or give constraints they were trying to satisfy with that choice.
Someone who says the site must be in PHP might mean they want a "dynamic site". Someone who specifies "Bootstrap" might mean "responsive", etc.
We clear assumptions by asking questions, and noses by blowing them.
[0]: http://web.mit.edu/negotiation/www/NBivsp.html
If it is confidentiality the customer need, provide good solutions to that. But check if confidentiality is really the thing needed. Quite probably, authentication and integrity protection is what is really needed. So AES in CTR mode might not be what the customer should want instead of MD5, but possibly AES-GCM, AES-CMAC or even a Ed25519 signature mechanism using public key.
And at this stage start to enquire what security the customer think their system/product/service needs and try to move forward from that point. And we usually also talk about MD5 and its brokenness. Than if a secure hash function is needed, there are several good ones to choose from. And if they really don't need a secure hash function, there are others, much faster hash functions to use.
The point is that sometimes things need to be handled directly and up front. This for me is one of those things.
There's a sentiment that, if you hire an expert, you should do what they tell you to do - why hire them in the first place if you don't trust them - and that's valid in some ways. Still, if an expert can't communicate to their clients why they think an approach is good or bad, it seems to me something's very wrong with the process.
Totally, but there are good and bad responses. I usually go with something like, "It seems we're not capturing or making some important information available, so can you describe the core problem that your suggestion solves so we can better understand how to implement it?" Usually a better solution arises from the ensuing back and forth.
Everyone solves problems by drawing on their domain of knowledge, and customers' knowledge is simply more limited than a software developers' when it comes to computing. The software developers' domain knowledge is much more limited when it comes to the customers' business though, so some humility on both sides is warranted.
But then again, I only work with clients who appreciate feedback and don't think of me as a person turning coffee into code ;)
It may feel uncomfortable to say "no" or "that's a bad idea" to the person who's paying you, but in the long term it's better for the relationship. After all, they're paying you for your expertise, not to fulfill their every wish.
Good job.
Michelangelo feigned reworking the nose and some say sprinkled a handful of marble dust to make the trick credible, then asked Soderini if he liked it now. He said it looked better.
They are expressing a desire, a need or a want
Almost always you can dig down to their motivation and get a better idea of what they are _really_ after, even if the clients proposed "solution" is technically impossible.
Your tone says something about your situation.
It helps if clients think like Darwin:
"I have steadily endeavored to keep my mind free so as to give up any hypothesis, however much beloved, as soon as the facts are shown to be opposed to it."
The reason it's in hardcopy is because you can't look stuff up on the Internet if the Internet is down.
I occasionally bump into old customers and many still run the same server. All of them are today using revision control systems.
So basically we didn't just provide a tech solution, but also brought in methodology and free tools to implement that methodology.
I hope and don't think so. Demanding them to use ClearCase, that would however been pure evil.
I run The Human Utility (formerly the Detroit Water Project) and we help folks with their water bills. When they reach us, they're used to dealing with other social service agencies that aren't very responsive and don't do something as basic as ever calling them back. We do and we find that people are grateful even for that.
Edit: People are happy to hear from us regardless of whether we actually help with their bills. If we say we can't, at least they know to try elsewhere and can do so fairly quickly.
Something so simple, yet great for customers!
That mirrors my experience when I was on the service provider side, and as someone who is now consuming those same services, I can confirm that I am most impressed by my providers when the communications are focused, helpful and timely.
spot on
Get an easier Excel sheet containing data. They're gaga about that. I've won contracts just by showing them that they will get all the data in an Excel sheet.
[0]: https://github.com/django-import-export/django-import-export
I did a few jobs where someone else controlled the billing, and kept us on a tight schedule. Every hour was billed. We were "fired" (AKA contract not renewed) every time. Yet when I went above and beyond, I had no problem getting and maintaining awesome clients.
As someone on the opposite side now (hiring freelancers), I've realized the thing I value most: the freelancer gives me less work, not more. It may seem obvious, but when I was on the other side, it wasn't. When I hire freelancers now, I value one overarching quality: to make my life easier. I don't care about price or hours (within reason), I care about not having to think about it.
Brilliant, thank you for your comment!
Worth remembering.
Sounds like I'm bragging - maybe I am.
Adding sockets for, say, the 3 newest logs they get in real time. Or if they have anything that maps to a graph/app-overview just make sure that will always update in real time. It's not a huge time investment for me. Customers usually never request it specifically. But I've found they are blown away when they see how everything is updated in real time. It just makes the whole thing feel 'alive'.
Another thing which I don't personally love, but I do because I understand industries have differences is just exporting whatever can be exported into .csv files or .xls files where applicable.
All in all, I work in consulting. The code I write is meant to make the life of people easier, I want to make sure they get that when possible. A big part of why I'm able to do this is that I have a lot of creative freedom to do whatever I want so long as I'm getting stuff shipped. So huzzah for comprehensive management as well!
Working on an in-house application, this has been one of the most common types of requests. "Can we add this field here to the CSV export?" It's a three-minute task for me, but a huge time-saver for the manager of the team using the application and thus highly appreciated.
By the way, I've had lots of success with chart downloading by simply copying the svg element into a request to an svg to png converter.
Personally, I do love whenever applications allow to export data and lack of such feature is IMO strong negative.
Yes, my employer's customers like their CSV imports too. If you're looking at a big data entry feature and they ask you how the interface works and you say "you give it a CSV file with these columns", they're happy.
Yet, most of the time customers insist on XLS export, and we are happy if they at least acccept XLSX instead.
I suspect you're thinking of something like "CSV as outputted by Excel with the default settings", which may be clean and unambiguous, but is far from the only CSV in the world.
For that reason (and I'm just saying this generally, not targeted at the comment I'm replying to), always use the most mature CSV output library you can find for your stack. Never write your own CSV export code by bashing strings together unless you have no other choice because you're working in some stack that doesn't have or can't use existing CSV libraries.
(You can ignore the RFC for CSV too; it's not "wrong", it's just one particular flavor that was declared long after the horses had left the barn, learned to form a horse civilization, discovered the atom bomb and bombed themselves back to being plain horses again. It barely rises to the level of being "advisory" in practice.)
EDIT: I will add that EXPORTING to XLS/X is usually quite straightforward and makes users happier than getting a CSV often times. Until they start wanting to get crazy with template design and then you get into Excel styling application and you're back to hating it all over again.
http://www.aspose.com/products/cells
[NB I have no connection with Aspose, just been a happy customer for many years].
Excel encodes dates and times as floating point numbers. The date / time-ness of a cell is encoded in its format. Some of the formats are hard-coded, some float depending on locale, and some use explicit format-pictures embedded in the styles.
But of course there's no guarantee that the user has formatted a cell with a date as a date. Sometimes the user has pasted a US-format date into a copy of Excel running in a UK locale, so dates that fit have day and month swapped, while dates that don't fit show up as strings. This is non-trivial to handle in the general case. I've had to add customer-specific workarounds for this case in particular.
You'd think when Microsoft came up with their new shiny file formats they'd actually make them new and shiny and good.
But nope.
The worst thing Microsoft ever did to Excel was even translating the formula functions in different languages. So SUM() isn't actually called SUM() in half of Europe...
[0] https://github.com/kennethreitz/tablib
[1] https://en.wikipedia.org/wiki/Office_Open_XML
[0]: http://xlsxwriter.readthedocs.io/ https://pypi.python.org/pypi/XlsxWriter
[1]: https://openpyxl.readthedocs.io/ https://pypi.python.org/pypi/openpyxl
One nice feature with openpyxl is that it can work together with excel template files. So I can create a template in excel with whatever looks and features I want and then use openpyxl to populate those templates with data.
A resource hog, though - had to close it off into its own container, lest it gobble up all available RAM.
I'm curious how you got your first few "gigs". What should the sales process actually look like? Did you cold call, or did you have enough established relationships first? How do you typically agree on a contract, has the customer come to you with needs, or did you ask them for problems first and propose some solutions, and they agreed to them?
It works over regular HTTP and has a built in method to tell the server the last seen message (i.e. to allow replaying old messages), and exposes the event type (i.e. the event: field in the event block sent from the server) for use with addEventListener in the browser.
It's supported by all non-MS browsers, and because it works over regular HTTP, it can be polyfilled in IE/Edge using long polling XHR.
are you talking about websockets for web apps? It's not always easy to implement and it requires some extra libraries and deployment setups. Is it really that easy to add for you as giving client extra candy in post order?
Tools like these also make it easy to create documentation that is a step-by-step walkthrough of each process.
There is also an entire class of tools designed to screenshot automatically to track work: http://alternativeto.net/software/timesnapper/