The process map came out and the fields were defined. The next question is which tool it gets built with. This lesson takes that question out of preference and turns it into a seven criteria score; anyone filling the same table can arrive at the same result.
In the second lesson you drew the process map, in the third you decided which fields to collect. What you hold now is a measurable piece of work. This lesson deals with deciding which build shape that work gets done in.
A tool decision usually turns into an argument about preference. In this lesson we drop the argument and put a seven criteria score in its place. Scoring takes the decision out of personal opinion and makes it something anyone filling the same table can arrive at.
Prerequisite: the process map from the second lesson. Without the map the scoring cannot be done, because most of the criteria rest on what the map holds.
An automation can be built in three shapes. All three can be right; which one is right changes with the work. The distinction below is the ground the later criteria sit on.
A system produced to do a particular job, running as it comes. The setup is short and the provider carries the upkeep. In return the process fits the product rather than the product fitting the process.
A middle layer that lets flows be built from ready blocks. The process takes shape by your own rules and no code gets written. In return, as the flows grow the upkeep gathers on your side.
A system written to the work. What the process is, is what gets built; the boundary belongs to the work rather than to a product. In return this is the shape with the heaviest build and upkeep.
The three are alternatives to one another as much as they are layers of one another. In one business, accounting can run off the shelf, the enquiry flow on no-code, and portfolio matching on a custom build.
The difference is not only the size of the load but its shape. Off the shelf the load is regular and foreseeable, and in return the process is expected to fit the product. On no-code the setup is light, yet as the number of flows rises the upkeep gathers quietly. On a custom build the load collects at the start and comes back each time a change is asked for. While deciding, keep in mind that all three carry a cost; what differs is where the cost falls and when.
The tool decision comes after the process is written. In the first lesson the sentence the tool comes last appeared; this lesson is its applied form. A tool comparison made without a process map turns into comparing feature lists.
Comparing feature lists misleads, because every product lists the features it is strong at. Your measure should be what your work wants rather than what the product does. And that want is written on the map.
The first three of the seven criteria look at the work itself. Give each criterion low, medium or high; a score on a 0-100 range works too if you prefer one.
Did the map come out, have the steps stayed the same for months? A settled process suits off the shelf or custom. If the process is still shifting, no-code can carry the change cheaply.
How many exception paths are on the map? Few exceptions suit off the shelf. Where exceptions are many, the cases that do not fit the product patterns pile up and manual work returns.
How many systems does the process touch? Work that stays in one system can run off the shelf. If several systems will connect, no-code or custom comes forward.
Read these three from the map rather than from memory. For how settled the process is, look at when the map was last updated. For the number of exceptions, count how many exception paths were written. For integration, list the system names appearing in the steps. Because all three can be counted, their scores stay closed to argument.
The next two criteria measure not the work but the side that will run it. When these two get skipped, what gets built is technically right yet does not live in the business.
Who will change the flow? If there is someone inside who can build flows, no-code is sustainable. If not, every change gets asked of the outside and small fixes pile up.
Who will maintain it after the build? Off the shelf the upkeep sits with the provider, on no-code and custom with you. A decision made without writing the upkeep owner meets you in the sixth month.
These two usually move together. If nobody on the team can build flows, the upkeep load passes outside on its own; then off the shelf, or a custom build with a maintenance agreement, becomes the more realistic option.
While scoring team capability, look at the role rather than the person. If capability leaves with whoever builds the flow today, that score is in truth low. In the same way, while scoring the upkeep load, think not only of the first weeks after the build but of the moments the process changes: how long it takes and who does it when a change is asked for is the real measure of upkeep.
The last two criteria are the ones asked least at decision time and paid for most afterwards. Both call for reading a contract, yet their question is simple.
Whose data is it, where does it sit, can it be taken out? The field dictionary from the third lesson helps here: ask field by field which of them can be taken out.
What happens if you want to leave this tool? In which format does the data come out, can the flows be carried over, does the work stop during the move. A tool whose answer is unknown is a dependency.
Asking about the exit cost at decision time is not planning to leave. Knowing the measure from the start makes a later decision cheaper today.
Score the seven criteria separately for each candidate. By candidate we mean not the three shapes but their concrete counterparts: the name of the product being looked at, the name of the no-code tool being looked at, the custom build that was quoted.
While scoring, ask not is this tool good but does this tool fit this work on this criterion. The same tool can score high on one job and low on another; the table measures the match rather than the tool.
The reason column is the most valuable part of the table. When the decision gets discussed later, what people look at is the reason rather than the score.
A filled row looks like this: criterion integration need, candidate off the shelf, score low, reason it connects to the portal but has no connection to the existing portfolio system. That one sentence makes asking the same question again three months later unnecessary. A high score with no reason is usually an impression rather than a measurement.
Once the table is filled, one of three patterns usually comes out. The patterns are guidance rather than a fixed rule; the final decision comes from the whole of the work.
The process is settled, exceptions are few, the integration need is low, nobody on the team builds flows, and the upkeep is wanted outside. Data ownership wants a separate question here.
The process is still shifting, a few systems will connect, someone on the team can build flows, and the upkeep can stay inside. Exit cost wants a separate question here.
Exceptions are many, the process is particular to the business, the integration is deep, data ownership is critical. In return for the upkeep load, the boundary is set by the work itself.
If the table shows two candidates as close, the decision comes not from the criteria but from the weights. Write which criterion weighs more for you; that sentence becomes the reason for the decision.
The build shapes do not rule each other out. A common arrangement is this: records and accounting sit off the shelf, the flows particular to the business get built on no-code, and only the single piece that fits no pattern gets written custom.
The price of a hybrid arrangement is boundary management. If which information gets updated where goes unwritten, the single source of truth rule from the third lesson breaks and the data starts drifting apart in two places.
There is no need to move to a hybrid arrangement from the start. Most businesses begin with a single shape and add a second only once the piece that fits no pattern turns up. That order lets you take on the boundary management load only when it is genuinely called for.
The score table narrows the candidates but does not decide on its own. Setting up a small trial with the narrowed list turns the guesses in the table into measurements.
The trial uses the same pilot measures as the first lesson: narrow scope, one trigger, visible output, reversible by hand. The difference is that the aim here is testing the tool rather than automating the work.
The exit plan is a short note written before the tool is built. Three things sit in it: in which format the data can be taken out, where the written counterpart of the flows lives, and how the work runs during a move.
This note is written to see the dependency rather than to leave. An exit plan that cannot be written can be a sign to think the decision itself over again.
Do not hold back from asking the provider for the plan. A customer who asks at the decision stage is taken seriously on the provider side too, because the question shows which clause of the contract was read. An exit question that gets avoided says something about the criterion itself.
In the first lesson the real estate office picked enquiry recording as its pilot. In the second lesson its map came out, in the third its fields were defined. Now we look at which tool it gets built with.
Candidates: the office writes three candidates. An off the shelf package made for the property sector, a general no-code flow tool, and a custom build quote to be added to the existing portfolio system.
Process and exceptions: the map is settled and the steps have been the same for months. The exception count is medium: district mismatch, a second enquiry, the agent on leave. All three exceptions are written.
Integration: the process touches three systems: the portal, the portfolio system and messaging. The off the shelf package reads the portal but does not connect to the existing portfolio system.
Team and upkeep: the office has an agent who can build flows and handles simple changes personally. Keeping the upkeep inside is preferred.
Data and exit: in the off the shelf package the portfolio data sits in the provider system and the way out is limited. In the no-code tool the records stay in the office own sheet and the flows can be taken out in written form.
Reading: the off the shelf package comes out low on integration, data ownership and exit. The custom build weighs heavy on upkeep. No-code comes out medium on three criteria and high on four.
Trial: the office builds only the acknowledgement step with the no-code tool and tests the district mismatch exception. The exception can be built, the portfolio system connects, and the agent can change the flow personally.
Decision and exit plan: no-code is chosen. Into the exit plan goes this: the records sit in the office own sheet, the written definition of the flows lives on the process map, and if a move becomes necessary the enquiry recording can run by hand for a week.
The return of this lesson comes from filling the table in for your own pilot task. You can download the tool comparison table at the foot of the page and use it.
The filled table becomes the input of the fifth lesson: you will build the first automation with the tool you chose.
Download the tool comparison table (xlsx) · seven criteria, three candidates and reason columns, along with the trial build and exit plan sections.
Every product lists the features it is strong at. The comparison gets made against what your map wants rather than against what the product does.
A demo shows the normal flow and not the exceptions. What settles the decision is not the normal flow but whether the exceptions on the map can be built.
Choosing no-code while nobody inside can build flows makes every small change depend on the outside, and the fixes pile up.
When the question of where the data sits gets asked after the build, changing the answer comes dear. The question belongs at decision time.
A tool whose way out is unknown is a dependency. When the question goes unasked, the dependency becomes visible only once leaving is needed.
When one tool works well and every job gets moved onto it, the processes that do not fit the product get forced. A hybrid arrangement usually produces less resistance.
Before the tool decision gets made, you want to be able to say yes to every item below.
The terms that come up in tool conversations. Speaking the same language as the provider shortens the comparison.
In this lesson you decided which tool it gets built with and wrote the reason for the decision. The next lesson deals with building the first automation with that tool: the five parts introduced in the first lesson turn into practice there.
If you would like to carry on with the published lessons, the seventh module covers where to look when a built flow does not run as expected.
The setup sheet, building the five parts in order and going live through a narrow gate.
The field dictionary. The ground of the data ownership criterion.
The whole training section and the modules added since.
If you would like to score your candidates together, write to us and we can fill the table in with you.
Get a Quote on WhatsApp