When an automation needs a dashboard — and when it doesn’t

Start without one

It is tempting to put a dashboard in front of every automation. It makes the work visible. There is a menu, a queue and something the client can open. But visibility on its own is not a good reason to build another application.

Take a website enquiry. A workflow can check the contact details, create a record in the CRM, assign an owner and send an internal notification. If that is the whole job, the CRM already has the screen the team needs. A custom dashboard would mean another login, another database view and another piece of software to maintain.

The same applies to invoices and support messages. If an invoice matches a purchase order and can go straight into the accounting system, it does not need to pass through a new interface first. If a support team already lives in a help desk, I would put the classification and suggested reply there instead of rebuilding the help desk around the automation.

The workflow changes when it has to wait for a person

Now change the enquiry example slightly. The workflow reads the message and prepares a reply, but somebody must check it before it goes to the customer. The budget may have been extracted incorrectly. The project may be outside the service area. The operator may want to change the next step from a call to a site visit.

At this point the workflow cannot simply run and disappear. The enquiry has to sit somewhere with its original message, extracted fields and current status. A person needs to open it, make a correction or choose what happens next. That decision also needs to be saved, especially if another person will return to the record later.

Email or chat can announce that something needs attention. They are less useful for holding the work itself. Once several people start replying, forwarding and asking whether an item was handled, the process has already grown a queue; it is just a bad one.

This is usually the point where I recommend an interface. Not because the automation is complicated, but because the human part of the process needs a proper place to happen.

I still would not show every item. In invoice processing, for example, the normal cases can stay automatic. The dashboard may contain only duplicates, missing purchase orders and totals above an approval limit. The screen is for the work that cannot safely continue on its own.

Keep the first version small

When a dashboard is justified, the first version rarely needs charts, configurable rules or a large settings area. I would normally begin with a queue, a page for the individual record, the decision itself and a short history of what happened. If several people share the work, it may also need an owner. That is enough to run the process and find out what the team actually misses.

The interface changes the size of the project more than it may appear. It needs a database model, authentication, permissions, validation and all the states around loading, failure and correction. It also has to stay compatible with the automation underneath it. My current starting point is €900 for an automation. Most automation projects with an interface fall between €2,500 and €6,000.

Before proposing the larger version, I want concrete answers. Who opens the screen? What decision do they make? What can they correct? What must still be there tomorrow? And why can this work not stay in the CRM, help desk or accounting system the business already uses?

If those answers are unclear, I start with the automation. A dashboard can be added later, when there is an actual human step to build it around.