CityPeak
A site manager photographs a handwritten defect list. Ninety seconds later every defect is a separate task, sorted by trade and urgency, waiting on one person to approve it.
The problem
CityPeak is not a real company. It came as a client file in an AI automation course - five staff interviews and a spreadsheet. Every number below is theirs; nothing here was deployed.
A site manager lists defects on paper, photographs the form and emails it in. Someone at the office retypes every line into the task board.
30 min
to retype one form, at 75 ₪ an hour
800 forms
a month
₪200,000
in late-handover penalties, in the six months before the brief
The retyping is not the expensive part. Every day a defect sits between the site and the system is a day closer to a penalty.
Mapping the Bottlenecks
The audit revealed three major operational bottlenecks. The rejection protocol was chosen for its highest ROI and clear AI fit:
Tenant inquiries
800 free-text messages a month, sorted by hand. ₪360K a year.
Invoice matching
Supplier PDFs checked against the CRM by eye. 10% paid wrong.
Rejection protocol
₪400K a year, and the only one where the input is handwriting. Highest cost, clearest case for AI.
Who it was for
Two people touch this and they want opposite things.
- The site manager has one hand free on scaffolding. Anything that asks him to type is a form he won't fill in.
- The technical secretary gets the call when a wrong task reaches a contractor. Anything that writes to the task board without her is a system she won't trust.
I interviewed neither. They are read off the brief's transcripts - a step above invention, and well short of research.
The solution
Photo in, tasks out. The only step that isn't automatic is the one I left there on purpose.
Telegram as the front door
He already has it open, and it sends a photo without installing anything.
Handwriting, not a form
The paper list stays as it is. The system adapts to the site.
One row per defect
The photo becomes eight tasks, not one attachment.
A parallel alert
Three or more critical defects pings the VP while the rest of the flow keeps running.
Key decisions
The approval step is the product, not the training wheels
Most automation writing treats the human check as the thing you remove later. I built the flow around keeping it: the agent drafts, a person commits.
What it cost: the scenario can't finish alone. A run nobody approves ends as a Slack reminder. I'd keep it anyway.
The escalation path was swallowing the work
Critical overload branched through an If/Else, so it alerted the VP instead of processing the list. The most urgent forms were the only ones that never reached the task board.
What it cost: nothing to fix, once I saw it. I caught it on a run that finished clean and empty. I built the calm path first, which is exactly backwards.
A router before the crash, not an error handler after it
The download step pulled photo[4], Telegram's largest thumbnail. Every test image had five sizes until one had two, and the run died. Now it takes whatever the largest actually is.
What it cost: two extra modules on every run. Worth it - that failure looks identical to the system ignoring a site manager.
Free tools, and what that decided
Cloud Vision's handwriting OCR is free to 1,000 images a month and Make's agent classifies without a key of my own. This build costs nothing to run.
What it cost: I never compared it against a paid model on the same forms. The model choice is an assumption here, not a finding.
Where it stands
The scenario runs end to end. I have sent it photographs of real handwritten defect lists and watched the rows appear.
The course asked for Google Sheets, so the last step is the right shape pointed at the wrong system. One field rename away; not built.
A Make run is linear - it can't pause for forty-five minutes and resume. Production needs a second scenario, triggered by the approval itself. I know what that looks like. I didn't build it.
It's the brief's numbers times my own assumption about how much delay this removes. Nobody has measured it, because nobody has used it.
What I'd do differently is what the escalation bug already told me: build the overloaded path first. A system that exists for bad days should be designed on one.
Let’s build something great together.
I'm currently exploring new opportunities in Product Design and UX Research.
My LinkedIn profile