People Don’t Want to Be Sold

People don’t want to be sold. They want to buy. Do you think those sentences are contradictory? Consider this:

Think about what happens when you walk into a retail store. An attendant usually comes up to you and asks, “May I help you?”

You typically respond, “No, thank you. I’m just looking.”

In all likelihood, that’s not true. You’re not just looking. You’re hoping to be buying. But you’d prefer to be left alone to buy what you want — or to buy what you need — in your own time, without pressure from a salesperson.

Now think about this: You walk into that same retail store. The attendant approaches and says, “Hi. I know you’re probably just looking. So, please free and take your time. If you need help, I’ll be right over there. And if you’re interested, I can probably help you save 40 percent of the time you’d otherwise spend here.” Then she walks away.

What happened there? The attendant realized that your need to buy from her was much more important than her need to sell to her. She approached you with the intent to serve you and to make your visit to the store valuable.

No, This is Not Retail

It’s obvious enough that core processing software is not a retail sale. Core processing software is not a a commodity. It’s not an impulse buy. But it does serve business needs. And it does provide value.

That’s why we don’t run ads that say, “We won’t be undersold!” It’s why we don’t run limited-time discount offers. It’s why we cultivate trusting relationships, stand by our customers, provide the services they need to ensure the success of the implementations, and continue to enhance, improve, and add new functional capabilities to our software.

“Why are you telling us this?”

We thought you’d never ask. We’re telling you this because if our desire to sell you our software exceeds your desire to buy it — and to work with us for the good of your company — we’re doing it wrong. And if we come with any intention other than to serve you and to help you achieve your objectives, it’s the wrong intention.

If you’ve ever seen a demo of our software, you know it practically sells itself anyway.

If you haven’t, why not?

The Tortoise and the Cloud: Part Two

In the middle of March, Insurance Thought Leadership published a post called, “‘No-Code’ Goes Mainstream”. The post offered this time-sensitive admonition:

It’s time to take a hard look at no-code–generating computer programs without the need for programmers–which could streamline business processes and slash costs … No-code takes programming to the next level [no indication of what level we’re on now], because it lets even us non-technical types do that sort of grabbing of objects to assemble apps that make computers do what we want them to do — without having to wait for the IT department to have resources for us and without having to translate our current processes and our desires into some language that they can turn into code.

Like cloud computing (as we suggested in our previous post), much of the hard looking is already being done or has been done.

OOPs

The grabbing of objects mentioned in the Insurance Thought Leadership post refers to object-oriented programming (OOP), which develops software programs as simple, reusable pieces of code blueprints (usually called classes) that are used to create individual instances of objects, rather than necessitating the repetition of individual lines of code. While OOP wasn’t new in the immediate aftermath of Y2K, it was more widely adopted thereafter, along with programming languages like Python and Ruby, as suggested in this historical artifact, which says this, in part:

In particular, the newer generation of programmers wasn’t looking back into the labyrinth of COBOL, ForTran, DB2, and other ancient procedural languages. Rather, they were looking ahead into the as-yet unstructured lexicon of declarative query languages like SQL, JavaScript, and the programming equivalent of Esperanto-XML-that permitted greater functional literacy.

Since that artifact was published almost 22 years ago, it can’t come as any surprise that no-code programming has also been around for a while.

What’s In a Name

To make an arguably self-serving point, our Design Studio offers users no-code/low-code for implementation of the Finys Suite. It’s the exact same toolset our developers and designers use. It enables insurers to be self-sufficient, responsive, and competitive by letting them design and configure their own products. It also lets business users and IT departments collaborate to design, configure, and manage the Suite — as well as states and lines of business — more quickly and less expensively.

Maybe we could have called it No-Code Studio. But Design Studio sounds more elegant. And yes, it’s in the cloud.

As Ted Nugent would say, “Ya gotta love that.”