A service is not one description. It is the same piece of work seen by three readers who need completely different things, and collapsing them into one field is how catalogues go wrong.
In Biloh a service carries three voices:
- The public summary — the sales pitch. Plain, short, appealing. This is what a prospect reads on your website and what a client sees browsing available services in their portal.
- The legal scope — what is included, what is excluded, liability, client responsibilities. This renders on proposals and signed agreements, where precision protects both parties.
- The operational scope — equipment, method, access requirements, site procedure. This goes to the contractor on the work order, and clients never see it.
One catalogue entry, three registers. The alternative — one description doing all three jobs — produces documents that are either too vague to enforce or too legalistic to sell.
The failure this prevents
The instructive version of getting it wrong: a client portal that renders the legal scope as each service's description. The operator browses their own portal and finds "Available Services" opening on a 250-word wall of exclusions, liability transfers and statutory disclaimers — technically accurate, commercially awful.
Nothing was broken. The right words were in the wrong register, on the wrong surface. That is why Biloh's portal catalogue selects the public summary and cannot select the legal scope at all: the safest way to guarantee legal language never appears on a browsing surface is to not fetch it there.
Sell what you can actually deliver
Most service businesses end up with two catalogues that drift apart: a website menu written by whoever built the site, and an operational catalogue that reflects what the business really does. A prospect requests something from the website that nobody has priced, resourced, or written a scope for.
Biloh links them. When you create a service you can have its website entry drafted at the same time — linked to the operational service it sells, seeded from the public summary, and left unpublished so you polish and publish deliberately. Website entries created this way point back at real, deliverable work.
That link pays off on the way in as well: a quote request submitted from a website service page resolves to the operational service behind it, so the enquiry arrives naming something you can price and schedule rather than a string an operator has to interpret.
Both behaviours are per-business settings — a business that manages its website by hand can turn the drafting off without losing the link.
The audience facet, and why agents need it
Alongside the three voices, each service declares who it is for: residential, commercial, or both.
This exists because of a specific, repeatable failure. A catalogue containing "Window Cleaning", "Window Cleaning (Inside & Out, Screens & Tracks)" and "Window Cleaning — Shopfront" gives an AI assistant nothing to choose on. Asked to schedule a commercial shopfront clean, it picks the domestic service — the one with screens and tracks, which a shopfront does not have — because the names are equally plausible and nothing says otherwise.
Two fixes, both cheap:
- Name for the reader. Lead with the audience: Commercial Window Cleaning — Shopfront (Glass Only). A name that disambiguates is doing structural work.
- Declare the facet. The audience field is returned in the service catalogue with an explicit instruction to match it to the job.
A catalogue is an interface for agents now, not just a price list. It deserves the same care as an API.
Where each voice ends up
| Voice | Surface |
|---|---|
| Public summary | Website service pages, client portal catalogue |
| Legal scope | Proposals, signed agreements |
| Operational scope | Work orders sent to contractors |
Keeping them separate means you can rewrite your sales copy without touching a legal definition a client already accepted — the change a single-description catalogue can never make safely.