00.0

Home  /  Portfolio  /  ParrotB

Salsedine, own product, shipping

ParrotB

You can't be everywhere.ParrotB can.

A plumber with both hands inside a boiler cannot answer the phone. Most callers who reach voicemail hang up and dial the next number, and the ones who do leave a message are the easy half of the problem. The rest of the day is quotes, jobs, invoices, suppliers and the tax office.

RoleFounder, product and UX
Year2026 to now
MarketsItaly, Spain, Portugal
LanguagesFour
A Tuesday, on a job since eight
Missed today 0 Hands full since 08:00

The decision that changed the product

Answering the phone was the smallest part of the problem.

The first version was called Alessia and it answered calls. So did every competitor, and so did the answering services charging over a thousand euros a month. Building a better phone bot meant competing on the one feature everybody already had.

So the product got a north star question, and it is still the test every feature is held against.

Does this help a tradesperson run their business better, not just answer their phone?

The question that reorganised everything

Almost nothing about the phone module changed. What changed was that it stopped being the product.

One product became six modules
Alessia, the AI receptionist1 product

The reason it has to be one system

One job, from a missed call to a maintenance reminder eleven months later.

Twelve touchpoints  ·  six modules

This is the journey map the product is built against. Every step below is a real screen, and the badge on each card is the module that owns it. A phone bot can only ever do the first two.

One job, end to end
One job touched all six modules. reception · front desk · documents · brand · website · back office

The module nobody expects

In Portugal, fifteen of the twenty three obligations are not taxes.

Back office started as suppliers, receipts and books. Then the research kept returning the same answer: the thing that actually keeps a sole trader awake is not the phone, it is the state.

So the module carries the obligation calendar, and it is country split by design rather than translated. Italy gets Tasse e Partita IVA, because in Italy it genuinely is tax. Portugal gets Burocracia, because most of what a Portuguese sole trader owes the state is not a tax at all: it is registrations, declarations, employment paperwork and rental contracts.

The label is derived from the business's country, never from the interface language. An Italian owner who switches their dashboard to Portuguese should not have their tax module renamed. That sounds obvious written down. It was not obvious in the code, and it is the kind of thing that only surfaces when one person owns both markets.

The same module, two countries
Tasse e Partita IVAItaly

Conversation architecture

Every rule in the agent came from a call that went wrong.

The voice layer is interaction design with no screen. The rules are specific, testable, and each one is traceable to a failure:

  • One or two sentences, never more. A caller talks over anything longer.
  • If the reply contains a question, the question is the last thing said. Anything after it gets talked over, because the caller starts answering immediately.
  • Phone numbers and house numbers digit by digit. Prices as words, dates spelled out, never a timezone.
  • Availability as one hour windows, never an exact minute. The booking still records the precise start time.
  • Never give up on a misheard word. Ask to repeat, then stop talking.

That fourth rule is the one I am most pleased with. A trade cannot promise to arrive at 09:15, so the agent never says it. What it speaks and what it stores are deliberately different.

A booking call, with the rules showing

Making it affordable to run

One prompt of 2,800 tokens became four of about 800.

The first architecture sent the agent everything on every turn: identity, tone, business vocabulary, services, pricing, service area, booking rules, transfer rules, emergency handling, opening hours.

A call only ever occupies one part of that at a time, so the prompt was split into a small base plus one stage, and the tools were scoped per stage so the agent cannot book before it has collected anything.

Around 68% fewer prompt tokens per call. Across a twenty four turn conversation that is roughly 76,000 tokens down to 30,000, and the shorter context measurably improved how well the agent held to the rules.

Prompt size per turn
Monolithic
0tokens, every turn
Staged
0base plus one stage

How a prompt change gets approved

Fifty nine scenarios, and a threshold that blocks the merge.

Prompt work is easy to fool yourself about. A change reads better, the one call you try goes well, and something three steps away quietly breaks. So every change runs the same protocol: run all four suites, make one surgical edit, run all four again.

Each suite has a floor. Drop below it and the change does not ship. Two of my own changes did not: a fuzzy service matcher that dropped intake to 78% because it made the agent hedge on matches it should have been confident about, and a broader emergency detector that dropped it to 66% because urgency phrasing started overriding service identification. Both were reverted and both are written down.

Eval suites, with block thresholds
59 scenarios2 changes reverted

What shipped

A platform, not a phone bot.

Six modules, four languages, and a category the product now defends in its own FAQ. The hardest part was not building the AI. It was deciding it should not be the headline.

6modules, three of them base
12touchpoints in one job
68%fewer prompt tokens per call
59eval scenarios gating every change

Not here to hire a designer?

ParrotB is live, and it takes customers.

If you run a trade business it answers the phone, books the job against your real diary, and gives you a site that gets you found. There is a monthly fee and you can see it before you talk to anyone.

See what it costs  →
Next case study

Saveri, designing for a model that is not sure

03 / 07 →