Documentation
Biloh documentation
How Biloh works, how to do things in it, and how it is built. Public and built to be read by people and AI agents alike — the full corpus for agents is at /llms-full.txt.
How-to guides
- Amending a proposal after you have sent it
A sent proposal is immutable. Supersede it with an amended copy that keeps the audit trail and redirects the client's original signing link to the new one.
- Dispatching and triaging jobs
Dispatch a job to a contractor, act on it from the Job Command Sheet, and clear what needs attention — overdue, missed, and unassigned work.
- Migrating a client book from another system
Move live clients off an old CRM one at a time — verify the entity, stand up the service, backfill completed work, and bill it without losing history.
- How to send a proposal
Build a proposal in biloh, preview the investment summary, and send it to your client for a legally-binding portal acceptance — by chat or in the app.
- Triage an inbound client request
Pick up a request a client sent from their portal, decide whether to quote or decline it, and turn it into a priced proposal.
Reference
- Connecting Biloh over MCP
How to connect a Biloh tenant to an AI assistant over the Model Context Protocol — the endpoint, authentication, personas, and the operator toolset.
- Route optimization: the runs bolt-on
Runs group a day's stops in Biloh. Ordering them by hand is free; an optional paid solver sequences them and hands the route to your maps app.
- Service request MCP tools
The five MCP tools that let an assistant work a client's inbound request queue: list, read, review, decline and quote.
Explanation
- Backfilling work you already did
Record completed visits from before a migration at their original price, decide whether a contractor gets paid, and let the billing cadence bill them.
- How client requests close the loop
Once a client is onboarded their portal becomes the channel they send new work through, and every request lands in your queue as actionable work.
- Who decides whether a job needs photos?
Photo and note requirements on completion resolve through four levels — job, series, client and contractor, then your default — with the strictest rule winning.
- Delivery models: dispatch, self-perform, or both
One delivery-model setting adapts Biloh to operators who subcontract every job and to owner-operators who do the work, without splitting into two products.
- One proposal, many sites
A multi-site proposal prices each premises on its own line, subtotals per site, and stands up a separate service line at every site when the client accepts.
- Scheduling jobs by the day, not the minute
Why a field-service schedule models jobs at day granularity, and how editing a recurring series splits into this-occurrence and all-future changes.
- The three voices of a service
One service speaks three ways: a sales pitch for customers, a legal scope for contracts, and an operational scope for the crew doing the work.
- How Biloh handles money: the two Stripe tills
How Biloh separates platform subscription billing from each business charging its own customers — two independent Stripe tills.
- When completing a job bills the client
Field-service billing cadence is per-client: invoice each job on completion, consolidate a period, bill on the period's last job, or invoice by hand.
- Why a contractor can't be assigned to a job
The compliance gate checks capability, agreement, insurance and availability before any assignment — and names the exact reason each contractor failed.
- Why your brand assets should outlive your designer
How Biloh's Brand Pack keeps finished files AND editable source masters with your business, so any designer can continue the work.
- What is Biloh?
Biloh is an AI-native operating system for service businesses — run quoting, scheduling, contractor dispatch and invoicing by chat or any AI agent.
Engineering notes
- An orientation payload an agent can actually read
A read-me-first tool that returns 100KB is unreadable inside an agent's context budget. Make the default lean, put the full detail behind an explicit flag.
- Show the price you'll charge: one source of truth
Show prices from the same source that charges the customer. Copying a price into a second surface invites silent displayed-versus-charged drift.
- Drag is a desktop idiom; the phone wants a tap
Drag-and-drop dispatch boards are desktop tools. On touch a press-and-move is a scroll, so the field surface has to be tap-first, not drag-first.
- Every record needs a visible bucket
Grouping a list into filters can leave records in no group at all — present in the data, invisible on screen. Make the buckets a partition and assert the union.
- The gap between a green build and a live deploy
Lessons from building a docs system into a deploy-on-every-push platform: a green local build and a working deployment are different claims.
- Lessons from shipping agent-facing MCP tools
Lessons from shipping a batch of MCP tools: test the consumer not just the logic, surface what agents need, and watch the build and version traps.
- When the money arrives but can't be recorded
When a provider confirms a payment your system can't record, alert a human and still acknowledge the provider — never fail silently.
- Making a multi-connector MCP setup safe to act on
How Biloh stops an agent holding several tenant connectors from acting on the wrong one: identity, a per-response stamp, a mismatch guard, confirm-gates.
- One write path, many callers
Why every mutation should funnel through one core that the UI and the agent both call — and the billing bug that appears when a caller skips it.
- Put the yes where the thumb is
A field app's primary action belongs in the thumb zone, pinned and dominant — and the destructive options belong below the content, not above it.
- Tool discoverability for agents
How an agent finds the right tool among hundreds — a categorised map, intent search, and the zero-result rate as the signal the catalogue works.
- Trust the signed account, not the webhook's metadata
A payment webhook must bind each charge to the provider's signed account, not to client-supplied metadata — the pattern that blocks cross-tenant spoofing.
- Two places, one fact
A permission was stored in two places. The form wrote one, the gate read the other — so a user's saved choice was invisible to the system enforcing it.
- Reading a tenant setting: unwrap the envelope
Governed settings writes wrap the value as {v:...}, so a raw read silently returns the default. The one unwrapper to use, and the lint that enforces it.
- Verifying the tenant that isn't your default
A test harness that injects tenant context can't catch a tenant-resolution bug. Only live use on a non-default tenant exposed a 401 the suite couldn't see.
- Whose "today" is it? Timezones in a scheduling engine
A scheduling product that computes today in UTC shows the wrong day to most of the world. Resolve the day in the tenant's timezone and lock it with a test.
- A handler nothing subscribes to does nothing
An event handler can be unit-tested yet never run in production if nothing subscribes it to its event. Verify the wiring, not just the handler.