Field service requests start in chat, not in a job form

A customer does not open your software. They write the way they already write. “AC stopped. 24 King Street. Tomorrow afternoon?” That sentence is the brief. Everything after it is either operations or delay.

Most field-service software starts later. It starts when someone has already decided the work is a job and has typed it into a form. The request existed three messages earlier. The job did not.

In most crews the next step is still a hop. Someone screenshots the chat. Someone copies an address into a sheet. A crew member guesses the site. The customer asks “are you coming?” in the same thread that started the work. That hop is where windows slip, notes vanish, and the person who happened to be online becomes the system of record.

Existing field-service software generally starts once a job already exists. WhatTheJob starts when the customer writes or calls.

Why the first message is the product

If the thread lives on a personal WhatsApp, the business does not own the work. The same is true of a personal SMS inbox, a mailbox only one person checks, or a voicemail that never becomes a record. When that phone is off, the week is off.

Owners feel this as dropped balls. Dispatchers feel it as a pile of half-stories. Crew feel it as a driveway guess. None of those people need another dashboard slogan. They need the conversation tied to the company, visible to the people who dispatch, not to whoever happened to be online.

That is why How it works starts at the inbound message, not at a calendar. The path is conversation in, a draft you can trust, a person who still approves, assign, the Crew App, done. The motto is the sequence: from first message to job done.

WhatsApp is often the channel people picture first. It is not the only one. SMS, email, and voice land in the same operational inbox. Listing two of those four is how you pretend the week is tidier than it is.

The hop that loses the job

Watch a busy morning. A customer texts the owner. The owner is on a site. They forward a screenshot to the office. The office opens a sheet. The address is right. The unit number is not. “This morning” becomes a cell that says AM. The shutoff note in the third message never leaves the chat.

A crew member gets a pin and a first name. The customer writes again, in the original thread, because that is the only place the request still lives. Someone replies “on the way” from a personal phone. Nobody can later say who promised what.

None of that is a technology failure in the abstract. It is a failure of ownership. The request was clear enough to act on. The company never held it.

A prettier calendar will not save that week. If this path is excellent, the calendar is a view of work you already trust.

One inbox for WhatsApp, SMS, email, and voice

Queries exists so the conversation is a company record. The people who dispatch can see it. The raw thread stays next to the draft. You are not reconstructing the brief from memory when you decide it is a job.

Four channels, one operational inbox:

• WhatsApp, when that is how the customer already writes.
• SMS, when they would rather text a number than install anything.
• Email, when the building manager sends a paragraph and an attachment.
• Voice, when they call, and the call still has to become a thread someone can stand behind.

There is no end-customer web portal in this product. They already chose a channel. Meeting them there is not a feature list. It is the shortest path from request to a record.

Features is the desk view of that inbox: the thread, the draft, the job you assign. The field does not get a forwarded chat. They get the job. That split is the point of Crew need the job record, not another inbox.

A message is not a job

AI can draft the service, the site, the window, and the problem. Software can check the draft against your catalog. A person still decides it is a job. That gate is not a disclaimer. Software that invents work will not last a week in a real crew.

The raw thread stays next to the draft. Missing fields stay visible. Guessing does not. Convert when you mean it. The inbox can stay an inbox.

This is the same rule as AI drafts the field job. You still approve it. Extraction is useful. Autonomous dispatch is not the product. If “tomorrow afternoon” is only 82% sure, you see it. If the service is not in your catalog, software rejects the guess.

A customer asking what you offer is not a job request. A customer asking for a person is not a catalog question. Software should route the turn before a job is even considered. The inbox has room for all of that. It does not have to pretend every message is work you already sold.

A morning that stays in one place

Here is a composite, not a case study. A customer writes on WhatsApp: “AC stopped. 24 King Street, unit 4. Tomorrow afternoon? The shutoff is in the hall closet.”

The thread lands in Queries. WhatTheJob drafts a request: AC repair, that site, a window, the problem, a note about the shutoff. Software checks AC repair against your catalog. A dispatcher reads the raw messages, edits the window, and converts it. They assign a crew member. The crew member opens the job on the Crew App: address, unit, window, checklist, the closet note.

The customer is not told an arrival time the model invented. When the job is done, they are told it is done, on the channel they already used.

Change the channel and the shape stays. An email from a property desk with two photos. An SMS that says “leak under the sink, this morning if you can.” A call that becomes a thread because a voicemail is not a job. The hop is what you are trying to delete.

What Queries actually holds

Queries is not a chat app with a logo on it. It is the operational inbox. The thread is tied to the company. The people who dispatch can open it. The draft sits next to the words the customer actually sent.

That matters on a Tuesday when two people need the same story. The owner is on a site. The office is converting. The crew member will need the shutoff note later. If the only copy lives on one phone, two of those three people are guessing.

What you should see in the inbox:

• The raw thread, not a summary that replaced it.
• Whether this turn looks like a job request, a catalog question, or someone asking for a person.
• What the draft thinks the service, site, window, and problem are, each with a score.
• What is missing. Empty is better than a confident guess.

You should not see an arrival time the model invented. You should not see a job that nobody converted. You should not see another company’s conversation. Isolation is a different note. The short version is: this inbox is yours.

Roles are part of that trust. Owners and admins can see the desk and the look back. Dispatchers live in the inbox and the day. Crew do not get the whole workspace. They get the jobs you assign. End customers do not get a login. They already wrote or called.

Why a customer portal can wait

A portal is a reasonable product for a different problem. It assumes the customer will come to you, create an account, and fill a form you designed. Some weeks that happens. Most field weeks do not start that way.

The customer already chose WhatsApp, SMS, email, or a call. Asking them to start over is how you add a second brief that does not match the first. The office then reconciles two stories. The crew still gets the worse one.

Meeting them on the channel they picked is not a feature list. It is respect for how the request actually arrived. Photos can live on that thread. A building manager can forward an email. A call can become a record. None of that requires a new login.

If you later want a portal, that is a later product question. It is not the MVP path, and it is not how this note starts. Start at the conversation you already have.

How this sits on the rest of the path

Intake is the beginning, not the whole product. After the thread is a company record, the rest of the week still has to work.

A person still approves. The model drafts. Software checks the catalog. You convert, or you leave it as a conversation. That gate is the product, not a footnote under an AI sticker.

You still assign. The model does not send anyone. You pick the crew member and the window from the jobs list, the board, or the calendar.

The field still needs a job record. Site, window, checklist, photos, signature. Not a screenshot. When they mark it done, the customer is told. An optional short survey can run on that same phone. Loyalty points are a separate switch, off until you turn them on. Neither is the product. The product is a finished visit that started as a sentence.

If you want the AI half of this in more detail, read the human-gate note and AI. If you want the field half, read the crew note. If you want to walk the whole path with your own morning, contact sales.

What this is not

This is not a generic field-service suite with a chat sticker. Most of those tools still assume the form already exists. This is not a customer portal that asks people to log in after they already wrote you. This is not a promise that AI will run the week.

WhatTheJob drafts. Software validates. You act. Tell us how a request becomes a job today. If the path fits, we walk Queries, the gate, assign, and the Crew App. Architecture stays generic. The first conversation does not.