We started the company in 1990, to create dedicated software for charities and NFPs. Specialised solutions were fairly scarce: many fundraising and membership professionals were still bolting together generic databases, sales-driven contact trackers, and spreadsheets - all a bit Heath Robinson.
We thought we could do better – and, false modesty aside, so it proved. The original, DOS-based version of alms was a hit. It was devised specifically for the sector, and it was built to be flexible: users could configure their own screens, tables and views, and arrange them to suit. And so ‘flexibility’ became our byword and hallmark. alms for Windows in 1994, and Visual alms, three years later, didn’t just offer more features and capability, they were expressly designed to be customised.
Things went well. Our client base grew and diversified, we were able to invest in serious customer training and product support, and the resulting dialogues – between us and clients, and between clients themselves – were soon feeding back into the product development cycle.
And this is where the thinking behind alms.NET took shape – in workshops and training events with our partners. It wasn’t a straightforward process; indeed some of the key ideas for the development of the system arose in response to problems. In particular, it was obvious by now that that the flipside to flexibility was complexity – unnecessary complexity. The systems we’d built and customised for clients were becoming unrecognisable. In hindsight, some seemed to have changed every time a new staff member had been recruited, and this had been a time of high attrition and turnover among technical staff in the sector. Add to this modifications made when a client’s business mix changed...
We wanted to harness the power of our customers’ expertise and experience. They wanted to share and learn. But we were losing the common language and understanding needed to make that happen. So we had a deeper look. And we found - to put it really simply - common tasks and processes being performed in different clothes, under different names, in different sequences. This wasn’t really news to us, looking back. But when discussed in the round, with a group of folk from all over the sector, doing a variety of things - well, let’s say we had a bit of a collective lightbulb moment. We set about identifying the business processes inherent in what all our fundraisers and membership managers were doing, synthesising them to the point that they were a good fit with effective practice across the range of alms users, and started revising the architecture of the system accordingly.
This was meant to be a section about the company, and I’ve written about the origins of alms.NET. Perhaps that’s a message in itself.
To get back to my brief, and assuming you’re not that bothered about what we look like (it’s a mixed picture) or what we did on our holidays, I’ll just say this:
We’re not a large-scale company, we’re not part of a group, we're specialists. We work flexibly and maintain a physical office in London Bridge down by the river, and we retain a call-off team of accredited technicians for when things get busy.
Get in touch - we might be able to help you do what you really want to do.