When the Dispatch Software Vendor Started Missing Support Tickets

The situation

Gabriela, Javier and Burak had put together a small coordination business a few years earlier, matching independent drivers with loads moving through Sault Ste. Marie and the surrounding routes. Javier still drove long-haul himself two or three weeks a month; Burak worked shifts at a local factory and handled the books in the evenings. Gabriela ran the day-to-day. None of them drew much of a salary out of the company in most years, splitting a modest amount between the three shareholders and leaving the rest in the business account for slow months.

The company ran almost entirely on a single piece of dispatch and routing software, licensed from a vendor based outside Ontario. It matched drivers to loads, tracked hours, generated the paperwork carriers needed, and held years of records the shareholders relied on for scheduling and for tax purposes. It worked well enough that they had never seriously discussed what would happen if the vendor stopped operating. The contract was the standard one the vendor offered every small customer: month-to-month access, no source code, and no data export tool beyond a basic spreadsheet download.

Cracks started showing about eight months before they called us. Support tickets went unanswered for a week at a time. Two features broke and stayed broken. Then a competitor's customer mentioned, in a trucking industry group Javier followed online, that the vendor had laid off most of its support team and that a rep had said something about the company being 'restructured.' Nothing about the software itself changed yet, it still ran every night, but the three shareholders realized the entire company depended on a vendor they knew almost nothing about, and that if the software disappeared, so did years of routing history, driver records, and the ability to run the business at all.

They came to our office not entirely sure what they were even asking for. Gabriela described it as wanting insurance against a vendor going out of business, but none of the three knew whether their contract allowed them to ask for anything, or whether raising it would spook the vendor into cutting them off outright. What began as a routine planning question, how do we protect ourselves, would end up drawing our attention to the state of the underlying contract itself.

The risk we had to size

Source code escrow was the tool we suspected we would end up recommending, but before drafting anything we needed to know exactly what risk the company was carrying and how much leverage it had to fix it. Escrow is an arrangement where a vendor's source code, held by a neutral third party, becomes accessible to the customer if the vendor stops operating, becomes insolvent, or fails to maintain the software as promised. It does not hand a small trucking coordination business the ability to run a software company, none of the three shareholders could maintain or rebuild a dispatch platform themselves, but it buys time: enough to migrate records and find an alternative before the lights go out entirely.

The first read of the existing contract was discouraging. It was a standard-form agreement the vendor used for every small account, with a clause reserving the vendor's right to terminate service on short notice for any reason, and no obligation to provide data in a usable format if it did. Read on its own, it looked like the shareholders had no contractual footing to demand anything. They had signed what they were given, and the vendor owed them little beyond continued access so long as it kept operating at all.

That reading changed once we asked for everything the company had: every invoice, every support ticket, every email from the vendor over three years. Two things came out of that review. First, the company had paid on time every month without exception, a fact the vendor's own account records confirmed, which mattered because the contract gave the vendor discretion to make exceptions for customers in good standing, discretion it had exercised for other clients before. Second, the emails about 'restructuring' were more specific than Javier's online tip suggested: the vendor was actively renegotiating terms with several customers to raise cash, which told us it needed customers to stay, not leave.

A vendor trying to keep accounts, rather than one indifferent to losing them, has a reason to say yes to a request it would otherwise refuse. That single distinction, between a vendor in genuine collapse and one under manageable pressure and still motivated to retain business, reshaped the entire strategy. It meant the shareholders were not asking for charity from a company about to disappear. They were offering a paying, reliable, low-maintenance account a reason to formalize a relationship it already had every incentive to keep.

What we did

