CP Manager Had To Be Invented — Then Our Programmers Had To Be Taught How To Build It

Here's why the first workflow-driven agency management system took longer — far longer — than anyone else's...

Since 1990, I've worked as an insurance automation consultant helping agencies increase productivity and efficiency, and along the way, selling agency management systems at the highest level for two different companies: Agency One and InStar. Both are gone now. But for over a decade, I was the top producer for each of them and their lead consultant.

Having worked as a productivity consultant to agencies and having actually represented two different system vendors taught me something no programmer ever could have: what actually happens inside an agency when the software gets in the way.

Every year, in agency after agency, I saw the same thing. CSRs re-entering the same data three times. Producers avoiding the system because it fought them. Commercial lines treated like an afterthought. And every time I brought it back to the vendor — "here's what needs to change, here's how to fix the workflow, here's what would make this system actually productive" — I got the same answer:

"We can't do that. Our table structures don't support it."

I heard that sentence more times than I can count. Different vendor, different system, same wall.

The Wall Every Agency Management System Hits

Here's what most agency owners never see, because it happens before they ever log in: every agency management system starts life as a database. 

Someone decides what the client table looks like, what the policy table looks like, how notes and follow-ups and correspondence get stored — and then, once agencies start going live on it, that structure is locked. Permanently.

From there, a vendor can add features on top all day long. New screens, new reports, a new integration here and there. What they can never do is go back and change the foundation. The table structure is the system. It determines how many clicks it takes to process a task, how many windows a CSR has to jump between, how data does or doesn't flow from one screen to the next. And once it's set, it's set.

That's why every "workflow improvement" I ever proposed to a vendor died the same way. Not because they didn't want to fix it. Because they couldn't — not without tearing out and rebuilding a system that already had live agencies on it. Nobody was going to do that.

Those who design systems believe features are the key, and they all strive to create one "wow" feature to impress agencies with. In addition to this, starting with features is typical because that's how programming teams write database programs. Client database first, policies, notes and the rest bolted on as features.

Workflows, if they ever get addressed, are added on top afterward, working around a table structure foundation that was never built to support it. That's not a knock on the programmers who built them. That's just how programmers have been taught to build database systems in this industry and every other industry.

I Actually Built A Process-Driven System

I'm not just an insurance automation consultant who talks about workflow — I've built it.

Before CP Manager, I wrote a process-driven agency management system from scratch for a specialized agency that couldn't use a traditional AMS at all — their business was too unique for anything off-the-shelf.

Other programmers quoted them up to $75,000. I built it for $21,000, and it outperformed every one of those quotes.

I turned their busiest season into push-button processing — update a record, generate the paperwork, print the labels — and the job that used to take 8 people to process, one person could now handle alone.

The key to dropping the number of people from 8 down to 1 to handle the job was having a very clear understanding of "how" they processed the work, and then building the system around that.

It wasn't about features. It was solely about how they did the job, and then automating everything. If changing one field meant three others had to update too, we automated the cascade — change one, the rest were updated also.

With the extensive knowledge I had on workflows, productivity strategies, agency management systems, relational databases...

I Set Out To Build A System Backwards By Starting With Workflows

In 2007, I started designing something different: a system where the workflow comes first, and the table structure gets built to serve it — not the other way around. It took a year alone just doing the blueprint.

That sounds simple. It isn't. It meant that before a single table got designed, we had to map out, in detail, exactly how each policy task actually gets worked — new business, renewals, endorsements, claims, cancellations — across every line of business, because each one genuinely works differently.

I listed out each of the service tools needed to process the work and how they should operate to support the task at hand.

Everything was evaluated. And every service tool from notes to attachments was overhauled to support a workflow driven system with an emphasis on increased productivity.

Only after all of this, after everything was mapped out, could the database get built to fit it.

The problem: no programmer had ever built a system this way. 

Not because it's a bad idea — because standard training doesn't teach it. Every programmer who's ever built a database system was taught the same way I have watched play out the past 30 years of working with agencies to increase their productivity: start with the objects, build the features, ship it.

Starting with workflows and building table-structure-derived-from-workflow isn't a technique you hire for. It's not in the curriculum programmers learn from. I had to teach it, team by team, from scratch.

Why I Wouldn't Let It Slide

I know exactly what needs to happen for an agency to run efficiently. I'm not guessing at it — I spent over 3 decades watching agencies get stuck inside systems that couldn't fix themselves, and I know precisely which decisions cause that.

So when our programming team, mid-project, fell back into old habits by solving a problem the "feature-first" way because that's what they'd been trained to do their whole career, I didn't let it stand. I had them rip it out.

Not patch around it. Literally rip it out and rebuild it the right way, even when that meant walking away from work that was already done.

We lost a good year because of this alone, which happened way too many times. It's just not how programmers are taught to write database programs.

Programmers loved working with me for the same reason some of them hated it: I wasn't going to compromise on the one decision you don't get a second chance at.

You can add a feature next year. You cannot fix foundational table structures after agencies are live on the system. Get it wrong upfront, and you've built exactly the kind of system I spent thirty years watching agencies get trapped inside.

That's Why It Took This Long

Not because we were stalling. Because this had never been done before, and doing it right meant inventing the method, teaching it to programmers who'd never worked that way, and enforcing it every single time the old habits crept back in.

Could a version of CP Manager have shipped years ago?

Sure, if I'd been willing to let table structures get set the same way every other system's did. I wasn't. I'd already watched what that costs an agency, from the inside, as the person agencies trusted to tell them how to fix it and having to tell them, every time, that the fix wasn't possible.

CP Manager exists because I refused to hand agencies a system with that same wall built into it. It's still the only agency management system built based upon workflows as the foundation to the system, where the table structures were designed to support how the work actually gets done instead of building another feature-driven system first and asking the workflow to fit in around them afterward.

That's not a system that gets built fast. It's a system that gets built once, right.

Ready to see the difference a workflow-first foundation actually makes?

Schedule a Walk-Through and we'll even let a CSR from your agency drive. Not only do you get to experience a highly productive workflow driven system, you'll hear from the CSR 'how it felt' driving it.