Software that turns customer requests into jobs takes an email, a form submission, or a forwarded message and creates a tracked job. That job has an owner, a due date, and the original request attached, so nobody retypes anything and nothing gets lost. The distinction that matters is where the request ends up. Some tools create jobs your crew actually works from. Others create tickets in a separate helpdesk that nobody on site opens. Pick the tool where the request lands on the same board as the work.
TL;DR:
- The useful version of this software puts customer requests on the same board your team already works from, not in a separate ticket queue.
- Email and a public web form cover most small-business intake. Phone calls still need a human to forward a note or fill in the form.
- Good intake handles the boring failures: duplicate emails, lost threads, and auto-replies that bounce back and forth forever.
- Per-seat pricing punishes you for giving the office, the crew, and subcontractors access, and that access is the whole point of shared intake.
- AI can draft jobs from messy requests, but a person should approve every one before it hits the schedule.
Table of Contents
- Why Customer Requests Die Between the Inbox and the Board
- What Software That Turns Customer Requests Into Jobs Actually Has to Do
- Email, Web Forms, or Phone: Which Intake Channel to Build Around
- The Auto-Reply Loop, and Other Ways Intake Breaks
- Helpdesk, Per-Seat Project Tool, or Flat-Fee Job Board: Which to Pick
- Where AI Fits in Request Intake, and Where It Shouldn't Decide
- Keep the Request Data Lean, Because You Have to Look After It
- Turn Every Forwarded Email Into a Tracked Job for $399, Once
- Frequently Asked Questions
- Sources
Why Customer Requests Die Between the Inbox and the Board
Most small businesses don't lose customer requests through laziness. They lose them in the gap between where requests arrive and where work gets tracked. The email comes into the office inbox. Someone reads it, means to add it to the board, gets a phone call, and the email scrolls off the first screen. Three weeks later the customer calls back, annoyed, and the request is still sitting there marked as read.
The fix is not "be more careful." That fails the moment the office gets busy, and busy is exactly when the most requests come in. The fix is removing the retyping step. When a request turns into a job by itself, or with one forward, the gap closes.
Retyping causes a second problem too. Every time someone copies a request onto the board by hand, details drop out: the gate code, the second phone number, the photo of the leaking pipe. The crew then calls the customer to ask for things the customer already sent. That's how one email turns into four calls, and how a competent business looks disorganized.
What Software That Turns Customer Requests Into Jobs Actually Has to Do
Plenty of tools claim to "capture requests." Very few pass all five of these tests, and you should check every one before you pay for anything.
It creates a job, not a note
The output has to be a real job, with a status, an assignee, a due date, and a place on the board. If the request lands as a comment, an attachment, or an item in a separate "requests" area, someone still has to convert it. That conversion step is the step you were trying to get rid of.
One request becomes one job
Customers send the same request twice. They reply to their own email with "also, the side door." Two people in the office forward the same message. Good intake software catches this. Every properly formed email carries a unique Message-ID header, as defined in the IETF's RFC 5322 internet message format standard. Replies point back to earlier messages through the In-Reply-To and References headers. Software that reads those headers can attach follow-ups to the existing job instead of creating duplicates. Software that ignores them leaves you with three jobs for one leaking tap.
The original request stays attached
The job should carry the customer's actual words, any attachments, and their contact details. A summary is fine as the job title. It is not a substitute for the source. When there's a dispute about what was asked for, the original email settles it.
It shows what's holding the job up
A request rarely becomes a job you can start right away. It's waiting on a quote approval, a part, a permit, or another job finishing first. If the software can't show that dependency, the job looks ready when it isn't. Then someone books a crew for a site they can't work on yet.
The right people can see it
The person who reads the request is usually not the person who does the work. Office staff, site leads, and subcontractors all need to see the job. If adding each of them costs money every month, you'll end up rationing access. That puts you right back to relaying information by phone.
For a broader look at what the tracking side needs once a job exists, see our breakdown of what job tracking software actually needs to do.
Email, Web Forms, or Phone: Which Intake Channel to Build Around
You don't need every intake channel. You need the two or three your customers actually use, wired up properly. Here's how the common ones compare for a small trades or office team.
| Channel | How it becomes a job | Data quality | Effort for your team | Verdict |
|---|---|---|---|---|
| Email to a dedicated address | Automatic, or one forward | Messy but complete | Low | Build around this |
| Public web form | Automatic | Structured, consistent | Very low | Build around this |
| Forwarded from a staff inbox | One forward | Messy but complete | Low | Good backup |
| Phone call | Staff fill in the form or send a note | Depends on who answered | Medium | Unavoidable; route through the form |
| Text or chat messages | Usually manual copy | Fragmented | High | Avoid as a formal channel |
Pick email plus a public form. Email catches the customers who will always just email you. The form catches new customers and gives you structured data: the address, the type of job, and a preferred date, every time, in the same fields. For phone calls, have whoever answers fill in the same public form. Then a phone request looks exactly like every other request, instead of living on a sticky note.
Pro Tip: Set up a dedicated intake address, such as jobs@ or requests@, rather than using one person's inbox. When that person goes on holiday or leaves the business, intake keeps working. You also stop the slow drift where "the system" quietly becomes "whatever Dave remembers."
The Auto-Reply Loop, and Other Ways Intake Breaks
Automated intake has failure modes that hand-copying never had, and you should know them before you switch anything on.
- Auto-reply loops. Your intake address sends "Thanks, we've received your request." The customer's out-of-office replies to that. Your system logs the reply as a new request and responds again. You now have two machines talking to each other.
- Newsletters and notifications becoming jobs. If the intake address ends up on a mailing list, every promotional email turns into a job. Keep the address for requests only, and filter out obvious bulk mail.
- Forwarded chains losing the original sender. When staff forward an email, some tools record the staff member as the "customer." Check that the original sender's address survives the forward.
- Attachments silently dropped. Photos are often the most useful part of a trades request. Test with a phone photo before you trust the setup.
The auto-reply problem has a standard solution. The IETF's RFC 3834 on automatic responses to email defines an Auto-Submitted header that marks messages sent by machines rather than people. A well-behaved responder checks for that header and stays quiet.
RFC 3834 says an automatic responder should not reply to any message whose Auto-Submitted header says anything other than "no." If your intake tool ignores that one header, it will eventually argue with someone's out-of-office until a mailbox fills up.
Test this yourself before go-live. Turn on your own out-of-office, send a request to the intake address, and see what happens.
Helpdesk, Per-Seat Project Tool, or Flat-Fee Job Board: Which to Pick
There are three broad kinds of software that turn customer requests into jobs. They suit very different businesses.
| Approach | Where requests land | Who can see them | Typical cost shape | Best for |
|---|---|---|---|---|
| Helpdesk / ticketing | A support queue | Support staff | Per agent, monthly | Businesses whose "job" is answering a question |
| Per-seat project management | The project board | Whoever you pay for | Per user, monthly | Teams with a fixed, small headcount |
| Flat-fee, self-hosted job board | The project board | Everyone | One-time license plus your hosting | Trades and office teams with crews and subs |
A helpdesk is the wrong tool if your jobs involve trucks, materials, and site visits. Tickets are built to be answered and closed. Jobs are built to be scheduled, staffed, blocked, and finished. Forcing one to act as the other means running two systems and copying between them, which is the retyping problem again with a bigger invoice.
Per-seat project tools work well until you do the math on giving everyone access. This kind of intake only works when the people doing the work can see the requests. That includes the office, the site leads, and the subcontractors who are on two jobs a month.
At a hypothetical $12 per seat per month, 12 people cost $1,728 a year, every year. A $399 one-time license pays for itself in under three months.
Our position is simple: if your team includes crews or subcontractors, pick a flat-fee board. The per-seat model charges you more for exactly the behavior that makes intake work, which is letting more people see the jobs. Self-hosting is a real trade-off, though. You run the server, and you own the backups. We lay out those costs honestly in the real math on self-hosted project management, and in what you're choosing with self-hosted task management.
Where AI Fits in Request Intake, and Where It Shouldn't Decide
Customer requests are messy. "Hi, the thing at the back is doing that noise again, can someone come Thursday-ish" is a real job. It's just not a well-formed one. Turning that into a titled job with a likely type and a suggested date is useful work, and language models are decent at it.
The safe pattern is suggest, then approve. The AI drafts the job. It proposes a title, pulls out the address and phone number, and flags that "Thursday-ish" is a preferred date, not a commitment. A person then accepts, edits, or rejects it. Nothing reaches the schedule without a human clicking yes.
Connecting AI assistants to your job data is getting more standardized. The Model Context Protocol is an open protocol for connecting AI applications to outside tools and data sources. A project tool that exposes an MCP server lets an assistant read your jobs and propose new ones without you copying and pasting between windows.
Don't let AI auto-create jobs, assign crews, or reply to customers with promised dates. The cost of a wrong guess is a truck at the wrong site. Having someone review a draft takes seconds, and that's a cheap insurance policy.
Keep the Request Data Lean, Because You Have to Look After It
A public intake form is tempting to overbuild. Resist that. Every field you add is data you now store, protect, and eventually have to delete.
If you have customers in the EU or the UK, the data minimisation principle in Article 5 of the GDPR requires personal data to be "adequate, relevant and limited to what is necessary" for the purpose. Article 5 also says you shouldn't keep it longer than you need it. Even outside those jurisdictions, it's sound practice. You can't leak what you never collected.
For most trades and office requests, the form needs these fields:
- Name and one contact method. Phone or email, not both as required fields.
- Job location. This is what makes a request schedulable, so make it required.
- What's wrong or what's needed. A free-text box, plus an optional photo upload.
- Preferred timing. Label it clearly as a preference, not a booking.
Skip date of birth, company size, "how did you hear about us," and anything else that's really marketing data dressed up as intake.
Turn Every Forwarded Email Into a Tracked Job for $399, Once
ReplaProject closes the inbox-to-board gap this article describes. Forward an email, or let a customer fill in the public intake form, and the request becomes a job. It lands on the same board, table, and calendar your office and crews already use. Automatic dependency detection shows what's holding each job up, so a request waiting on a quote doesn't look ready to schedule. The AI assistant and MCP server can draft jobs from messy requests, and a person approves every one before it goes live.
It costs $399 flat, with unlimited people, so the subcontractor who's on two jobs a month doesn't need a seat budget. The honest caveat: ReplaProject is self-hosted. You set up the server and the intake mailbox, and backups are your responsibility. Run the out-of-office test from this article against it before go-live, the same as you would with anyone else's tool.
Frequently Asked Questions
What is software that turns customer requests into jobs?
It's software that takes incoming customer requests, usually emails and web form submissions, and creates tracked jobs from them automatically. Each job gets an owner, a status, and a due date, and the original request stays attached. The goal is to remove the step where someone retypes the request onto a board by hand.
Is a helpdesk the same as job intake software?
Not really. A helpdesk is built around tickets that get answered and closed, which suits support questions. Trades and project teams need jobs that can be scheduled, staffed, and blocked by dependencies, so a helpdesk usually ends up as a second system you copy from.
How do I stop duplicate jobs when customers email twice?
Choose software that reads the Message-ID, In-Reply-To, and References headers defined in the email standard RFC 5322. Those headers let the tool attach replies and follow-ups to the existing job instead of creating new ones. Test it by replying to your own request before you rely on it.
Can AI create jobs from customer emails automatically?
It can draft them well, pulling out addresses, contact details, and a sensible title from messy messages. It shouldn't create or schedule jobs without a person approving them. A wrong guess means a crew at the wrong site, and a quick human review prevents that.
What should a customer request form ask for?
Keep it to a name, one contact method, the job location, a description with an optional photo, and preferred timing. Location is the field that makes a job schedulable, so make it required. Collecting less data also means less to protect and delete later.
Sources
- RFC 5322: Internet Message Format | IETF / RFC Editor
- RFC 3834: Recommendations for Automatic Responses to Electronic Mail | IETF / RFC Editor
- Model Context Protocol | Model Context Protocol
- Art. 5 GDPR: Principles relating to processing of personal data | gdpr-info.eu