What If Dazza Follow-Up Gets It Wrong?
A missed follow-up is annoying. A confident wrong follow-up can be worse.
Connections make DFU more useful because they can help find loose ends without the user entering everything manually.
They also increase the cost of getting something wrong.
That is why one of the biggest design questions is not “How much can we automate?”
It is “What should happen when the system is not sure?”
Wrong person, wrong follow-up
Suppose two customers have similar names.
Suppose an email thread mentions one job while the sender is associated with another.
Suppose an accounting record was changed after DFU first saw it.
A clever-looking guess is not good enough when the result could put the wrong follow-up in front of the user.
The system needs to preserve enough evidence to know what it knows — and what it does not.
Duplicates need to be safe too
Connected systems retry things.
Networks time out. Providers resend events. Schedulers run again.
A robust DFU workflow should be able to see the same source information more than once without creating a fresh customer problem every time.
This kind of idempotent, duplicate-safe behaviour is not exciting marketing copy, but it matters enormously in the finished product.
No automatic customer chasing just because the software thinks so
Another important boundary remains in place.
DFU’s first responsibility is to remind the business owner.
It is not being positioned as a machine that independently decides to start contacting customers because a timer went off.
The person stays in control of the actual customer conversation.
That keeps mistakes recoverable and keeps DFU in its intended role as the secretary, not the boss.
When uncertain, stop and surface it
The safest behaviour is often boring.
Do not silently bind the wrong account.
Do not silently create a follow-up from weak evidence.
Do not silently mark a matter complete because one signal looked promising.
Surface the uncertainty, ask for human confirmation where needed, and preserve the record so the decision can be understood later.
That is the direction we are using as the connector work develops.
This is why testing comes before release
The interesting tests are the negative ones: wrong customer, duplicate reminder, missed follow-up, incorrect completion, revoked access and stale data.
Those are the cases we want to prove before telling people DFU is ready.
It is still under development and there is still no release date.
The aim is not software that never admits uncertainty.
The aim is software that behaves sensibly when uncertainty turns up.
Comments