1. Reviewed the existing software agreement clause by clause. We needed to know precisely what the vendor could and could not do under the contract the shareholders had already signed, including the termination language that looked so unfavourable on first read, before deciding whether escrow was something we could ask for without reopening the whole agreement. This step also confirmed the contract had no clause barring the shareholders from discussing vendor stability with other customers, which mattered later.
2. Organized three years of invoices, support tickets and vendor emails into a timeline. What had looked, in Javier's telling, like a company on the verge of collapse turned out on paper to be a vendor under real financial pressure but still meeting its obligations to paying, low-maintenance customers. The timeline became the evidence base for everything that followed, and it changed the tone of the conversation from the shareholders asking for a favour to pointing out, with dates, that they had been a reliable account throughout.
3. Assessed what leverage the company actually had. A small account with modest monthly fees has little natural bargaining power, so we looked instead at what the vendor needed: continued cash flow from paying customers during a difficult stretch, and no public sign that customers were leaving. We built the proposal around giving the vendor a reason to say yes rather than treating the request as charity, framing escrow as a low-cost way to reassure a stable customer.
4. Drafted a source code escrow agreement naming an independent third-party escrow agent. The draft set out the release conditions, insolvency, cessation of support for a defined period, or a formal wind-down, and specified the shareholders would receive a current copy of the source code and technical documentation sufficient to allow a replacement developer to maintain continuity, not simply raw files with no way to use them.
5. Opened negotiations directly with the vendor's account manager rather than escalating through a formal legal notice. Given the vendor's apparent cash pressure, a heavy-handed approach risked either a defensive refusal or, worse, a decision to simply terminate a small account rather than deal with the complication. We proposed the escrow arrangement as routine business continuity planning, which it genuinely was, and asked for a response within a set number of weeks.
6. Negotiated the terms of the compromise once the vendor agreed in principle. The vendor would not absorb the escrow provider's setup and annual fees itself, and pushed for an increase in the company's monthly licence fee to help cover its own costs. We advised the shareholders that this was a reasonable trade given what they were gaining, and negotiated the increase down from what the vendor first proposed before recommending they accept it.
7. Built in a fallback data-export protocol alongside the escrow clause. This required the vendor to provide a full export of the company's routing and driver records, in a usable format, on thirty days' written notice regardless of whether the more serious escrow triggers were met. This gave the shareholders a second layer of protection that did not depend on proving the vendor had failed in the ways the escrow agreement formally defined.
8. Advised the shareholders on what to watch for going forward. We set out, in writing, which signs would justify invoking the agreement, a formal insolvency filing, a sustained lapse in support, a wind-down notice, and which would not, since escrow protects against real vendor failure, not every missed ticket or slow week. Without that distinction, the shareholders risked either sitting on a real warning sign too long or souring the relationship over an ordinary hiccup, and we recommended they revisit the arrangement annually as the company grew.

The outcome

The vendor agreed to the escrow arrangement about six weeks after we opened negotiations, along with the fallback export protocol. The shareholders accepted a monthly fee increase in the low hundreds of dollars to help cover the vendor's costs, a concession, not a win, and one Gabriela was initially reluctant to accept until we walked through what it was buying against the alternative of losing the software with no notice at all.

The added licence cost worked out to roughly two thousand dollars a year for a company running on revenue in the hundreds of thousands, a real number for a business that modest, but a manageable one against the alternative. Had the vendor shut down without warning, the shareholders estimated it would have taken months and a meaningful cash outlay to rebuild routing and driver records from scratch, assuming the historical data could be reconstructed at all from paper backups and drivers' memory.

The vendor did not go out of business. As far as the shareholders know today, the financial pressure eased within the following year, support staffing improved, and the relationship has continued on essentially normal terms since. The escrow agreement has never been triggered. For Gabriela, Javier and Burak, this is not a story with a dramatic ending. It is a story about a company that no longer has its entire operation depending on one vendor's goodwill, at a modest and known cost, with a documented process to fall back on if things change again.

The shareholders also came away with something less tangible: a habit of asking, before signing the next vendor contract, what happens if that company disappears. Two smaller software tools the business added afterward were reviewed for data-export and continuity terms before signing, something none of the three had thought to check before this experience. The company's exposure to a single vendor's failure is smaller today than it was when the first cracks appeared, even though no crisis ever actually arrived.

What you can learn from this