At Tempworks we’re constantly facing build or buy decisions on how to better support our staffing software. Such was the case recently when we wanted a better way to survey clients on our support call service.
The latest developments in web technologies like HTML5, CSS and jQuery have created a big divide between new and old web sites
One option was to build our own survey system. The other was to use one of the several innovative survey products that have come on the scene as organizations around the world have realized the benefit of efficient feedback from clients.
Building our own has almost always been our approach in the past. It’s in our DNA – to a fault. We’re developers and we’re every bit as susceptible to not-developed-here-syndrome as the next guy.
Not only that, we use our own software to manage everything from web analytics to sales, payroll and accounting. The idea of outsourcing a key function like service call feedback didn’t sit right. In fact, we already built an excellent survey system in our Applicant Portal product, but adapting it ran into a serious obstacle: developer priorities. We’re in the middle of some big project and pulling developers from client projects in the name of in-house tools just didn’t make sense.
We wanted to make it as easy and quick as possible for clients to give us feedback, so in the end we chose the solution that offered the best user experience
All that plus the fact I had recently been to a conference in San Francisco (always a great way to pick up new ideas) and got demos of various survey products by some genuinely entrepreneurial startups. So back to the shop where one of our devs, Kevin Prow, who has played a key role in a lot of our innovations got to work evaluating different survey systems.
Here are the criteria we used:
- Price. What was the five year cost of the system?
- Function. For example, same-page conditional logic in which one question shows or hides others on the same page.
- Brand identification. Could we modify the templates, themes and CSS (design code) to give the survey the Tempworks feel
- Integration. How well could we integrate it into our systems.
- URL Query String Piping (pass query string into the survey for identification purposes, pre-population, and merging into question text)
- Scriptable actions. For example, could we generate an email or use a specific template based on whether the feedback was good or bad?
- Ease of use. We didn’t have a lot of time to devote to designing our own system, so using an existing system which is quick and easy to get setup.
We began evaluating a large number of vendors, and there were many good ones. Quickly though we whittled the list down to the following products:
We eliminated next the self-hosted options which we may otherwise have chosen if not for the high cost of initial purchase and support.
We also eliminated a few options that were free but were limited with question types.
Almost all of the providers did not have same page conditional logic. Several had multiple-page conditional logic, but we want our survey to appear quick. One page. No ‘Next’ buttons.
Several also got eliminated because we had no easy way to pipe data in and out of our database.
In the end, we chose SurveyGizmo. It provided us exactly what we need at a reasonable price. Again, the ability to to provide same page conditional logic, flexible question types, data piping via url query strings, free REST API were key to this selection.