A Start-Up’s Take on the Art of Processing Customer Feedback
Looking at the years between 1971 and 2010, this team used several different computer simulations to measure the degree to which human activities or interventions (including irrigation, land use changes, water withdrawals, reservoir management) alter water supply either favorably or unfavorably for communities downstream. The main question being investigated was the following: “Has human intervention led to a reshuffling of water scarcity hotspots, leading to changes in the exposure to water scarcity events?” In this study, HI (human intervention) means “land use and land cover change, man-made reservoirs and human water use.”
Use Multiple Funnels to Bring in Client Feedback
Short of asking a client to “pull up a chair” and join the meeting I have with developers every morning, I want to give users of our product plenty of ways to talk to us. Customer feedback gauges the relevance of our product and our company. Clients can use email, voicemail and in many cases immediately talk to a support engineer when they have a comment or want to report a technical glitch. Any calls that come in are our equivalent of a “911” summons. A support engineer will call back within an hour and video-record the customer’s screen to document the issue. This encourages clients to create a business case for why we should add or modify a feature. Volume of feedback on a particular issue helps us prioritize work items. Multiple channels of communication and a quick response time on our part allows us to sort and prioritize more efficiently.
Don’t Send It to the Committee
It may be that as a company gets bigger, its ability to maintain that one-on-one connection with customers gets lost. CivilGEO is still a start-up in many respects and as software engineer and director I can flit between projects and clients as I like. But, even as CivilGEO grows, this one-on-one connection with our customers will remain front and center. I have worked at firms that document, sort and file customer feedback, but don’t require much more than that. At these firms, a certain volume of calls triggers a formal review process by committee. This committee rarely interacts with those in charge of product development—and rarely, if ever, even talks to customers.
Take the Time to Talk
If a customer calls in, we try to have conference call with them that day to try to figure out the scope and severity of the problem. Depending on the importance of the request, we can have a developer working on the issue that very same day. This not only applies to technical glitches but requests for additional capability. We try to project how long the issue will take to code and we share this information with the client.
Deliberate Before You Dive
Clearly it is important to address technical glitches in the software as efficiently as possible. However, the market is full of applications that were rushed into code without adequate planning or research. We have all seen it. The result is a feature that looks sloppy and performs badly, compromises the value of your product and tests the loyalty of your most reliable customers. This is one of our challenges as we consider integrating fish habitat modeling capabilities into HEC-RAS. This is a complex area that requires a lot of planning. We are not going to rush into this one, but you can be sure that when we do release a HEC-RAS version with fish modeling capability, the work that went into research and design will be obvious. Similarly, a lot of our customers are waiting for GeoHECRAS with 2D HEC-RAS modeling capability to be released. In order to implement this capability well, a large part of the GeoHECRAS interface needed to be completely redesigned and rearchitected. It’s a laborious process, but it will be worth it.
The main thing is to treat customer feedback as the “gold nugget” that it really is. You can have hordes of “testers” in your company that give you print-outs and performance results, but what you really need is that testimonial from a client who knows first-hand what your software needs to do. Grab him, give him a seat at the table, and listen!

