2 Oct 2026
The AI workflow worked. The customer's workflow didn't.
A property manager already has a heating and cooling company she trusts. That company has serviced the building for years. There may be a maintenance contract, a history of repairs, and people who know the equipment.
Then a new automation sends somebody else.
The software has completed a task. The customer has a new problem.
That was the moment I kept coming back to after my conversation with Sally Hamidi, founder and CEO of ON Property Technologies, on Tech Break by Friday. Sally described a beta-launch lesson that reaches well beyond property management: before automating a workflow, understand the relationships and decisions inside it.
The assumption a beta customer challenged
Sally came to technology after years in HOA management, including owning and operating a management company. She knew what it felt like to balance inspections, board meetings, homeowner requests, and maintenance problems.
Even with that experience, she said her team initially overlooked an important customization: managers needed to choose their preferred vendors.
A beta customer made the gap clear. She did not want an unfamiliar contractor turning up when she already had someone responsible for that building’s maintenance.
Sally’s team responded by adding vendor preferences by trade and association. The lesson was specific. Existing service relationships were part of the workflow the product needed to support.
For founders, I think this is an excellent discovery question: What does your customer already know, trust, or have an agreement about that your automation cannot see?
The answer might be a maintenance contract. In another business, it could be an account owner’s approval, a customer’s communication preference, or an exception that has never made it into a process document.
Start with the delay that hurts someone
Sally used a roof leak to explain the operational problem she wants to solve.
A resident calls or emails. The manager is in a meeting or away from the phone. The message waits while the damage continues.
The opportunity is to shorten the path from a reported problem to someone taking action. In the workflow Sally described, a work order can be triaged to the building’s preferred vendor. The resident receives updates, the vendor communicates and documents the repair, and the manager can see what happened afterward.
This was an example of the intended workflow, rather than a measured customer case study. What made it useful was the clarity of the outcome: reduce time to resolution while keeping people informed.
When I look at an automation opportunity, that is where I want to start. Which delay is causing a real consequence? Who is waiting? What would a successful handoff look like?
A preferred vendor still needs a backup
Respecting a relationship does not mean waiting indefinitely.
Sally described a rule in which the preferred vendor gets the first opportunity. If that vendor is unavailable, the system can dispatch the job to other vendors in the area.
That gives the manager a way to express a preference without becoming responsible for every follow-up phone call.
It also makes the decision easier to inspect. You can ask who should receive the job first, what happens if they cannot take it, and what information the manager should receive.
Those are design decisions worth making before a workflow goes live. An instruction such as “find someone to fix this” leaves a lot of operational meaning unspecified.
Measure what happens on the job
We also discussed vendor accountability. Sally described several signals her team uses to understand performance:
* How quickly a vendor responds to a job.
* How many opportunities they miss.
* Whether they arrive and finish on time.
* How often they have to return to fix the same job.
* How industry professionals review their work.
The return visit matters. A job marked complete may still create more work if the repair was not done properly the first time.
My takeaway is to define success beyond the first completed action. For your own process, decide which signals show that the underlying problem was actually resolved. Track those alongside speed.
Keep the failure visible
Sally was candid about a beta work order that went to the wrong kind of vendor. A backflow-prevention issue was treated as a more general plumbing problem, even though the platform had a separate trade category for that work.
She said people still needed to oversee assignments. The system was not designed to be left entirely unattended.
That distinction matters when a workflow affects people’s homes. An automation can move quickly and still misunderstand the problem.
For me, this turns human oversight into a practical design task: decide who can see an assignment, who can correct it, and how the people involved will know that intervention is needed. Those are my implementation questions from the conversation, rather than claims that we verified every control inside the product.
A five-question check before you automate
Here is the checklist I would take into the next workflow discussion:
* What delay are we trying to reduce? Name the person waiting and the consequence of waiting.
* Which relationships or agreements must the workflow respect? Capture preferred providers, contracts, and existing responsibilities.
* What happens when the first choice is unavailable? Define the next step and the conditions for escalation.
* How will we know the work was done well? Include quality signals such as rework, as well as response time.
* Who can see and correct a mistake? Give a person the information and authority to intervene.
Sally’s advice to builders was to know the client, the pain point, and the details of the work. She also asked us to think about what a person gains from the product beyond time saved, including a deeper understanding of the problem.
That is a useful standard. When someone opens your system after a busy afternoon, can they understand what happened and what needs their attention?
Watch the conversation
Watch the Sally Hamidi conversation in the video above or on YouTube (https://youtu.be/-xPN-o2nkJA) and subscribe for more practical conversations about technology, operations, and building businesses.
Connect with Sally
* Sally Hamidi on LinkedIn (https://www.linkedin.com/in/sally-hamidi)
* ON Property Technologies (https://www.weareon.io/)
* OnCall PRO (https://www.weareon.io/solutions/oncall-pro)
* ON Property Technologies on LinkedIn (https://www.linkedin.com/company/on-proptech)
Connect with me, Paraskevi Kivroglou
* LinkedIn (https://www.linkedin.com/in/paraskevi-kivroglou/)
* AureliaEdge (https://www.theaureliaedge.com/)
* AureliaEdge on Instagram (https://www.instagram.com/theaureliaedge/)
Follow Tech Break by Friday
* Website (https://www.techbreakbyfriday.com/)
* YouTube (https://www.youtube.com/@paraskevikivroglou7838)
* Spotify (https://open.spotify.com/show/3c6KAQPQ54vxXUvLLRffC1)
* Apple Podcasts (https://podcasts.apple.com/us/podcast/tech-break-by-friday/id1796711716)
* Instagram (https://www.instagram.com/tech.break.by.friday/)
* Substack (https://kivroglouparaskevi.substack.com/)
If you want to put these questions to work in your business, start with an AureliaEdge Operations Audit (https://www.theaureliaedge.com/audit).
Where has an automation missed something your team already understood? Leave a comment with your experience or a question you would like me to explore in a future Q&A video.
Get full access to Tech Break by Friday at kivroglouparaskevi.substack.com/subscribe (https://kivroglouparaskevi.substack.com/subscribe?utm_medium=podcast&utm_campaign=CTA_4)
