Why workflow apps are better than kanbans

As a companie evolve and establish their own internal processes, they usually search for software solutions(such as workflow apps) that will allow them to scale those processes while keeping the overall “feel” of their natural workflows. As processes are usually chronological, step-by-step affairs, most people will often feel that pipelines (or kanbans) are the best means available for transposing their processes into internal tools.

So, most productivity tools, such as Monday, Click Up, or Trello, will either be pipeline oriented, or at least have a heavy focus on pipeline building for managing projects. That’s a legacy mindset that arises from the heavy use of kanbans in core business tools, such as CRM or Project Management software.

The problem with this approach is that while a pipeline is a great way to visually represent what the overall process is, it’s hardly ever the best way to operate said process.

That’s because pipelines are the most logical way for a builder to design and walk through a process from beginning to end, but processes are seldom a one-man job.  Instead, they’re team-wide efforts that must be carefully orchestrated, each individual person being responsible for their own microprocess, and who hardly ever benefits from the overload of information that a giant, unified pipeline entails.

So are pipelines bad? No! They’re a perfectly fine way of structuring processes, and perfectly serviceable when dealing with smaller, simpler workflows. However, if you want to build scalable processes, that are less prone to errors and that boosts team productivity to the maximum, it pays to divide your pipeline into smaller parts, with dedicated views for specific sections of the process. We’re going to run through some classic cases in which pipelines break–and where apps flourish.

Workflow apps case 1: Synchronous teamwork

Let’s take a step back and talk about CRM and Project Management software, and why pipelines usually work for them. 

Classic CRMs usually assume a salesperson will be responsible for a deal from beginning to end. From New to Won, each salesperson will dictate their own pace and perform every task related to that deal, working as their very own “deal coordinator”. Even if they need external help (for example, asking the legal team to send an agreement), they’ll just write it down that they should follow up with the legal team in a day or two. Every piece of actionable information in the deal pertains to them. Work is synchronous, but mainly a solo endeavor.

Project Management is the opposite. You’ll have a card for a specific project and assign tasks to team members. However, the card itself in the pipeline is overall irrelevant. It’s more of a progress tracker than anything else. Usually, team members will perform their tasks in parallel, then meet daily or weekly to record their progress and issue new tasks. Pacing is dictated by the team, not the pipeline, which acts more as a data log than anything else. Work is collective, but asynchronous.

But what happens when synchronous team work is involved?

Imagine this: 

• The Sales team must ask for a cost estimate on a project from the Finance team. 
• Then, the Sales team negotiates with the prospect before making a proposal. 
• After the prospect agrees, the Finance team must send an agreement for signing.
• After the signing, the Sales team must onboard the new client, and then pass the card over to the Finance team again, who’ll keep an eye on it for the first invoicing. 

As you can see, in this process, the responsible party is switched many times. At a given moment, a deal can be the responsibility of either the Sales or the Finance team. 

The way most people will work around this is by creating extra stages or columns in their kanbans, and assigning owners to each stage. This works, but not without its own share of problems: the kanban will become excessively long, and being the owner of varied stages that are visually far apart increases the chances of something “slipping by” exponentially.

Even when trying to be as methodical as possible, it’s very easy to miss a card or two when looking at a pipeline as a whole–especially if you’re not able to perform their corresponding tasks and move them along immediately. 

Adding too many stages to a kanban can make a process cumbersome (screenshot of Trello)

Let’s give an even trickier example. Imagine a sequence of tasks that belong to the same stage, should be done in order, but are spread to different people. For example, for a New website project, the task Test in production is dependent on the Buy domain one. In this case, it makes no sense to create new stages to the general Projects pipeline. After all, that’s very specific to this one project in particular. With a regular pipeline, it’s very easy to miss this “pass the baton” moment. 

Adding stages for specific tasks is not sensible… (screenshot of Trello)

…but keeping them hidden just inside the card make them easy to miss when things pick up (screenshot of Trello)

We can solve both situations easily with dedicated apps. 

In the first case, we can create apps that are filtered to only see records from specific stages of the kanban. We can even go one step further and create different mini tables that already show us the records in each stage, along with the relevant fields for that specific stage. Using a combination of formulas and components, we may add things such as showing how many records are “stuck” without any update for more than 2 days, and other important, actionable information. 

In Jestor, you can create kanban-based workflows…

… but also create apps that allow you to operate them better

In the second case, we may do a similar setup. But now, we may use automations to help us out. For example, we may link two tasks together, and then make it so when the first task is finished (in this case, by completing the to-do), it will change the following task Waiting field status from checked to unchecked. This, in turn, will make it appear on the app. The responsible party will immediately know that it can start working on it. 

By automating task progression…

…we can create an app that shows what we have to do NOW

The idea here is that Apps present you a way to prevent team members from experiencing sensory overload. Looking at a wide pipeline full of cards (from dozens to hundreds by stage) can be daunting and a recipe for disaster. It’s confusing, and things are often forgotten or not seen. For some processes, such as Sales or Billing, that’s a lot of money a company can lose just on things slipping by.

Workflow apps, however, can trim down unnecessary fat from the process, so people can know that every single piece of information on screen is useful and actionable. This means no more searching for what to do. Instead, software dictates the pacing: if you see it on screen, you must act on it. 

