Why Does This Have to Be So Complicated?

I lost a client over calendars. At least, that's the reason I was given.

There may have been more to it. Usually there is. But one frustration came through clearly enough. She was trying to set up multiple booking calendars in GoHighLevel, the process had become increasingly laborious, and eventually she'd had enough. She found another solution—and another coach—and stopped working with me.

Her question was completely reasonable: Why does this have to be so complicated?

I understood the frustration. I also found myself wanting to give an answer that probably wasn't going to make the frustration disappear, because quite a bit of the complexity is there because somebody, somewhere, once asked, But what if I need it to do this?

──────── ⚡ ────────

A basic appointment scheduler isn't difficult to imagine. Here are the hours I'm available. Pick one.

For some businesses, that's honestly enough. If it does everything you need it to do, there's no prize waiting for you because you chose software with seventeen more switches.

But businesses have an annoying habit of becoming more specific once actual people start using them. What if I have a sales team, and every salesperson has different availability? What if appointments should be distributed among them instead of always going to the same person? What if one person uses Zoom while another meets Customers in person?

What if my personal calendar should behave differently from my sales calendar? What if someone should be able to choose whether they need fifteen minutes or an hour? What if this kind of appointment needs different questions? What if the system needs to check the calendars my team members already use so I don't book them when they're somewhere else? What if people coming from one funnel need a different booking experience from people coming through another?

Keep going and eventually, "Here are the hours I'm available. Pick one." isn't enough anymore.

Every time somebody asks one of those perfectly reasonable questions, somebody building the software has a choice: tell them no, or add another option.

Today's overwhelming setting was often yesterday's missing feature.

──────── ⚡ ────────

I should admit something here. I have a tendency to teach the whole machine.

If a setting exists for a reason, I want people to understand the reason. If there are five ways to configure something, I want them to understand what those five ways make possible. I don't particularly like telling someone, "Don't worry about that," when I know there may come a day when they're going to care very much about what that does.

That's probably a strength right up until it isn't.

My client didn't necessarily need to understand everything her booking system could possibly do. She needed to understand which possibilities mattered to her.

Complete information and useful information aren't always the same thing at the same moment. I think I've become much more aware of that distinction since.

──────── ⚡ ────────

There's a peculiar way we sometimes judge software. If a program only gives us four choices, we call it simple. If another gives us forty, we call it complicated.

But that doesn't necessarily tell us which one is better designed for the business we're trying to build.

Sometimes the four-choice system really is better. We needed three of them, ignored the fourth, and went home early. Sometimes it only feels better because it has already made thirty-six decisions for us.

You don't notice the missing decisions until you need one of them. Then simplicity starts feeling suspiciously like limitation.

This doesn't mean more options automatically make better software. A badly organized collection of powerful features can absolutely become miserable to use. Good interface design matters. Good defaults matter. Clear explanations matter.

But there's a difference between simplicity created through good design and simplicity created by removing choices.

The second is still a tradeoff, even when it's a tradeoff worth making.

──────── ⚡ ────────

That distinction has been on my mind while we've been building the Business Brain Builder.

I've been working through how a business should think about its appointment system before anyone starts clicking settings. Somewhere along the way, I realized we'd been approaching my old client's complaint from the wrong direction.

Maybe the goal shouldn't be to make sophisticated software have fewer options. Maybe the goal should be to make the human responsible for configuring it face fewer decisions.

Imagine opening a complicated calendar setup screen with no preparation. How long should the appointment be? How far ahead should someone book? How much notice do you need? Should there be a buffer? Who gets the appointment? Should it be assigned to one person or a team? What questions should we ask? What should this appointment even be called?

You aren't really configuring software yet. You're being asked to make a pile of business decisions while staring at software controls.

No wonder it feels complicated.

Now imagine arriving at the same screen already knowing what conversation you're trying to create.

You know who it's for and why they would want it. You know whether it belongs with a salesperson, consultant, service professional or team. You know roughly how long the conversation should take and whether you want to protect a little extra time behind it. You know what information would actually help before the conversation begins, and you've probably already determined that quite a few of those intimidating settings don't matter to this appointment at all.

The software hasn't changed. The number of options hasn't changed.

But your experience of using it has.

Instead of asking, What does all this stuff do, and which thing am I supposed to choose?, you're saying, This is what I need. Which settings make it happen?

That's a much easier question.

──────── ⚡ ────────

This is becoming one of my favorite things about building the Business Brain.

The goal isn't always to simplify the system. Sometimes it's to simplify the decisions the human has to make about the system.

That's what we're trying to do with calendars now.

Before touching the implementation, we're figuring out what kinds of conversations the business actually needs. We're deciding what each one is for, who should conduct it, how much time it deserves, what someone should know before booking, what questions are worth asking, and what should happen when the appointment successfully enters the business.

Then we can hand those decisions to the software.

There will still be settings. There will still be features you don't use. There may still be a moment when you wonder why some mysterious checkbox exists and discover that seventeen thousand users apparently demanded it after a very passionate Facebook group discussion in 2024.

That's software.

But you don't have to understand every possibility before making progress. You need to understand the possibilities that matter to what you're trying to accomplish.

──────── ⚡ ────────

I don't know whether a different approach to calendars would have kept that client working with me. It would be convenient to rewrite the story that way, but I don't actually know.

Maybe the calendar setup really was the deciding factor. Maybe it was one frustration among several. Maybe the other solution genuinely suited her better.

What I do know is that her complaint stuck with me.

Why does this have to be so complicated?

Years later, I think I have a better answer.

Sometimes it doesn't. Sometimes we're just being shown decisions before we're ready to make them.

Perhaps the better way to make a powerful system feel simple isn't to take away its possibilities. It's to know enough about what you're building that you can walk past most of them without wondering whether you're making a mistake.

Know what you need. Know what you can ignore.

Then let the complicated machine be complicated. You only have to tell it what to do.