How Onboard Cut Their Support Time in Half With DealJourney

Onboard used to have a standing meeting with a partner where the time often went on cases that had fallen between the systems along the way. Not because anyone had forgotten them, but because they had nowhere to land.

Onboard runs a maritime platform that brings everything for people on the water into one app, covering safety, weather, club membership and boat trackers for insurance customers. It is a SaaS business with subscriptions as its model, and that gives them several very different groups of customers to support: the clubs who subscribe to the platform, the tracker customers who pay a subscription for a physical product, the end users out on the water, and rescue services in several countries.

Before DealJourney, none of those groups were being served as well as they could be, because nobody could see the full customer picture, or whether a customer had been in touch before in connection with any of the other parts.

"We used a leading system on the market for some things, but mostly a flood of emails, messages, notes and memory. We never managed to use the system properly, so we had no single view of customers and leads. The result was that only the customers who happened to be top of mind got handled, and we were often behind on follow-up rather than ahead of it."

Software that is awkward to use, or that gives its users no visible value, does not fail loudly. It fails by being avoided, and there is no error message for someone quietly deciding it is faster or easier to do it their own way.

It costs more than you think, because from the outside nothing looks wrong. The licence is paid and the CRM system is in the stack. But every week the team works around it is a week of history that never gets recorded and cannot be retrieved afterwards, and a week where the system does not contribute to the overview you expect to have.

Onboard did not run a long evaluation:

"We had high expectations of DealJourney's focus on subscription businesses, which is what ours is, and of the expertise the CRM team already had, so they could build a system with all the good things they had seen, and deliberately avoid the pitfalls from the start."

Two things settled it. The first was that the commercial model matched Onboard's rather than being bolted on afterwards, a CRM system built for SaaS businesses with subscriptions from the ground up. The second was scope.

"The focus on recurring revenue and the overview of the KPIs that come with it, and the automated invoicing, so we did not need a second system for that or have to build our own. And that the system can handle the whole customer journey, from sales and onboarding with checklists for what needs doing, to support and customer health to avoid churn. Plus that it is easier, more intuitive and more automated to use. When you work in the CRM for much of the day, saving a couple of clicks or page changes at every step matters a lot, and that is clearly optimised in DealJourney."

The decision was largely Christine's, but the board was watching for one specific thing.

"The choice to switch was mainly me, but also our chairman, because he was missing the overview of our pipeline and what he could expect in sales, how it was developing, and a basis for discussing what was actually blocking or delaying deals."

The support side was split up in a way many small companies will recognise.

"Our support inbox ran through our CRM system, but on top of that came phone calls that were rarely logged, emails straight to the person doing our support, which we had no control over, and emails in my own inbox, which I struggled to keep on top of. Then there were cases raised in various meetings, plus assorted Excel lists of customers who needed following up for different reasons."

Predictably, things fell between several stools.

"We kept missing cases, and we had cases that were handled wrongly, with no way to see the history. So when you had to rescue an earlier case, you could not make head nor tail of who had handled the customer, when, why and how. On top of that came cases about development, waiting for something to be released before they could be answered, which either piled up as unread emails or were forgotten and never got a reply, so the customer never got the good experience of hearing that what they reported had been handled and solved."

Everything now lands in one place, including the things that previously had nowhere to land.

"All emails come into DealJourney, from both club support and end user support, along with cases reported directly in our own system on a tracker customer. We answer all of it from there, and where a case turns into development work we note the Jira number on it, so we can go back to the customer when it is solved. Every time a case has been answered, and it is not waiting on development, it is closed, and it reopens when the customer replies, so we have an overview of what we need to handle without anything else muddying the picture. We also handle tracker replacements that come in directly from customers through our app as support cases, and answer them when a new tracker has been sent."

The Jira detail is small and easy to read past, but it is the fix for exactly the problem described above. A case waiting on development no longer disappears into a holding state that only one person remembers. It stays open, attached to the customer, with a reference to the work it is waiting on.

The clearest measure is the one Christine offers herself, with an honest caveat attached.

"We do not really have numbers from before. But we had a support person working 20 hours a week, and today his work plus club support, which was not part of it back then, is handled in one to two hours a day by one person. We also get far fewer and shorter phone calls than before, because they usually came from a case we had forgotten or not handled properly. So we save both time and frustration by not missing cases and not having to spend time apologising and smoothing relationships over."

Worth reading that again. The comparison is not like for like, and it is not by accident that it is not. The scope went up and the time went down. Unhandled cases generate their own follow-up work. When they disappear, a whole category of work disappears with them, rather than merely getting faster.

Support was the most acute problem, but it was not the only one.

"We had no overview of the pipeline, how far along each quote was, how much time had been spent per lead, both in hours and in calendar weeks, and which leads we should have been chasing but were not, or should have given up on because they kept pushing the decision."

"We have control of our subscriptions now, so we know what needs renewing and when. We had no overview of that at all before, and had to remember who was renewing when by checking the last invoice in our ERP system."

"We have only just started using the pipeline, but we already have an overview we did not have before. Our sales rep showed it at our most recent meeting with the chairman, who finally got the overview he had been asking for, both of the pipeline and of existing subscriptions. We also put notes on the customers in the CRM now, instead of having assorted documents owned by different people, which are hard to navigate when you need to find old information or hand over knowledge."

Asked what the team values most day to day, the answer is not a feature.

"For me, what matters most is the reassurance that things are under control, and that the system makes sure we invoice what we are supposed to invoice and follows up on what needs following up, whether that is a quote, an activity or a support case."

"We can get an overview of our revenue and our recurring revenue, and our pipeline and expected revenue going forward. And we can easily look back at what cases a customer has had, and see statistics on response time and so on for support cases."

Christine is direct about the two things she would change, and both are about the migration:

"We should have cleaned up our data more instead of just bringing everything across from the old system, because we have a fair amount of mess in the people and companies that came with us."

"I would also have liked to switch off many more fields, so it became a simpler system, before the other users started working in it. I find there is too much information in ours, and it confuses the users. We need to put that right when we can."

Both are worth taking seriously if you are planning a migration. A clean import and a deliberately reduced set of fields and functions are cheap before go-live and expensive afterwards, because by then people have built habits around what they can see.

"Generally anyone who needs a CRM system, especially if you have recurring revenue, so you get that overview in one system. And anyone who needs support as well."