Software is part of almost every area of our lives: work, school and entertainment. At work, we all know that if our business is seen as one more of the bunch, clients choose whichever provider is a penny cheaper. That is becoming a commodity.
So if we already use software for so much of our lives, why not bring it into our business?
Taking the step toward digital IPM has real challenges. But first, a quick review of the concept:
Integrated Pest Management (IPM) means carefully considering every available pest control technique and then integrating appropriate measures that discourage the development of pest populations. IPM combines biological, chemical, physical and cultural strategies to minimize pesticide use and reduce the risks these products pose to human health and the environment.
In other words, you need to know what to measure, how to measure it and how to tell whether your plan is delivering the expected results. You need to be able to prove, tangibly, that your work is controlling the population and reducing its chances to grow.
Not long ago we gave a conference on the meeting point between IPM and technology. It drew a lot of interest, because you can't know how you are doing if you have nothing to compare against (as-is vs. to-be), or no reliable way to evaluate results. Fortunately, technology lets you document, analyze and share that information with your clients.
This post summarizes that early-2022 conference. You can watch the full talk on YouTube (Spanish). Here are the points I consider most important.
Define your context
What is your specialty? What is your business really good at? Some tell me food plants, others retail and restaurants, others residential. All valid answers. Do you know when it's a bad answer?
When someone says "I specialize in everything." In 99% of cases that means you don't have an ideal customer, and no clear strategy to win that market beyond selling a lot to anyone.
What matters is recognizing what sets your business apart: what you can offer that the competition can't.
Why does this matter? Because your goals and strategies must be connected and consistent. Delivering a quality report for an audited account is not the same as handing a homeowner a receipt. Each niche has its own expectations, problems, budgets and tolerance thresholds. Understanding our context (where we are and where we want to go) is the first step.
Define your need
Since we are talking about software for an IPM business, the decision must start from an identified need.
If you want software just because everyone else has it, you don't have a solid foundation. In business, software is a tool: you get a tool for a task, a solution for a problem. In the talk I give several examples of needs:
- Operations
- Prospecting
- Sales follow-up
- Inventory management
- Document management
- Reporting
- And so on
For each concrete need, look for the best solution. Rupipest, for example, specializes in IPM operations, although we have complementary modules.
Sometimes I meet owners who already have a very good CRM (HubSpot, say). I recommend they keep it as their main CRM and connect our module to their data. That is completely normal, because HubSpot will never build a pest control operations module. It isn't their specialty.
Cost-benefit analysis
This is always key for evaluating investments and project feasibility, and for backing the decision to spend capital (or not). It usually comes after identifying what we need to improve and what that improvement gets us, in other words, how the benefit brings us closer to our goal. It has two components.
Cost: how are you calculating it?
Isolate the process you want to analyze so you can identify every cost and expense that belongs to it. That process should come from the need you identified. Knowing your costs, even as a reasonable estimate, is the cornerstone of the whole analysis.
Watch out for a common trap: the sunk cost fallacy, the tendency to keep trying to recover what is already lost even when it isn't rational. In plain words, don't cry over spilled milk.
So why care about what your manual process costs today (as-is)? Because otherwise you can't size the benefit of technology. If software saves 90% of the time spent on manual work, is that enough to decide? No, because you are missing half the formula: whether that 90% saving outweighs the cost of implementing and maintaining the software.
The best decisions are based on data. If you only know half the equation, you are shooting in the dark.
Analyze objectively
The first fork in the road: once you know the software you need (context + needs) and that it can break even (cost-benefit), will you build it yourself or hire a company?
- In-house: built by your own company, with staff hired specifically to develop it.
- Third party: built by an outside company that delivers the agreed scope for a given budget and timeline.
Stop and ask: is software development your business? If not, put your company's resources into your specialty, which is Integrated Pest Management.
Finding a third party
Two models are popular today:
- Custom development: software built from the requirements the client provides, managed as a development project.
- Software as a Service (SaaS): specialized software offered through a license (annual, monthly, etc.). It prioritizes fast deployment and everyday usability, and keeps scaling as light as possible.
Remember the cost section? If your provider isn't transparent about pricing, you'll have a problem: every time you add a user, use another feature or need more resources, you may never reach break-even. That is why it is so important to have all costs in black and white before deciding.
To no one's surprise, here is my recommendation:
I can already hear you: "Freddy, you're only saying that because Rupipest is SaaS." Let me tell you, dear PCO, I wouldn't build SaaS or recommend it if I didn't think it was the best option ;)
Other important criteria
With the above you have a solid base to continue your evaluation. Here are other points to consider in your digital transformation plan, whether you go with us or any other provider.
SLA: service level agreement
In theory, an SLA is an agreement between a provider and its client that sets the agreed quality of the service. The most visible commitment is usually the maximum response time for an incident.
In practice it is often a headache, because (more often than you'd imagine) if the SLA says fifteen days, that means you get an answer in fifteen days, which may or may not solve the problem. Be honest with yourself: can an issue in mission-critical software, the one that runs your operations, really wait that long?
Pro tip: look beyond what's written and focus on how incidents and questions are actually handled.
Ease of use
We often think we are evaluating this, but we skip it. It is about the learning curve and how long your team takes, on average, to get used to the software.
I personally disagree with ridiculously short free trials. One prospect told me they had been offered three days. Honestly, can you learn a platform well enough in 72 hours to judge whether it's easy to use? This is a business system, not an entertainment app.
Ask yourself:
- How easily does my company fit the software?
- How easy is it to pass the knowledge on to my team?
- How long is it taking me to get up and running? You'd be surprised by the horror stories of prospects who came to us after more than 15 months with another provider, still unable to use it properly.
Ongoing support
Support or warranty applies when the tool fails or behaves strangely. Ongoing help for questions and doubts is something else. Find out how much you can count on your provider to answer your and your team's questions.
- Does the provider help with training?
- Does my license include onboarding?
- Is there support material?
- Do I at least have a channel for questions?
Warranty
This answers the big question: "What happens if something breaks?" All software can have unexpected errors, or a case no one anticipated that causes odd behavior. We call these bugs. If it happens to big software companies with huge QA budgets, it can happen to anyone. No one can promise a system will never fail.
What matters is knowing what will happen when it does. Part of that depends on the SLA, and part on at least these criteria:
- Support channels
- Deciding whether it is a bug or a new feature
- Speed of the fix
- Effectiveness of the fix
Security
Security has many fronts. The most common:
- Backups: is your information safe?
- Availability: can the people who should access your information do so?
- Data handling: is your information shared with third parties?
- Auditability: is the information you generate every day traceable, or are there blind spots?
- Integrity: can your information be changed without your knowledge and without a trace?
Innovation and constant evolution
Technology that doesn't evolve becomes obsolete fast. When you evaluate a provider, consider:
- Improvement cycles: how often are existing features fixed and optimized?
- New feature cycles: how often is there something completely new?
- Usefulness: are the updates actually useful in your day-to-day?
Also pay attention to the provider's update policy: whether updates come from user needs, whether they are charged, and if so whether it's a one-time payment or an extra recurring license.
The takeaway
That was a long post. If I had to sum it up in one line for your pocket:
The better the information you have, the better your decisions. Just be careful not to fall into analysis paralysis, spending your whole life thinking without taking the leap.
