Petri Autio 2026

Heading into Stockholm World Water Week 2026, with its theme of Water for People and Progress, one part of the mWater platform with growing traction and enormous potential stays on my mind: Workflows.

Workflows, digitized business processes, can help organizations sustain and improve services especially now that they face tighter budgets, shorter project cycles, and more pressure to show results. This means real money saved and gained. mWater is enabling WASH professionals do more with less by turning informal processes into repeatable systems, and seeing early successes motivates me to keep promoting the feature. I'll expand a little on what workflows are, what I've learned from seeing them be deployed this year, and where I think more opportunities lie.

Create workflows for any business process to systematize them.

Building workflows

Thanks to funding from UNICEF Madagascar, we built and released workflows late in 2025 as a feature for everyone to use. Since then, organizations have created nearly ten thousand workflow instances across about 170 workflow types that have seen real use, and some larger organizations are beginning to adopt them at scale.

From within the product team, the challenges with workflows looked mainly technical. Workflows are a configurable process engine, and with flexibility comes systems complexity which we want to handle behind the scenes and present users an elegant interface. You define a workflow type with steps, actions, triggers, automations, roles, and permissions that then have to hold up against real business needs. Each live workflow is an instance of that type, and there can of course be as many as are needed. It moves through the process, which may branch or loop back on itself, collecting data at different steps, assigned to the right people at the right time, with alerts rising when something stalls. It is complicated software, and I expected the majority of the difficulty to live there.

A lot of preparatory conceptual work was needed to have a solid model before we got to the build. But the real-world challenge is that most organizations do not have clearly codified processes in the first place. When you sit with a utility and ask them to describe how a repair moves from report to verified fix, the answers vary. For more complex workflows like project implementation, a lot more is up in the air.

A workflow type pushes that ambiguity toward resolution. You cannot define steps without deciding what the steps are, and each action within them and transition between them needs to be considered. That conversation can be difficult, and making it happen is probably the most valuable thing the feature does. This, I think, is the real pathway toward professionalization that mWater can help facilitate.

What workflows people use

I assumed repair and maintenance would dominate the types of workflows created. Preventive maintenance is one of the best and most cost-effective ways for a utility to protect assets and save money. The data also now leans that way. About a quarter of deployed, named workflow types are related to repair and maintenance. But usage is broader than I expected, with room to broaden still.

So what is being done? Teams are running household connection pipelines, procurement and purchase-order flows, installation tracking, quality monitoring, kiosk operations, and public-health case notification.

Repair workflows, once they settle, converge on a similar shape: report, assess, fix, verify, close. I have seen that pattern independently in water-point repair, filter replacement, leak repair, and piped-system breakdown workflows across different countries. Across contexts the same two questions remain: who verifies, and what counts as verified?

Connection workflows are different. They are longer, with more handoffs and more waiting on external parties. Here the same workflow engine has to support short repair loops, long connection pipelines, and branching processes without forcing them into one model.

More organizations are asking us to help them adopt workflows seriously, which is more than documentation and templates can carry on their own. mWater stays free for unlimited use, and bug reports are always free and always welcome. For teams that want hands-on help designing workflow types, we now offer that through Stellar Data, and what it earns goes back into the free platform.

Making use of the data

Our workflows interface allows a manager to see which workflows are active, which step needs attention, and which ones have ongoing notices or alerts calibrated to the process at hand. Each workflow can hold many different types of collected data, so there is a real opportunity to apply mWater's visualization and analytics features to it.

The complexity of workflows does raise the expertise needed to make those visualizations useful for management. We have made dashboarding much more accessible to non-technical users through our AI-assisted design tools. A manager can describe what they need in a chat box in their dashboard widget, and the AI assistant works out the data structure and technical choices required to build a useful table, map, or chart.

If you have not tried these features yet, I would encourage you to, whether or not you have active workflows. The AI feature is free for users up to a daily cap, and works with any data your user account can access.

Challenges I see people hitting

1. Trying to capture all the complexity

Branching logic and automations are powerful and the temptation to over-engineer is real. Our documentation says to start simple and add complexity. I would recommend you build the smallest version that captures your actual process, run real cases through it, and only then add automations, branching, and edge case handling. You will usually find that the step you debated for an hour does not matter, while the one you added as an afterthought is where the work gets stuck.

I envision workflow complexity as an area where AI tooling can provide a critical validation role going onwards. Currently, we provide ways to make starting small easy through ready-made templates. In the future, AI-powered design and validation can boost ambition and confidence in building more elaborate workflows.

2. Assigning steps to people instead of roles

A related friction is assigning steps to individuals. It feels natural, especially in a small team where everyone knows who does what. It works until the person goes on leave, changes jobs, or leaves the organization. Then workflows may sit at a step that belongs to nobody, and nothing in the system signals that anything is wrong. An admin has to notice, step in, and move the workflow forward.

