FutureMinds

5.0 (1 Review)
Practical AI systems for smarter business decisions. Find what’s worth automating, what should stay human, and where AI can actually save...
Johor Bahru, MY
•Created byProfile pictureGrayson Jong
23 joined
Profile picture
Grayson JongProfile picture@grekkie·1d

Before You Automate a Problem, Find Out Why It Keeps Happening

A task being marked as completed doesn't always mean the underlying problem has been solved.

Think about a maintenance request, customer complaint or delayed follow-up.

The issue might already be recorded in a system. Someone might even be assigned to handle it.

But what happens if the person responsible is waiting for approval, missing important information or juggling several other urgent tasks?

The real bottleneck may not be the task itself. It may be what happens between identifying the issue and getting it resolved.

That's why choosing an AI tool shouldn't be the first step.

A better starting point is to examine one actual workflow:

  1. What was supposed to happen?

  2. Where did progress slow down?

  3. What prevented the next step?

  4. Would a clearer process, better information or automation genuinely help?

Sometimes AI will be appropriate. Sometimes a simpler operational change will deliver more value.

Here's a question for the community:

Think of one task in your work or business that regularly gets delayed, repeated or forgotten.

Where does it usually get stuck?

I'd be interested to hear a real example, even if it's something small.

Profile picture
Grayson JongProfile picture@grekkie·6d

Finding one good AI opportunity doesn't mean you've finished looking.

A workflow changes.

A team grows.

Responsibilities move between people.

A new system gets introduced.

A problem that barely mattered six months ago starts happening every day.

That means an AI opportunity that makes sense today might not be the most valuable opportunity later.

This is why I think the better question isn't only:

“Where can we use AI?”

It’s also:

“What has changed in the way the work actually gets done?”

Start with the workflow.

Look at where time is being lost, where information gets stuck, where people are repeating work, and where mistakes or delays keep appearing.

Then ask whether the problem needs:

• a clearer process

• better ownership

• a simple rule or automation

• AI assistance

• or no technology at all

The opportunity should come from the problem — not the other way around.

And as the business changes, it may be worth asking the question again.

Profile picture
Grayson JongProfile picture@grekkie·Oct 4

A workflow problem becomes easier to prioritise when you can measure what it is costing.

It’s easy to notice that a process feels slow or repetitive.

The harder question is whether that friction is actually important enough to fix.

Before deciding where AI or automation belongs, I think it helps to look at the operational consequence of the problem:

How often does it happen?

How much time does it consume?

Does it create rework or repeated follow-up?

Does it delay another person or team?

Does it increase cost, risk, or the chance of something being missed?

Two workflows can have the same visible problem but very different business impact.

A five-minute delay that happens once a month probably doesn’t deserve the same attention as a five-minute delay repeated hundreds of times across a portfolio.

The same applies to mistakes. Some create minor admin work. Others affect safety, compliance, customer experience, revenue, or operational risk.

That’s why I’m increasingly seeing measurement as part of finding the opportunity, not something that comes after the solution has already been chosen.

Before asking:

“Can AI automate this?”

It may be more useful to ask:

“What is this problem actually costing us, and would improving it create measurable value?”

That makes it much easier to separate an interesting AI use case from an opportunity worth acting on.

What do you usually look at when deciding whether an operational problem is worth fixing first?

Profile picture
Grayson JongProfile picture@grekkie·Oct 2

Before automating a workflow, identify the decision

One useful way to analyse a process is to work backwards.

Instead of asking:

“Which steps can AI automate?”

Start with:

“What decision eventually needs to be made?”

Then ask:

What happened?

Why does it need attention?

Who has authority to act?

What information do they need?

What can happen automatically before they get involved?

That changes the way an AI opportunity looks.

For example, a maintenance workflow might automate intake, classification, status checks and vendor follow-up.

But if a quote exceeds an approval limit or an unusual issue appears, a person still needs to decide.

The opportunity isn’t necessarily to remove that person.

It may be to make sure that when they step in, they already have the context needed to make the decision without chasing information first.

That can remove a surprising amount of unnecessary coordination.

Good automation doesn’t just move work faster. It makes the moments that still require people easier to handle.

Profile picture
Grayson JongProfile picture@grekkie·Sep 29

Having the information doesn’t always mean the workflow is ready to move

A workflow can contain all the required information and still stall.

That sounds contradictory, but consider a handoff.

The next person might have:

  • the request

  • the customer or tenant details

  • the supporting documents

  • the maintenance history

  • the relevant photos or notes

And still not know:

  • whether the information has actually been validated

  • what stage the workflow is currently in

  • what action they are expected to take

  • how urgent that action is

  • whether they have authority to make the decision

  • what happens if the normal process doesn’t apply

That means information completeness and decision readiness are not the same thing.

This matters when evaluating AI opportunities.

AI might successfully capture information, classify a request or route it to the correct person.

But if the recipient still has to reconstruct context before acting, the automation hasn’t necessarily removed the bottleneck.

A useful workflow review should therefore ask two separate questions:

1. Does the next person have the information they need?

