What Makes WorkMesh Different?
WorkMesh came out of problems we had seen repeatedly while working in projects and businesses.
There are a lot of good systems in the market, but there are also some frustrations that come up again and again: lack of flexibility, complexity, cost and poor customer support.
One of the most frustrating situations is when a system does almost everything you need, except for one important feature.
You ask the supplier about it and the response is effectively:
"We can build that for you, but it will cost another $20,000."
Then the feature becomes part of their product and gets sold to everybody else.
We have never thought that was a particularly good model for the customer.
That experience had a big influence on how WorkMesh was designed.
Flexibility was not something we wanted to add later
A lot of systems start with a fixed process and then add some configurable fields around the edges.
WorkMesh was approached differently.
Flexibility is part of the foundation.
The objective is for a business or project to be able to build a system around the way it actually works, rather than having to change the process to fit the software.
That is why we describe WorkMesh as a true no-code platform.
It is not limited to one industry or one use case.
The same foundation can support very different processes because the fields, workflow, access, responsibilities and Actions can be configured around the problem being managed.
That becomes particularly important once you get away from the easy examples.
Most business processes have edge cases.
Different people need different access.
One approval might need one person while another needs a role or team.
Some information is open and some is sensitive.
A process might be simple most of the time but need a completely different path when something goes wrong.
Those are the situations where rigid systems become difficult very quickly.
We have tried to build WorkMesh with those cases in mind rather than treating them as exceptions that will be dealt with later.
The Action should not disappear into the register
The shared Action and escalation engine is probably the part of WorkMesh that best explains the thinking behind the platform.
On projects, we regularly see something waiting for a decision or approval.
A change is a good example.
The paperwork is ready.
The project needs the decision.
The person responsible is busy and does not get to it.
Somebody sends an email.
Then another email.
Then somebody calls them.
Meanwhile the change is still waiting.
WorkMesh is designed to make that responsibility visible.
The Action goes to the person who needs to deal with it.
If the Action is not completed within the required timeframe, the escalation can move up the reporting line.
That gives the line manager useful information as well.
They can see that the work is not being completed and decide what needs to happen.
The person might genuinely be overloaded.
The Action might need to be reassigned.
Or perhaps the manager simply needs to make it clear that the approval is now holding up the project.
Whatever the answer is, the system is helping move the process rather than simply recording that it is late.
Project work does not only happen at a desk
The same idea applies to mobile.
Project managers, supervisors and engineers spend a lot of their time away from their computers.
If a project needs an approval, it should not automatically mean waiting until that person is back at their desk.
The direction for the WorkMesh phone applications is to support real work outcomes where the workflow can safely be completed on the phone.
If someone can review what is needed, complete the Action or approval and allow the project to keep moving, that is far more useful than a mobile application that simply shows them a smaller version of the desktop screen.
This sounds like a small convenience until you multiply it across a large project.
Two hours saved here.
Half a day saved there.
A decision made before somebody leaves site.
A piece of work that can continue rather than waiting until tomorrow.
That adds up.
Automate the reporting work that does not need a person
The same applies to reporting.
Project teams spend a lot of time every month producing reports that are largely the same process as the month before.
Take the reporting snapshot.
Extract the information.
Update the tables and graphs.
Send the report.
Then start again next month.
Some of that work needs professional judgement.
A lot of it does not.
WorkMesh supports scheduled snapshots and automated reporting so the reporting cycle can be built around the project calendar.
If the project reports at month end, the system can capture the controlled reporting position at the required time and use that position for the reporting process.
That gives the team a consistent point in time and removes a lot of the repetitive work involved in producing the same reporting pack every month.
The wider backup and recovery approach is designed around the same principle: important information should not rely on someone remembering to manually preserve it.
One application foundation
WorkMesh is also not being built as one isolated product.
We have a much broader plan for it.
The foundation has been designed so additional products and applications can sit on the same platform and work together.
That means we do not have to solve every new problem by introducing another independent system, another user list and another place for Actions to get lost.
A project may use different WorkMesh capabilities for risk, safety, environment, interfaces, reporting or other processes.
Those processes can still remain different.
But they can share the same application foundation, the same users and the same approach to Actions and accountability.
Over time, that becomes increasingly valuable.
Why we think this saves time and money
For us, the difference is not one feature.
It is the combination.
Give people the flexibility to configure the process without paying for software development every time something changes.
Make Actions visible and escalate them when they are not being dealt with.
Let people achieve useful outcomes from the phone when they are away from their desk.
Automate the reporting work that does not need somebody manually rebuilding it every month.
And build all of that on one foundation that can continue to expand as the business needs more from it.
Those are practical things.
They save time.
They reduce administration.
They help projects keep moving.
And they reduce the amount of money organisations need to spend just to make software fit the way they already work.
That is what we set out to make different with WorkMesh.