Software in a Service: Taking Responsibility for What Happens Next

What changes when a client hires us to keep something working, with software as part of how we deliver it?

An integration fails on a Tuesday morning. Website inquiries stop reaching the CRM. Nobody notices until a customer calls to ask why no one got back to them.

That moment, more than the software itself, is what this post is about.

Most clients don't come to Clevyr because they want more software.

They have something they need to get done. Customer information lives in three places, and none of them agree. An inquiry comes through the website and sits in somebody's inbox. Someone spends the first hour of every morning moving information between systems that should already be connected.

The request might be for a portal, a HubSpot integration, or a dashboard. We can build those things. But the reason for building them is usually somewhere in the work happening around them.

I've been thinking about what it would mean for us to take more responsibility for that work after the software is built. There's a phrase for this idea that I find useful: software in a service.

What the client is buying

With software as a service, you pay for access to a tool. Your team still has to decide how to use it, configure it, maintain the process around it, and turn it into something useful.

That can be a perfectly good arrangement. Plenty of businesses want control of their own systems and have the people to run them.

Software in a service changes the arrangement. A client hires a provider to handle a defined piece of work, and the provider uses software to deliver it. The software might be custom-built. It might be HubSpot, an integration platform, or several tools working together. The client may still use an interface every day.

What changes is who takes responsibility for keeping the process working.

Who keeps the process working?

Take lead intake. Installing a CRM gives a business somewhere to put its leads. Setting up an integration gets inquiries into that CRM. An ongoing service could also include monitoring whether those inquiries arrive, checking that they're assigned correctly, and resolving failures when something stops working.

Those are different commitments. They need different pricing, different operating practices, and a clear agreement about who's responsible for what.

Where this fits Clevyr

Our work has always started with understanding what a client is trying to accomplish. That's the thinking behind Compass, our retooled discovery process.

Before we decide what to build, we need to understand how the business works. Where does information enter? Who needs it next? What happens when it's incomplete? Which steps depend on one person remembering to do something?

Those questions also help us figure out whether a process is something we could take ongoing responsibility for.

Consider a business receiving inquiries through several channels. Its team might be dealing with duplicate records, missing details, and inconsistent assignments. The first step is understanding that process with the people who do the work. Then we can decide what belongs in HubSpot, what needs to connect to another system, and where a person still needs to make a decision.

Our development and integration work gives us ways to fill the gaps. An ongoing service would add responsibility for watching the process, handling agreed exceptions, and adapting it as the business changes.

That's a direction I'm interested in exploring for Clevyr.

The promise has to be specific

"Pay us for outcomes" sounds good until you have to define the outcome.

If we handle inquiry intake, we could agree to capture inquiries, route them according to approved rules, and flag anything that fails. Those are responsibilities we can design a service around.

Whether an inquiry becomes a sale also depends on the client's offer, pricing, sales team, and customer. We'd need to be clear about those dependencies before making promises.

The less visible the software becomes, the more visible our accountability needs to be. A client should know what we're handling, how we'll measure it, what happens when something goes wrong, and when we need their involvement.

We'd also need to be clear about what it costs to deliver that commitment. A few things drive it more than anything else:

• How many systems are involved. Every connection is another place something can break.
• How often exceptions happen. A process that runs smoothly most days but needs hours of investigation when it fails is expensive to support.
• How fast someone needs to respond. Next business day and within the hour are very different commitments.
• What's in scope and what isn't. The clearer the line between our responsibility and the client's, the more predictable the cost.

That's why discovery has to include the exceptions, not just the happy path.

Start with the work we understand

I don't think every custom development project needs to become an ongoing service. Sometimes a client needs something built, documented, and handed over. We should keep doing that well.

But there are processes where continuity matters enough that an ongoing service could make more sense. The place to start is with work we understand, problems we see repeatedly, and responsibilities we can reasonably accept.

For a client, the question is whether they want to run that process themselves or have a partner handle an agreed part of it.

If you're not sure, that's worth knowing. Start by listing the processes your team quietly keeps alive by hand. Those are the ones to look at first.

For Clevyr, the question is what we're prepared to own after launch.

We've built our business around helping clients figure out what needs to change and then building the software to support it. Software in a service asks us to carry that responsibility further.

When the integration fails on a Tuesday morning, who notices, and who gets it working again?

If you don't have a clear answer, that's where Compass starts. We'll map how the process works today, where it breaks, and what it would take for someone to own it. Then you decide who that should be.