# How client requests close the loop > Onboarding a client is not the end of the sale. The portal you give them becomes a standing channel for their next job: they describe the work, name the place, and it arrives in your queue with enough detail to quote. You triage it, turn it into a proposal, and send it back for signature — without a single email thread. The client's easiest path to their next job is the contractor they already have. URL: https://biloh.com.au/docs/concepts/client-requests-close-the-loop Category: Explanation | Audience: evaluator | Updated: 2026-08-16 ## What actually closes the loop? Most field-service software treats a client as a destination: work goes *out* to them — quotes, work orders, invoices. The loop closes when work can come back *in* under its own steam. A Biloh client portal is a standing inbound channel. A client who is already set up can, at any time, open their portal, pick a service from your catalogue (or describe something you don't list), say **where** the work is, and submit it. That submission becomes a **service request**: a first-class record in your queue, not an email in an inbox. The commercial consequence is the point. Once a client's next job is three taps away in a portal they already have, the path of least resistance for their next piece of work runs through you. You stop being the vendor for one service line and start being the one place they send everything. ## What does the operator actually receive? A service request arrives carrying the things you need to price it: - **Who** — the client, resolved from their portal session. No identification step. - **Where** — either one of their existing sites, or a free-text address they typed. - **What** — a service from your catalogue when they picked one, plus their own description in their own words. - **When** — one-off or recurring, and how urgent they consider it. - **Their reference** — a purchase-order number, where they work that way. The request has a quotable reference from the moment it is created, so both sides can talk about it by name. ## Why does "where" matter so much? Because the most valuable inbound request is usually for somewhere you have never been. A client with three sites under contract asks you to look at a fourth building. A commercial client asks you to do their director's house. If your intake can only accept a location you already service, that request either gets rejected by the form or arrives with the address buried in free text — and an address buried in prose is an address nobody can dispatch to. Biloh treats both shapes as first-class. The client either picks an existing site or chooses **"Somewhere else"** and types the address. A request pointing at an address you have no site for is flagged in your queue as **not a site yet**, so you can see at a glance that it needs a premises created before the work can be scheduled — and the address travels onto the proposal so it is never lost. This was learned the hard way. In a live tenant, one inbound request sat **37 days** without action. It was not ignored — it had nowhere to land. The client had named a property that was not a site, and the request reached the queue with no location on it at all. ## What are the three decisions? Every inbound request resolves one of three ways, and each is a real, recorded outcome rather than a status someone forgot to update: | Decision | What it means | What the client sees | |---|---|---| | **Review** | You've picked it up and are working on it | Status moves to under review | | **Decline** | You're not quoting this | The reason you wrote, in their portal | | **Quote** | It becomes a draft proposal | Status moves to quoted, with a link | Declining requires a reason, and that reason is client-visible. That constraint is deliberate: a silent decline teaches a client not to bother asking next time, which is the opposite of what the channel is for. Every one of those decisions is attributed to the person who made it and lands in the audit trail — so "who reviewed this and when" is always answerable. ## How does a request become money? Quoting a request creates a **draft proposal** already carrying the client, the location, the description, and their purchase-order reference. You add your price, and send it through the standard staged send — preview, then approve — so nothing reaches a client without a human seeing it first. The client opens the emailed link, reads the agreement, and accepts it in the portal. From there it flows into the platform's normal machinery: recurring work stands up its own schedule, one-off work becomes a job to dispatch. Read [how a proposal presents your price](/docs/concepts/three-voices-of-a-service) for how the same work reads differently to a client, a contractor and an invoice. ## Can an assistant work the queue instead of a person? Yes — and it is the same queue, running the same rules. The inbound queue is exposed over MCP, so an AI assistant connected to your business can list what is waiting, read a specific request, mark it under review, decline it with a reason, or turn it into a draft proposal. The UI and the assistant call one shared module, so a request triaged by an agent overnight is indistinguishable from one triaged by a person at a desk — same fields stamped, same events emitted, same audit trail. See [the service-request tool reference](/docs/reference/service-request-mcp-tools) for the exact tool names and shapes. ## What this is not It is not a ticketing system. There is no SLA clock, no queue assignment, no priority matrix. A service request has exactly one job: carry a client's ask from their portal into your pipeline with enough fidelity that you can price it without going back to them for basics. If you need to ask the client something before you can quote, that conversation happens where it always did. The request is the record that it was asked for.