We often talk about the important role of customer service and providing support to our customers. In fact, it’s one of the main selling tools of our STRUCTURE package. And we always hear plenty of feedback from our customers and users about just how important our support team is.
But equally important to supporting users is the development of the software.
I remember once I was in a conference room with a couple of old colleagues before the start of a big business meeting in which we were in charge of the presentation. We had our presentation on the projector, and we couldn’t get something quite right. A colleague was trying to get everything lined up, and as an expert user of the presentation software we were using, he was getting frustrated. I made a suggestion, and he glared at me and said, “That’s just a workaround. I want to do it right.” He continued to fumble, and we ultimately made our presentation with the misaligned components. I was put back by the comment, and even more amazed that he wasn’t willing use my “workaround” to fix the presentation.
Here at C/F, I was talking to some developers, and they wanted to try a new system to test the software where they would have someone not familiar with the software (a newbie like me), but familiar with the concepts, test it using the instruction manuals, and record how I used the software.

That way, they could see what workarounds were used, how I expected the software to work, and this would help them to reconfigure the software to function how a user imagines it should be used versus how the developers intend it to be used.
Since I had previously been told workarounds were bad, surprisingly I was now told by the software developers that workarounds are some of the best tools to improve and develop software. Too often, a developer creates programs to run how they see fit, and then the users are trained how to use the program a certain way.
If you want to be an industry leader with a user-friendly software package, you need a lot of input, and a team very much open to change.
We’ve been developing STRUCTURE contractor/construction accounting software for 32 years. We’ve made the obvious changes, like going from a hardware-based system to a software-based systems when our customers started using PC’s in the early 1980’s, and then switching from a UNIX to a Windows-based operating system, and then making changes to stay compatible with each new version of Windows.
We’ve enhanced our software to work with various printers over the years, and expanded to make it compatible with Word, Excel, Abobe PDF, and Outlook E-Mail.
We work to make it faster, take up less memory space, and be more efficient gathering, reading, and storing data.
But the really important part, the part that separates us a leader in the construction industry, is that we constantly work to enhance the appearance and user-friendliness of the package.
To make STRUCTURE more user-friendly, we rely on our users.
Our support group logs all of the calls and e-mails they receive, and these are studied by the development team, who in turn look for trends, whether they be problems, bugs, or instances where users need help completing a certain task.
If multiple users are calling to seek help completing a certain task, than we need to make it easier. If multiple users have the same problem, than we need to fix it. If our customers are asking to do something the software isn’t designed to do, than we need to change it. And we do.
Every 18 months or so, we release a new version of STRUCTURE. During those 18 months, our programmers and developers are hard at work addressing every aspect of usability, appearance, and efficiency of our software package.
We hold user-group meetings and super-user-group meetings with customers who have used STRUCTURE for years, are considered extremely heavy users, or have pushed STRUCTURE to its limits and beyond, and we seek their input.
Because we service a variety of contractors, whose businesses run in a variety of different ways, we seek input from each type of industry. When we consider making a change, we run it by our super-users to see what they think.

And we look for workarounds. Because if our customers are finding different ways to get what they need than what we intended, than perhaps we should make that workaround a core to our system.
When a customer calls our support line, they don’t get transferred to an overseas call center.
Likewise, when we need to develop, enhance, or change our software, we don’t subcontract the work out to an overseas programming company.
Our support team works a few steps away from our development team and our programmers. When we discuss how to improve our software, it is a round table discussion. It’s been this way for 32 years and counting, and it will continue to be this way.
Change isn’t always easy, but if you aren’t willing to accept change as a natural order of doing business, than you will fail. We know this, and because of this, we rely heavily on our team to adopt change to keep us competitive, efficient, and user-friendly. And we know our customers wouldn’t expect any less.
If you are not already a STRUCTURE user, take a few minutes to view a demonstration.
