Working prototypeClient work63 parser tests
WhatsApp crew groups, filed into monday.com by site and day
Your crews keep posting in their site groups. A listen-only number reads along and turns each day into one monday.com item per site: the day's status, finished work, open issues and photos, plus a daily site report. Attendance is worked out from the crew's own "Onsite" and "Offsite" messages. We built it as a working prototype for a wireless and telecom engineering firm.
AIAgenticBuilder.ca builds WhatsApp-to-monday.com capture like this for field crews at Canadian firms, as a custom build from $995.
- Built for
- A wireless and telecom engineering firm's field crews. Their site groups often have 15 people or more.
- Status
- Working prototype
- Listens to
- Every kind of message a group carries: text, photos, video, voice notes, files, emoji reactions. It posts nothing.
- Files to
- monday.com. Each group is a site with its own board; each day gets one item.
- Rules, not AI
- Attendance, hours per person, the shift day, issues opened and closed, downtime
- AI
- Optional. It groups the day's messages and drafts the day's summary. The prototype runs fine with it off.
- Tests
- 63 automated parser tests, built on a real crew conversation
Before
Why does the site record end up stuck in WhatsApp?
Because that's where crews already report. The arrival message, the install photos, the hold-up while someone waits for a coworker, the part that came in wrong: it all goes into the site's WhatsApp group, and it all scrolls away up the screen.
The office wants those facts sorted: which people were at which site and for how many hours, the work finished, anything holding the job up, and the photos sorted by site and date. Before this, someone had to read back through every group and type it all into the board. Often the photos just stayed on the phones.
Getting a field crew to switch apps is a losing fight. So we set one rule before writing any code: the crew changes nothing.
How it works
How do WhatsApp messages become monday.com items?
- join
Sit in each group, silently
A WhatsApp number used only for this is added to every site group, where it connects as a linked device. It reads; it never posts. Its privacy setting means only saved contacts can put it in a group.
- keep
Save everything
Each message is kept along with who sent it, when, and in which group: text, photos, video, voice notes, files. The group's name tells it the site. Nothing is filtered out at this stage.
- in/out
Work out attendance
A message that opens with the crew's arrival word starts an attendance record for that person and site; their departure word ends it. No departure message means the record stays open at zero hours, with no guessing.
- flags
Track issues and downtime
One emoji flags an issue on a message. Issues carry over from day to day until someone closes them, so you can see that something flagged on Monday took until Wednesday to clear.
- daily
Write one item per day
Each day gets one item on that site's board, carrying the day's status, the work done, the issues and the photos. Crew-on-site and hours columns are the next addition. The raw chat stays off the board.
- report
Put together the daily report
A short summary, what was finished, what's still open, and the day's photos in one log.
- health
Watch its own connection
When the connection drops or the number has to be paired again, it sends an alert to Microsoft Teams, Slack or a webhook. Never into WhatsApp.
The parser
What does the crew post, and what gets recorded?
No AI in this part. Plain rules, so every hour and every issue can be checked line by line.
| Crew posts | Recorded as |
|---|---|
| "Onsite" plus the site name, opening a message | Arrival: this person, this site, this shift day |
| "Offsite" plus the site name | Departure; the record closes and the hours are counted |
| ⚠️ on a message, or as a reaction to a photo someone posted | An open issue, pinned to that message |
| ❗ | A critical issue; in the cloud design, a fixed rule sends an alert |
| ⏳ then ▶️ | Downtime begins, then ends; not counted as working time |
| ✅ on the issue, or "solved" as a reply | Issue closed; if the match is unclear, it closes but is marked for a person |
Testing
What did a real crew chat teach us?
The parser's 63 automated tests lean on one real crew conversation, and many use the crew's exact wording. The prototype can replay that chat, all 31 messages and 7 photos, in a simulation mode.
Crews don't talk like the spec
Our first draft expected phrases like "arrived on site". This crew's actual habit was one word, "Onsite" or "Offsite", followed by the site name. The same chat also talked about an "existing unit on site", which a loose match would have read as somebody arriving. Now those words only count when they open a message.
Chatter isn't work
Under the first default, the parser filed 26 of 31 real messages (84%) as completed work, complaints and all. After the fix, 8 of 31 landed there, and every one of the 8 was actual work.
One message can mislead
Read alone, a morning post about waiting on a coworker looks like a blocker. He turned up 47 minutes later. So the AI summary waits until the day is over and reads all of it at once.
Night shifts break dates
A 22:00 to 02:00 job landed on two dates and showed half its hours on each. A shift-day setting fixed it: the whole shift now sits on one row.
Nobody types "issue:"
The first parser looked for "issue:" and found nothing, because nobody writes that. That's where the one-tap emoji flags came from. Field use of the flags is still untested.
Board names repeat
The monday.com account we tested had one board name used 10 times over. So boards are found by the group's fixed ID, never by their names.
Not fixed yet: restart the laptop version and it can make a second item for a day that already has one. The cloud design prevents that with keyed storage and a concurrency check.
Tools
WhatsApp to monday.com integration: what is it built with?
Running today
- The parser: a small set of plain functions, no dependencies, no AI. Feed it messages and it returns attendance, issues, downtime and day rows. The laptop prototype and the cloud design share it.
- Laptop prototype (Node.js): captures a chosen group live, warns when the number needs pairing again, replays the sample chat, syncs to monday.com and produces the daily report.
- Server version: one program meant for a small Linux machine. It keeps a local database, shows a web screen you can only reach over an SSH tunnel or VPN, syncs to monday.com, sends webhook alerts, and lets an AI assistant search the history without changing it.
Set up for production
- Azure, Canada Central, provisioned on September 1, 2026: Key Vault (purge protection on), Blob and Table Storage, a retrying Service Bus queue, monitoring, and one identity held to exactly four permissions.
- Planned shape: a receiver that never sleeps puts messages on the queue, workers parse and sync them, and opening the pairing page takes a Microsoft Entra ID sign-in, since its code works like a live credential.
- One deployment per company. No database is shared between customers.
Why not WhatsApp's official API? Meta's Groups API tops out at 8 participants. Its groups are made by the business and joined through an invite link, and its documented features include no way into a group that already exists (Meta's Groups API documentation). These crews' groups have 15 or more people, so the prototype takes a different route.
A read-only listener: a dedicated number joins each site group as a linked device, reads messages, photos and files, and never sends anything. We only ever use a dedicated number, never someone's personal one, and an alert fires the moment it disconnects. If you'd rather start fresh, crews can instead be moved into groups created through Meta's API, within its 8-person limit.
Status
Where does it stand today?
Working prototype
Works today
- Reading a chosen group live, on a laptop, without posting
- Replaying a real crew chat, photos included
- Writing day items onto a real monday.com board
- Producing the daily report: summary, issues, photo log
- The parser, covered by 63 tests
Not built yet
- The always-on receiver and workers in the cloud
- AI sorting and the end-of-day summary, running in Azure
- A PDF version of the daily report, weather, and a fleet dashboard
- Catching up on messages sent while the receiver was offline (not yet tested)
What AI does here
In the production design, AI does two jobs once a day, after the day is over: it puts the day's messages into categories and writes the day item's summary in plain sentences. It runs inside the company's own Azure tenant in Canada and hands back structured data, nothing else. On the laptop, simple keyword rules do the sorting unless someone connects OpenAI.
What AI doesn't do
- Work out hours, or who was on site
- Decide when an issue opens or closes
- Raise safety alerts; a fixed keyword rule does that
- Post anything, in WhatsApp or elsewhere
- Touch monday.com; every write is plain code
Because the model has no tools to call, the worst a hostile message could do is create a junk record, and a person reviews the board anyway.
For your firm
Could your crews' WhatsApp groups feed your monday.com board?
If your crews already post in one group per site or job, yes.
What it would connect to
- WhatsApp: the groups your crews already use, best as one per site or job
- monday.com: the board where you want each site's days
- Alerts: Microsoft Teams, Slack or a webhook of your choice
- Hosting: in Canada Central on your own Azure tenant, or on a small Linux machine you control
What we'd ask you for
- A phone number that does nothing but this
- Which groups to capture, and how you want the board laid out
- The words your crews already use when they arrive and leave
- Whether crews stay in their existing groups (the listener) or move to groups created through Meta's API
- A written notice for your crews, and a retention period for messages
A custom build, from $995
There's no ready-made connector for this, so the price is fixed in writing after the free prototype: one group feeding a test board, in a test setup. Hosting on your own Azure or server is billed to you. Designed with PIPEDA and Quebec Law 25 in mind; talk to your advisor about the notice your crews should get.
Questions
Questions about WhatsApp and monday.com
Will our crews have to post differently?
No. They keep using the same groups the same way. Arrival and departure are read from messages they send anyway, and the emoji flags are optional extras. Since the system can't post, someone in the office posts the flag key in each group and pins it, one time.
Can it post messages into our WhatsApp groups?
No, by design. The capture number reads and does nothing else. Alerts go to Teams, Slack or a webhook, and the server version has a test that breaks the build if any code path could send a message.
Why not use the official WhatsApp Business API?
Meta's Groups API tops out at 8 participants and only works with groups the business creates and people join by invite link. It can't read a crew group of 15 or more that already exists. So the prototype uses a read-only listener instead: a dedicated number joins each site group as a linked device, reads messages, photos and files, and never sends anything.
How are hours on site worked out?
When a message opens with the crew's arrival word, such as Onsite and the site name, an attendance record starts; the departure word, such as Offsite, ends it. Hours are the gap between them. If no one ever posts a departure, the record sits open at zero hours. It doesn't guess.
Is anyone using it on a job site yet?
No. It is a working prototype. On a laptop it reads a real group live, replays a real crew chat and puts day items on a real monday.com board. The cloud version that would run around the clock is designed, and its Azure base is in place, but nobody has built it yet.
Other monday.com builds
Your next step
Is your site record stuck in a group chat?
Book a free 30-minute call. We'll look at how one of your crew groups works and the board you'd want it filed into, and tell you plainly whether it's worth building.