2. Are they actually ready and authorised to act on it?

That distinction can reveal very different automation opportunities.

Sometimes the problem is missing data.

Sometimes it’s ownership.

Sometimes it’s visibility.

Sometimes it’s decision authority.

And sometimes the handoff technically happened, but operationally it never finished.

Profile picture
Grayson JongProfile picture@grekkie·Sep 27

Where a workflow breaks matters more than where AI looks impressive

A lot of AI conversations start with the tool.

“What can we automate?”

But the better question is:

Where is the workflow actually losing time, information or ownership?

Take a maintenance request.

The problem might not be the repair itself.

It could start earlier:

  • incomplete information at intake

  • unclear urgency

  • nobody clearly owning the next step

  • context getting lost during a handoff

  • follow-up depending on someone remembering

  • an unusual case reaching a person without enough information to make a decision

If you automate before identifying that point, you may simply make part of the process faster while the real bottleneck stays untouched.

A better sequence is:

Map the workflow → find the friction → understand why it happens → decide whether AI is actually the right intervention.

That is the part of AI adoption I think deserves much more attention.

Where do you see workflows breaking most often in your own work — intake, handoffs, follow-up, exceptions, or somewhere else?

Profile picture
Grayson JongProfile picture@grekkie·Sep 25

One thing I’m changing about how I look for AI opportunities:

I’m not starting with tasks anymore.

I’m starting with failure points.

For example:

“Follow up with leads” sounds like one task.

But the real problem could actually be:

• The lead was never assigned

• The CRM status wasn’t updated

• A handoff was missed

• Nobody knew who owned the next step

• The automation kept running after a human should have taken over

Same task. Completely different problems.

My current test for a workflow is:

  1. Where does the information enter?

  2. Who owns the next step?

  3. Where does work wait or get repeated?

  4. What decisions need to stay human?

  5. What result can actually be measured?

If those things aren’t clear, adding AI might just make a messy process move faster.

For anyone building AI systems or automations: do you normally start by listing tasks, or by tracing where the process actually breaks?

Profile picture
Grayson JongProfile picture@grekkie·Sep 24

Before You Automate a Lead Workflow, Audit 10 Real Leads

A simple way to find an automation opportunity:

Don’t start with AI tools.

Take 10 recent leads and trace what actually happened.

For each lead, look at:

→ Where it came from

→ How long the first response took

→ Who became responsible for it

→ Whether follow-up happened

→ Whether the CRM was updated

→ Whether ownership changed

→ What the next action was

→ Where the lead eventually ended up

Then look for repetition.

Maybe response time isn’t the real problem.

Maybe agents respond quickly but follow-up becomes inconsistent.

Maybe follow-up happens, but the CRM is unreliable.

Maybe the CRM is fine, but ownership becomes unclear after a handoff.

That distinction matters.

Because each problem requires a different solution.

Sometimes automation is the answer.

Sometimes the workflow itself needs fixing first.

The goal isn’t to automate more. It’s to identify the exact point where time, information or opportunities are being lost.

That’s the type of thinking I’m continuing to build into AI Opportunity OS™.

What would you measure first in a real estate lead workflow?

Profile picture
Grayson JongProfile picture@grekkie·Sep 23

Automation Starts Before the Automation

A workflow can fail before the automation even starts.

Example:

A maintenance request enters the system:

“Water leaking.”

The temptation is to immediately automate:

→ classify it

→ route it

→ notify a vendor

→ update the tenant

But there’s a problem.

Where is the leak?

How severe is it?

When did it start?

Are there photos?

Can someone access the property?

Has the same issue happened before?

If the input is incomplete, the workflow creates more back-and-forth downstream.

So I'm testing a slightly different way of thinking about automation:

1. Capture the request

2. Check whether the information is complete

3. Collect what's missing

4. Then trigger the operational workflow

The interesting part isn't always replacing a manual task.

Sometimes the biggest opportunity is preventing unnecessary work from being created in the first place.

For anyone building automations: how often do you check input quality before designing the workflow?

Profile picture
Grayson JongProfile picture@grekkie·Sep 22

The Automation Gap Nobody Measures

A workflow can respond instantly and still be broken.

That’s something I’ve been thinking about while looking deeper into property and real-estate operations.

Take a new lead:

Lead arrives → instant reply sent → looks automated.

But then:

• The CRM record is incomplete

• Nobody clearly owns the lead

• The next follow-up isn’t scheduled

• The lead changes status but nobody acts on it

• The conversation eventually goes cold

Or maintenance:

Tenant reports issue → AI classifies it → vendor is contacted.

But has the vendor actually accepted the job?

Has an ETA been confirmed?

Has the tenant been updated based on something that actually happened?

This is why I’m starting to think “time saved” by itself is a weak automation metric.

Before automating a workflow, I’d rather map:

Source → Capture → Owner → Next action → Exception → Confirmation → Closure

Then measure things like response time, time-to-owner, missed follow-ups, unresolved age and incomplete records.

Automation should remove friction from a working process — not make a broken process move faster.

What workflow have you seen that looks automated on the surface but still breaks underneath?