Most of this is avoidable at design time. When you deploy a workflow type you can place whole groups and teams into roles rather than named individuals, and define custom roles that match how your organization is actually structured.

3. Sticking to the old channel

A team builds a workflow and starts running it, but the WhatsApp group stays open and the formal process gradually stops being used. This is understandable. Direct communication is instant, familiar, and allows for useful vagueness. But if the real decision-making keeps happening elsewhere, the workflow becomes an after-the-fact record rather than the natural place where work is managed.

My impulse is to keep making workflows more compelling as a feature and simply be the superior, more rewarding choice. We have recently added in-app communication for our general admin support flows. That work opens the way to building the same capability inside workflows, so that managers and technicians can discuss a specific repair or maintenance task in context. Workflows need to add value to each participant to scale up well and become the natural place the work happens.

Why this can be a multi-million-dollar opportunity for the sector

Workflows are a free feature, like the rest of our platform, so the multi-million-dollar opportunity is not about license fees for us but rather operating costs avoided, downtime reduced, and institutional capacity retained.

Why such a large opportunity? Foster and colleagues priced the ten-year gap between community-managed and professionally maintained water systems in Kitui County, Kenya: USD 30 per person for handpumps, and USD 154 per person for piped schemes serving more than a thousand people.

If we conservatively attribute just a quarter of that gap to the coordination a digital workflow supplies, and gloss over differentials in different contexts for our illustration, a repair workflow creates about USD 377 a year in value for a small rural system, and up to USD 19,250 a year for a large utility scheme.

Today, mWater hosts over 1.5 million mapped water points, but users have also defined nearly 110,000 water systems. 46,000 water systems have assets mapped, with about 2,000 new systems added every month.

It is tempting to multiply all 46,000 systems by the USD 19,250 utility rate to claim an immediate USD 885 million annual market. But that misses how infrastructure actually looks on the ground. Most systems mapped in mWater are smaller rural schemes rather than massive municipal utilities.

A more realistic, weighted blend across those 46,000 systems, mixing rural point-based schemes with larger piped networks, yields an average workflow value of roughly USD 1,065 per system per year.

That brings the current baseline value of repair workflows to USD 49 million a year, or USD 490 million over a decade, counting zero system growth,.

Given that repair and maintenance represent only about a quarter of what teams actually track on mWater, this figure captures a fraction of existing platform usage, and includes nothing yet for capital planning, construction, water quality monitoring, or sanitation, not to mention all the activity beyond WASH being managed with Solstice.

See more detailed workings here.

Even modest estimates suggest there’s a huge amount of value utilities can gain from adopting workflows.

Enterprise software has priced this capability for decades, which tells you it has value. ServiceNow booked USD 13.3 billion in 2025 selling ticketing, escalation, and workflow tooling. Salesforce lists Field Service at USD 175 per dispatcher or technician per month. A utility running two dispatchers and twenty technicians would pay about USD 46,000 a year in licenses alone.

Now set that against the numbers above. A community water system's entire annual gain from a repair workflow is about USD 375. One Salesforce technician seat costs USD 2,100 a year, nearly six times the whole value the process improvement creates. That is not a criticism of Salesforce. Their pricing is rational for markets where a technician hour bills at a hundred dollars or more. Rural and small-utility water supply is not one of those markets. The capability has never reached these operators because at commercial prices it cannot.

That is the argument for building it as a public good. mWater's workflows are free and stay free, so the value lands in a utility's operations instead of a vendor's revenue. A funder who pays once for a feature buys it for every organization on the platform, in every country, permanently.

Those costs sit on an asset base a utility already owns and can already freely map on mWater. At root, they are produced by the gap between a problem existing and someone accountable acting on it. That gap is exactly what a workflow addresses. Actions within steps belong to real people, alerts are raised when things stall, and a dashboard shows which cases have been open longest. In consistent use, workflows can change the interval between a problem existing and someone accountable acting on it, which is exactly the interval where those costs accumulate.

The timing gives this urgency. Aid commitments for water supply and sanitation fell 9 percent between 2022 and 2023, and preliminary OECD figures show total official development assistance contracting by 23.1 percent in real terms in 2025, the largest annual contraction on record. Fewer than 13 percent of countries report having enough money and staff to carry out the WASH plans they already have.

In that environment, defining a process once and running it across teams and regions is more than an efficiency gain. A defined process, together with the data and management signal it produces, is one of the few assets a utility keeps when the project officer, the consultant, and the grant all leave.

That is the kind of progress Water for People and Progress should point us toward, and that mWater can help provide: professionalized operations that survive when individuals and project teams move on.

Petri Autio

Head of Product, mWater and Solstice