Custom PSA Software for MSPs and Services Firms

The market's loudest complaint about PSA software is billing: reconciliation done by hand every month, a second billing tool plus a connector because the base product can't bill some things cleanly, and billing treated as a specialist role that firms hire for [reported]. The complaint is about the gap between the product's assumptions and the way the firm actually sells.

One services firm we work with had a system built on stringent assumptions about how it would be used. When it went live, the only invoice it could produce was a line item with a total. Their clients needed the detail, so the firm rebuilt it by hand every month: run reports, pull the data, copy into templates, import. Not every line was typed, but every line needed a human's attention, and their invoice numbers run to four digits. The rules lived in people's heads. This client pays for mileage, that one doesn't because it was negotiated into the retainer, this state bills at a different rate. Every invoice meant going to look at a few different things to make sure the pricing was right. Invoicing finished around the 21st.

Now the rules live where you'd expect them, on the contract and on the client record. Not a big configuration system. When something has the word system in it, we all know that means it's complicated. Because the rules sit on the record, the warning happens at the point of work: log a billing item the client doesn't pay for and you're told then, not when the invoice bounces at month-end. The invoice run checks that every account and rate is current, generates the invoices, records what was emailed and transmitted, and uploads to accounting. Outside a couple of hours of double-checking, the run is under an hour, and the emails are out in about ten minutes.

Billing models we've shipped: monthly retainer plus project fees, per-incident, add-ons riding on another service, and time or activity billed in increments with per-client and per-jurisdiction rates. In an integrated system that already has the data, a billing model is a formula, not a feature, and MSP billing automation is the same formula run on a contract. We've posted to QuickBooks, SAP, and Sage, and we run our own general ledger that your accountant can work from. Whether accounting receives detail or aggregates is your choice; the PSA's reporting is usually better, so the accounting system stops being the reporting system.

It starts with interviews across as much of the company as we can reach, usually on site, because the rate exceptions and side spreadsheets people carry in their heads come out when you talk to employees. We don't need to capture everything. We need enough that by week four one of our systems is standing with your data in it, fully functional: clients, contracts, tickets and time entries on screen, reports that are already fairly complete depending on the quality of the data, and new screens being added.

The teams who'll use the system are in it for weeks before go-live, so nobody learns a new system on launch day. We call go-live about eighty percent. What follows is finding the interim steps that no longer need to exist and the omissions that only show up in use. The build itself is six to ten weeks; the company keeps tuning after that.

When the specifics of the software don't matter to your success. If there isn't much detail being kept, not much tracking or analysis, use whatever works well. And when you don't have the brain cycles. A business has to pick its priorities, and if this isn't at the top it isn't time, because if you can't execute it inside your company, it's not time to buy software yet. That's often why the first project is small: the invoicing run or the ticket clustering that frees up the team's time to build for the future. The longer argument is in the Software-as-Service thesis.