signalSync
A chat bot that tells a field technician, in about thirty seconds, whether their test upload landed and whether it passed compliance — replacing a call to a supervisor who had to go look it up.
~0
jobs a day in scope
~0s
from question to answer
0
automated tests, all green
<$0
monthly running cost
signalSync
online
Illustrative. Real replies carry the client’s own compliance matrix.
The problem
Technicians finish an install and need to know one thing: did my equipment test upload, and did it pass? Getting that answer meant phoning a supervisor, who logged into a vendor portal and read a grid. signalSync turns that into a text message. Send a job number, get a plain-English verdict with the exact components that failed.
A technician cannot see the vendor's test-results portal — only supervisors have logins. So every check became a phone call.
Supervisors were interrupted dozens of times a day to read a row off a grid.
The compliance rules — which components must pass for which type of close-out — lived in someone's head, not in a system.
A wrong answer means a technician leaves a site that will be rejected later, and has to drive back.
How it was built
- 01
Meet them where they already are
No app to install, no account to create, no training. The technician texts a job number to a chat bot on the phone already in their hand. Six digits or sixteen — it works out which you meant.
- 02
Access is a list, not a login
The bot only ever answers an authorised phone number, verified once through the chat platform's own contact-share. Everyone else gets a polite refusal and nothing else — no data, no hints. The roster lives in a spreadsheet the client's own office edits; changes take effect within a minute.
- 03
Compliance rules encoded, not remembered
Which components must pass depends on the medium and the type of close-out. That matrix is now a tested data structure, generalised across both media the client works in. Where the meter simply does not report a value, the bot says so as information rather than pretending it is a failure.
- 04
The portal has no API, so it gets driven
The lookup runs a real browser session against the vendor portal, reusing it across requests for speed. That reuse caused a genuinely subtle bug — a date filter that silently froze, so a job finished an hour ago read as "not found". Fixed with a two-pass search and a forced re-selection, unit-tested, then verified against a live same-day job.
The hard parts
Anyone can build the easy version. These are what the project was actually about.
Vendor portal, no API, no MFA to lean on
Everything comes out of a browser session. That means treating a UI as an interface: pure, unit-tested logic for anything that can be tested off-portal, and a narrow, replaceable adapter for the part that cannot.
A swappable lookup interface from day one
The chat layer never touches the portal directly. It calls a frozen interface that shipped with a stub on day one and got its real implementation later — so the bot was demoable before the data source was even settled.
Where it landed
- The supervisor phone call is gone. Technicians self-serve in about thirty seconds.
- A failed test is caught before the technician leaves the site, not after.
- The compliance matrix is now written down, testable, and changed with a code review instead of a conversation.
- Built for a few hundred dollars and running for less than twenty a month.
Built with
Bot
Lookup
Access
Quality
Your turn
Got a process this shape?
Thirty minutes is usually enough to tell whether it’s worth building.
Tell me the thing your team retypes every week.
Thirty minutes, no pitch. I’ll tell you whether it’s worth automating, roughly what it would cost, and if the honest answer is “don’t bother” — you’ll hear that too.
hello@clearpathflow.io · Raleigh-Durham, NC