Workflow apps case 2: Centralized information

Another way pipelines often fail to present information in the best way possible is when you need connected data. 

For example, imagine you have a database of Clients, and those clients can pop up in many processes at once. For example, they may be in:

• The Sales process, appearing through multiple deals in their lifetime.
• The Billing process, with a new record for each invoice sent.
• The Customer Support process, which contains every ticket they have opened.

And so on. 

Pipeline oriented software will often provide you with good tools to build those specific processes, but will not give you a proper way to see them all at the same time with a centralized view. At most, they will show you all the existing connections when you open the client’s record, but seeing all the information at the same time, with no way of filtering or prioritizing what’s relevant, is hardly useful. If anything, it will cause even more confusion. 

Our point is: pipelines are pipes. They are great when connecting things serially (for example, Sales connects to Billing), but they are not good for centralizing information. 

If that doesn’t seem relevant to process building, consider this: a lot of vital processes for a company are subjectively triggered. In other words, routines that depend on case-by-case analysis of data.

Let’s go through a quick example: imagine your Customer Experience team has to run a daily check of their own assigned clients, and act based on some possible insights:

• Perhaps a client is a recurring customer, but it’s been three months since their last potential deal. Have they found another service provider?
• Another client is late on the last two invoices, which is a sign they might churn soon.
• A third client has opened ten different support tickets in the past few weeks. How did this impact their overall experience?

If all you have is pipelines, the daily process will look something like this:

• Open the Sales pipeline, and check all cards for customer A.
• Open the Billing pipeline, and check all cards for customer A.
• Open the Support pipeline, and check all cards for customer A.

Then, do all of this again for customer B, and C, and so forth. Odds are exhaustion will make the Customer Experience analyst miss a lot of potential insights, and in fact there’s an even greater chance they won’t have the time to do this as diligently as they should for each client. Worse, this leaves them with even less time to do their actual job (of getting in touch and building a relationship with their assigned clients). Pipelines are the worst tool possible for their job.

Opening every pipeline to look for specific clients… (screenshot of Pipe)

… can become a daunting task when you start to scale up (screenshot of Pipe)

Apps, however, are a wonderful way of providing an eagle eye vision of specific parts of your company. With just a quick glance, your team can check all on-going deals, billing history, and open tickets a client has. This can cut the time spent fetching information many times over. Better yet, adding new information they should look at barely demands more time and effort on their side. 

Creating a centralized view makes 

While time spent looking at pipeline information always scales linearly, time spent looking at centralized information always scales in ever smaller increments. 

Workflow apps case 3: Field operations and hyper focused tasks

The last case we’ll bring to you is one commonly faced by companies that have physical operations. 

Pipelines, just like spreadsheets, are at their core office oriented tools. They are generic structures created to receive data from computers. You’ll be hard pressed to find people who are ecstatic about using pipelines and spreadsheets in their smartphones, which can be a real problem when trying to bridge the tech gap between office and field ops.

To be clear, this can prove to be a problem with even office tasks as well. Some teams may have what we could call hyper focused operations: tasks that are so simple that operating a pipeline can slow down things significantly and actually be a detriment to the operations instead of helping.

Let’s think about two examples, one for field ops and one for hyper focused office tasks.

In the first example, let’s imagine a warehouse. In this warehouse, a shipping officer must check for requests of specific items and dispatch them. The process, then, is changed so they have to update inventory info on a spreadsheet and update the request on a pipeline so the office always has real-time numbers and indicators. What was a relatively simple task with high productivity has now slowed down to a slog. 

The way we can do this better is to build an app that shows only actionable requests from the pipeline, and create a button that automatically moves the card along and updates inventory information. The process is just as fast as before, but now there’s no data gap between office and field ops.

Now let’s think about a very specific office task. Imagine an administrative clerk that has to check if a request has all the information necessary and approve or deny based on this info. In this case, we could build an app that shows pending requests, and create buttons with relevant automation. For example:

• Approve Button: moves the card along the pipeline and sends an email notifying the requester.
• Discard Button: moves a card to Discarded and sends an email notifying the requester.
• Send to Supervisor: passes the card to their supervisor, who’ll then have their own app to evaluate and approve requests.

Hyper focused apps can boost productivity tremendously!

By creating specific apps, we can effectively create a factory line in which people can be ultra efficient, because non-actionable or non-relevant information is hidden. All they have to do is read and click on a button, instead of operating the pipeline, opening cards and so on.

Should I ditch pipelines?

The answer? Only if you want to. Pipelines are not inherently good or bad, they’re tools that can be quite handy if you know how to use them. However, the mindset of trying to transform every process and every workflow into a pipeline is bad. As much as kanbans are touted as a general use, productivity boosting feature, truth is they can be quite hurtful and difficult to operate if not used properly. 

Apps give you the versatility to build a truly optimal tool for every situation. Because they can bring you only the relevant information and have a wide subset of tools from which to choose, you can break processes down into microprocesses and optimize them in ways a pipeline could never properly do.

In fact, you can even empower pipelines by a kanban to your app along with other visual components, making those processes that are a good fit for pipelines even better.