• Replies 13 replies
  • Subscribers 2 subscribers
  • Views 21 views
  • Users 0 members are here
Options
Related

Anyone experimenting with AI or automation alongside FieldPulse?

Eli Torres (Staff)

Hey folks — Eli here from the dev side of the house. Been tinkering with some automation workflows around FieldPulse and got curious what the rest of you are up to.

I've got a little side experiment going where I'm using a webhook → work_order.status_changed → triggering a GPT-4 call to auto-draft customer follow-up emails based on the job notes. It's... surprisingly not terrible? The prompt engineering is the hard part, honestly. Getting it to sound like "us" and not a robot took some iteration.

Also played with:

  • Auto-categorizing photos from the mobile app (sending to a vision API to tag "panel photos" vs "wiring photos" etc)
  • Slack bot that summarizes the day's completed jobs and flags anything with suspiciously short duration
  • Trying to extract parts lists from free-form technician notes — this one is still pretty rough, edge cases everywhere

Yeah this one tripped me up too when I first looked at it — the webhook payload doesn't include the full job history, so if you need context from previous visits you're doing extra API calls. Worth keeping in mind if you're building something similar.

Anyway, curious if anyone's actually production-ized anything AI-adjacent on top of FieldPulse, or if it's all still weekend experiments like mine. What's working? What's a waste of time?

Parents

  • YMMV on this one, but I've got a Make scenario running that pulls completed jobs every hour and feeds them into a small classification model we trained. Basically trying to predict which jobs are likely to generate a callback based on tech notes, time of day, and parts used.

    Heads up: the webhook reliability for high-frequency jobs is not amazing, so we batch it instead. Worth noting that FieldPulse's rate limiting on the read API (100 req/min last I checked) becomes your bottleneck real fast if you're trying to hydrate a lot of historical data.

    Here's what worked for me:

    // webhook receiver → queue in Redis → worker processes batches
every 15 min: fetch /work_orders?status=completed&since=${last_run}

    The model's only about 70% accurate so far, but it's enough to flag jobs for QA review. Small wins.

  • in reply to Devon Marsh

    About 8 months of historical before I trusted it enough to surface to dispatchers. The feature engineering was way more important than model choice — stuff like "ratio of estimate to actual time" and whether the customer had a prior complaint were stronger signals than I expected.

    And lol yeah, webhook race conditions are a thing. I ended up adding a 5-min delay buffer before processing, which defeats some of the "real-time" promise but saves sanity.

Reply
  • in reply to Devon Marsh

    About 8 months of historical before I trusted it enough to surface to dispatchers. The feature engineering was way more important than model choice — stuff like "ratio of estimate to actual time" and whether the customer had a prior complaint were stronger signals than I expected.

    And lol yeah, webhook race conditions are a thing. I ended up adding a 5-min delay buffer before processing, which defeats some of the "real-time" promise but saves sanity.

Children
No Data