Work orders, paperless
Orders are created, executed and closed in the system and on the technician's phone. It's the change that shows the most.
Kit Digital
Kit Digital lowers the cost of getting started, and that's great. But a subsidized CMMS nobody uses costs the same as a paid one nobody uses: no grant covers the work of actually getting it running.
For small and medium businesses and sole traders who want to digitalize their maintenance management and qualify for the program. It's especially worthwhile for maintenance companies, installers and technical support services still working with paper work orders and spreadsheets, because that's where the improvement shows from month one.
Not to discourage you, but so the grant actually does some good.
What gets digitalized here, specifically.
Orders are created, executed and closed in the system and on the technician's phone. It's the change that shows the most.
Customers, locations and equipment with their record and their history, which is the foundation for everything else.
Plans that generate work orders on their own, so you stop depending on someone remembering.
Letting them open their own requests and check their own work orders without calling you. Included from the first plan.
The most expensive mistake with a grant like this is treating it as a purchase instead of a project. The practical advice is simple: choose the tool based on whether it solves your operation, not on whether it fits the voucher's category, because you'll be living with it long after the voucher is spent. And set aside your team's time for the rollout from the start, especially the person who knows the equipment: that part isn't covered by any subsidy, and it's what decides whether the system sticks or gets abandoned.
Leave your details and we will get in touch to see whether we fit. No commitment, no lock-in period.
First, we'll tell you whether your case fits or not, even if the answer is no. From there, we help with the part that's ours to handle: understanding your operation, sizing what you actually need and preparing whatever technical documentation is required. The program's paperwork — checking your eligibility, submitting the application and justifying it — has its own official channels, and it's worth relying on those or on a specialized advisor rather than taking any software vendor's word for it, including ours.
The temptation when scoping a subsidized project is to include everything, because it seems to come free. That's an expensive mistake for two reasons. First, a broad scope means a long rollout, and a long rollout is the most reliable way for a team to lose interest before seeing anything working. Second, configuration decisions made on day one, without any hands-on experience, are almost always made badly: preventive plans get designed around equipment that hasn't been properly inventoried yet, and checklists around work that hasn't been done even once inside the system. What's worth including is what will be used from the first week — inventory and corrective work — and leaving scheduling and reporting for when there are a few months of real data to decide with.
A subsidized project has an administrative end date that doesn't match the date the system is actually settled in, and that gap is where a fair number of rollouts get lost. It's worth planning for it from the start: what's finished within the period, who keeps the system running afterward, and what things will need adjusting in year two, because there will be some, since the operation changes. Thinking about it this way isn't pessimism, it's what separates a tool that's still alive three years later from one that got justified, delivered and forgotten about. And it has a practical consequence: the subsidized period's scope should leave the team self-sufficient, not dependent on someone external coming back every time an asset needs to be registered.
It's worth planning for from the start, because the administrative end date rarely matches the date the system is actually settled in. What matters is that the period's scope leaves the team self-sufficient: if they still depend on someone external to register an asset once it's over, the system ages fast.
It's recommended, and not just for budget reasons. A scope you can use from the first week generates the experience needed to configure what comes next properly. Expanding a system that already works is cheap; redoing a system that was fully configured without any hands-on experience is expensive and, above all, wears down the team's trust.
It depends on the call for applications, the company-size segment and the solution category. Amounts change, so the right reference is always the program's official information, not what a vendor's website says.
What it covers and what it doesn't depends on each call for applications. What it certainly doesn't cover is your team's time, which is the part that decides whether the rollout goes well: it's worth setting that aside from the start.
With the technical part, yes: understanding your case, sizing the solution and preparing whatever documentation is required. The program's paperwork has its own official channels, and it's worth relying on those or on a specialized advisor.
We'll tell you. We'd rather lose the deal than put together an application that isn't going to go through. In that case we'll talk about the project without the grant, which often still makes sense.
A short demo of your operation is the fastest way to know if this works for you, voucher or not.
Accessibility
Saved in this browser. Light or dark theme is set from the footer.