FieldproxyIntegration guide · ZendeskZendesk for the ticket, Fieldproxy for the visit, and every update back on the ticket
Keep Zendesk as the support desk and connect it to a field service system for the part Zendesk was not built for: the visit. A ticket that needs someone on site becomes a job with the requester, organization, site, priority and ticket ID carried across. The job is dispatched by skill, location and SLA, the technician completes it on a phone app with required photos and checklist items, and status, notes and the visit report are written back to the same ticket. Support never leaves Zendesk, and the field team never works from a copied email.
Fieldproxy replaces the field side: dispatch, the technician app, checklists, stock, service agreements and invoicing. It does not replace Zendesk, and it is not a layer on top of other field software. Set up for you, live within a day, with unlimited users on one price per company.
See your Zendesk tickets turn into jobs
Tell us how a ticket becomes a visit today. We set it up on your own fields and job types before you commit.
The gap
Zendesk tracks the conversation. Nobody tracks the truck.
Zendesk is good at tickets: who asked, what they asked, how fast you answered. It was not built to decide which engineer goes, carry the site's access rules to a phone, force a photo of the main panel before a job closes, or count the parts that left the van. So teams fill the gap with a spreadsheet, a WhatsApp group and an agent who copies ticket details into a dispatch email.
The same questions came up on our sales calls with helpdesk-led field teams: EV charger maintenance, IT support for multi-site customers, equipment service. These are their words, anonymised.
“We've purchased Zendesk, so Zendesk is running, so presently we are pulling all of the site-related data into Zendesk.”
“The team managing the Zendesk activity also need to know about site restrictions or access or anything like that as well.”
“If an integration was live, the ACID tag would flow through from the ticket to Fieldproxy and then back.”
“Can we make those… parts of the checklist mandatory so that they can't pass…”
“I'm concerned that engineers could look through assigned jobs and not necessarily know what needs to be addressed first.”
How it works
From Zendesk ticket to finished visit, step by step
This is how a typical setup runs. The trigger, the job types and which updates go back are agreed with you.
- 1
A ticket needs a visit
Zendesk agent, or a rule
An agent sets a tag or a custom field (for example Needs site visit), or a rule picks it up from the ticket form. Tickets that can be fixed remotely stay in Zendesk. - 2
The job is created with the ticket's context
Fieldproxy
Requester, organization, site, priority, description, attachments and the ticket ID are copied onto a new job. The organization is matched to the customer and the site field to the site record, with its address, access rules and asset list. If a match fails, the job waits for the office with the reason. - 3
The right technician is picked
Dispatcher, helped by the Dispatch agent
The Dispatch agent ranks technicians by skills and certifications, where they will be, free time, van stock and the SLA due-by time. The dispatcher confirms, or routine job types are assigned by rule. Changes are previewed and can be undone. - 4
The ticket hears about it
Fieldproxy, written to Zendesk
An internal note on the ticket says who is going and when. Support can answer the customer without asking anyone. - 5
The visit runs on the phone
Technician, Android or iOS app
GPS check-in on arrival, the site's access notes, the asset's history, the checklist for this job type with required photos and readings, parts used from van stock, and the customer signature. The app works offline and syncs when signal returns. - 6
Proof and status go back to the ticket
Fieldproxy, written to Zendesk
The technician's notes, the visit report with photos and signature, and the completion status are written back to the same ticket. If a return visit or a quote is needed, the ticket says so and stays open. - 7
Finance gets the job, not an email
Fieldproxy to your accounting system
Labor, parts and charges on the completed job sync to NetSuite, QuickBooks, Xero or Sage, or an invoice goes out from Fieldproxy with a payment link.
What syncs
What moves between Zendesk and Fieldproxy, which way and when
A typical mapping. Your Zendesk custom ticket fields are mapped one by one at setup, so a field called Site ID or Charger serial in your account lands on the right record.
Field updates go in as internal notes by default, so the customer only hears what an agent decides to send, or what your own Zendesk triggers send when the status changes. If you want the customer to get a public reply at a certain step, that is set per job type.
| What | Direction | When | Detail |
|---|---|---|---|
| Ticket ID | Both ways | On creation, then on every update | Job reference, kept on the job and every visit. Both ways: the job always links back to its ticket, so updates land on the right one. |
| Requester | Zendesk → Fieldproxy | When the ticket is sent to Fieldproxy | Site contact on the job. Name, email and phone, so the technician can call ahead. |
| Organization | Zendesk → Fieldproxy | When the ticket is sent to Fieldproxy | Customer. Matched to an existing customer, or flagged for the office if no match is found. |
| Site or asset custom fields | Zendesk → Fieldproxy | When the ticket is sent to Fieldproxy | Site and asset. Site ID, address, access rules and asset tag, matched to the site record and its history. |
| Priority and SLA policy | Zendesk → Fieldproxy | When the ticket is sent to Fieldproxy | Job priority and due-by time. Drives dispatch order and the SLA clock the field team sees. |
| Subject, description and tags | Zendesk → Fieldproxy | When the ticket is sent to Fieldproxy | Job description and job type. Tags or a custom field can set the job type, which decides the checklist. |
| Attachments | Zendesk → Fieldproxy | When the ticket is sent to Fieldproxy | Job files. Photos or PDFs the customer sent are on the job before anyone travels. |
| Assigned and scheduled | Fieldproxy → Zendesk | As it happens in the field | Internal note with technician and time window. Support can answer "when is someone coming?" without asking the field team. |
| On the way and on site | Fieldproxy → Zendesk | As it happens in the field | Internal note, with GPS check-in time. Arrival is proven by the check-in, not by a phone call. |
| Work notes and findings | Fieldproxy → Zendesk | As it happens in the field | Internal note. What was found and done, written by the technician on the phone. |
| Visit report | Fieldproxy → Zendesk | As it happens in the field | Attached PDF or link. Photos, completed checklist, readings, parts used and the customer signature. |
| Follow-up needed | Fieldproxy → Zendesk | As it happens in the field | Internal note and status change. A return visit or a quote is raised from the job, and the ticket says so. |
| Completed | Fieldproxy → Zendesk | As it happens in the field | Ticket status change, e.g. to Solved. Only when the job's required items are done; which status you use is your rule. |
| Time on site and mileage | Fieldproxy → Zendesk | On completion; mileage per trip | Recorded in Fieldproxy from GPS check-in, check-out and trips, and rolled into mileage claims. Adding them to the ticket's note is set up per account. |
Whether updates reach Zendesk by webhook or polling, and whether agents also see the job in a ticket sidebar, is set up per account.
See your own Zendesk tickets turn into jobs before you commit.
Get DemoWhat stays, what moves
Zendesk keeps the tickets. Fieldproxy replaces the field tools.
The most common follow-up on support-led teams is a customer asking "was anyone actually here, and what did they do?" The answer should be on the ticket before they ask. Everything that produces that answer lives in Fieldproxy; the conversation stays in Zendesk.
Stays in Zendesk
- Customers raise tickets by email, chat, phone or web form.
- Agents answer customers and own the conversation.
- Your Zendesk triggers, macros and SLA policies for support.
- Ticket reporting and CSAT for the support team.
- The ticket stays the record both teams look at, with the field story written onto it.
Moves to Fieldproxy, and what it replaces
Sites, assets and access rules
Each site carries its address, access hours, keys and restrictions, safety documents and the assets installed there, with every past visit on each asset. The fields support needs can be shown on the ticket too, so both teams see the same restrictions.
Planned maintenance (PPM)
Service agreements create recurring visits on their own schedule, with the checklist for that visit type. They don't need a ticket. When a planned visit finds a fault, a ticket can be raised or updated.
Van and warehouse stock
Parts sit in warehouses and vans, move when they are used on a job, and are reordered on purchase orders. The dispatcher can see who has the part before assigning.
Contractors
Regular contractor crews get a login, one-off contractors get a job link. They see only their jobs and never need a Zendesk seat. Unlimited users means no seat count to manage.
Quotes and invoices
Good, better and best quotes the customer approves online, invoices with payment links through Stripe, and sync with QuickBooks, Xero, Sage or NetSuite.
Your own stages and forms
Job stages, forms and statuses are set up around how you work, in 27 languages, not a fixed template. Changes later are a conversation, with a confirm step and Undo.
Mileage sheets and timesheets
GPS check-in and check-out sit on the job, and drives between jobs roll into a mileage claim a manager approves. See GPS timesheets and mileage.
Ask it from Claude, ChatGPT or Copilot
Fieldproxy has its own MCP server: anything you can do in the app, such as finding the jobs waiting on a visit or raising the invoice, can be done from Claude, ChatGPT or Copilot, with a confirm step before any change.
Worked example, demo data
A lift fault at an office block, ticket to solved
Say Brackenridge Lift Services maintains passenger lifts in office buildings and runs support in Zendesk, with a custom ticket field for the lift's asset tag.
- 1
The ticket
Ticket #77120 from the facilities manager at Quayside House: "Lift 2 stuck on floor 4, doors won't close." The agent tags it Needs site visit; the asset tag field says LFT-QH-02. - 2
The job
Fieldproxy matches the organization to the customer, Quayside House to its site (sign in at reception, plant room key from security) and LFT-QH-02 to the lift, with its last two visits. The SLA policy's due-by time is on the job. - 3
Dispatch
The Dispatch agent ranks Joel first: certified for that lift range, 20 minutes away, with a door operator belt in his van. The dispatcher confirms, and an internal note on the ticket says Joel, ETA 10:50. - 4
The visit
Joel checks in at 10:46 (internal note with the check-in time), replaces the worn belt, works the door test checklist with required photos, and gets the facilities manager's signature. - 5
Back to Zendesk
His notes and the visit report PDF go to the ticket as an internal note, and the ticket moves to Solved under your rule. The agent sends the customer a one-line reply. - 6
Afterwards
The belt comes off Joel's van stock and is reordered; the labour and part sync to the accounting system for invoicing.
Result: The facilities manager had proof of the visit on the ticket the same morning, the agent never chased the engineer, and the lift's history shows the belt change for the next visit.
Names, sites and ticket numbers in this example are made up to show the flow. They are not a customer and not a result.
Visit proof
A job can't close until the proof is there
Required checklist items
Each job type has its own checklist. Mark items, readings and photos as required, and the job can't be completed until they are done. Conditional items appear only when they apply.
Photos with time and place
Before and after photos, taken in the app at the site. Photos that must show something specific (a panel, a serial plate, a cleared fault screen) can be checked by the Vision agent.
GPS check-in
Arrival and departure times come from the phone's location at the site, so the time on the report matches the time on site.
Signature and name
The site contact signs on the phone. The signed report goes onto the job and back to the ticket.
Parts and readings
Parts used come off the van's stock, and readings are captured in fields, not free text, so they can be reported on later.
Overdue and missed
The Watcher agent flags jobs about to breach SLA, missed visits and readings out of range, so a breach shows up before the customer reopens the ticket.
The options
Four ways to run field visits from Zendesk tickets
Described by kind of tool, not by vendor. Each fits some teams; check the trade-offs against how your visits actually run.
| Approach | Fits when | What you give up |
|---|---|---|
| Zendesk alone, with custom fields, macros and a spreadsheet | A handful of visits a week, all by your own staff, no stock or planned maintenance | No technician app, no required photos or checklists, no schedule view, no van stock. Dispatch lives in someone's head. |
| A field service app from the Zendesk Marketplace | Support agents schedule their own technicians and want to stay inside Zendesk | Check what it does offline, whether checklists can be required, and whether it covers PPM, stock, contractors and invoicing. Many are scheduling add-ons, not full field systems. |
| The field service module of your ERP | Finance owns the process and the ERP already holds assets, stock and billing | You still need a Zendesk connection, and ERP mobile apps and licences for contractors are often the weak spot. |
| A configurable field service system connected both ways (Fieldproxy) | Visits need their own checklists, sites have access rules, contractors do some of the work, and finance runs a separate system | A second system to run. It replaces your field tools, so plan the switch-off date for the spreadsheet and the old app. |
From a sales call
EV charger maintenance behind Zendesk
A charge point maintenance team bought Zendesk for support and kept site data in its custom fields. Finance runs NetSuite. They needed the field side: engineers, SLAs, planned maintenance and parts.
- Faults: a customer or the monitoring platform raises a ticket; it becomes a job with the site ID and charger serial carried across.
- SLA: the ticket's priority sets the due-by time, and the job list shows engineers which jobs are closest to breach first.
- Planned outages: when a site owner reports one, it is logged against the site so nobody is dispatched to a charger that is off on purpose.
- PPM: maintenance contracts create the planned visits, with a checklist per charger type.
- Mandatory evidence: photos of the unit, the fault screen and the repair are required before the job closes.
- Parts: fans, boards and cables come off van stock and are reordered on purchase orders.
- Money: completed jobs sync to NetSuite instead of manual submissions to finance.
Workflows
Zendesk and Fieldproxy, workflow by workflow
Auto job creation from tickets
A ticket that needs a truck becomes a dispatchable job, with the ticket context carried across.
Field dispatch automation
Match the ticket to the technician by skill, certification and location instead of by whoever is free.
SLA compliance workflows
Response and resolution targets by priority or customer tier, with a warning before the breach.
Ticket resolution tracking
Jobs keep a permanent link back to the source ticket, so support sees the field outcome.
Multi-channel support
Email, chat and phone all land as tickets that can start field work the same way.
Customer satisfaction surveys
Post-visit surveys sent after the job, scored against the technician and the job type.
For a worked example of ticket-led dispatch with GPS and mileage, read how to dispatch technicians from helpdesk tickets.
Setup
Connected, set up around your queues, live within a day
The Zendesk side needs an admin for a few minutes. The rest is done by Fieldproxy's team.
- 1
A 30-minute call
Which tickets become visits, which custom fields matter, what goes back to the ticket and who sees it, and how a job is done on site. - 2
Connect Zendesk
Your Zendesk admin authorizes the connection. We map ticket fields, tags and statuses to jobs, and agree how new tickets reach Fieldproxy. - 3
Build the field side
Job types, checklists with required items, sites and assets, technicians with skills, van stock and your invoice or finance sync. Site and asset data comes across with free, assisted migration. - 4
Test on real tickets
Send a few real tickets through, complete them on the phone and check what lands back in Zendesk. Then go live.
Moving off a spreadsheet or another field app? Sites, assets, customers and open jobs come across with free, assisted migration. Fieldproxy is one price per company with unlimited users, so support agents, dispatchers, technicians and contractors can all log in. See pricing.
Fit
Who this is for, and when it isn't the right fit
A good fit when
- Support runs in Zendesk and some tickets end in an engineer on site: EV chargers, lifts, IT hardware, building equipment.
- Sites have access rules and assets with a history that both support and the field need to see.
- Jobs need mandatory photos, checklists and signatures before they close.
- Contractors do some visits, planned maintenance runs beside reactive tickets, and finance runs a separate system.
Probably not the right fit when
- Every ticket is solved remotely; Zendesk already does the job.
- A handful of visits a week by your own staff, with no stock or planned maintenance.
- Your agents want to schedule technicians without ever leaving the Zendesk interface; a Marketplace scheduling app may suit you better.
- You want to replace Zendesk itself. Fieldproxy keeps it as the support desk.
Straight answers
Zendesk and field service: questions we get asked
Can a Zendesk ticket create a field service job automatically?
What does the Zendesk agent see after the job is created?
Does the ticket ID stay the same across both systems?
Can checklist items and photos be mandatory before a job closes?
Where should site and asset data live, Zendesk or the field service system?
What about planned maintenance that never starts as a ticket?
Do contractors need a Zendesk seat or a paid Fieldproxy seat?
How does invoicing work if finance runs NetSuite?
How long does it take to connect?
Can I ask Claude or ChatGPT about field jobs that came from Zendesk tickets?
Related
Where to go next
Every helpdesk Fieldproxy connects to follows the same pattern: the ticket stays where it is, the visit runs in Fieldproxy, and the result goes back. The same flow for Freshservice, Freshdesk, Zoho Desk and ServiceNow.
Keep Zendesk. Give the visit a proper home.
Tell us how a ticket becomes a site visit today. We show it running on your own fields and job types.
Get DemoLive within a day. Free, assisted migration. Unlimited users on one price per company.