Mapping the Questions Your Front Desk Agent Will Get

You do not need to read every message. You need a sample that is not skewed. The trap is pulling "the last 200 messages," which in a quiet business can mean four days of one shift, or in a busy one can mean a single Tuesday morning.

A defensible method:

1. Count total inbound items per day for the window. Note the daily totals.
2. Decide your sample size, typically 200 to 400 items for a single location.
3. Allocate the sample across days in proportion to each day's volume, so a Saturday with three times the traffic gets three times the sample.
4. Within each day, spread picks across open hours, not just the busy middle. Deliberately include at least a few items from opening hour and closing hour.
5. Include after-hours and weekend items even if they are a small share, because those are exactly the calls an agent most often covers.

If your goal is comparing channels, sample each channel separately rather than pooling everything. A chat log and a phone transcript produce very different intent mixes, and pooling them hides that.

A quick way to make the draw reproducible is to sort each day's items by timestamp and take every nth item:

import csv
from datetime import datetime

# rows: timestamp, channel, text
rows = list(csv.DictReader(open("inbound.csv")))
for r in rows:
    r["ts"] = datetime.fromisoformat(r["timestamp"])

by_day = {}
for r in rows:
    by_day.setdefault(r["ts"].date(), []).append(r)

sample = []
for day, items in sorted(by_day.items()):
    items.sort(key=lambda r: r["ts"])
    n = max(1, round(len(items) * 0.10))   # ~10 percent of the day
    step = max(1, len(items) // n)
    sample.extend(items[::step][:n])

sample.sort(key=lambda r: r["ts"])

Ten percent of a few thousand messages gives you a few hundred items with the day and hour spread intact. Keep a column for channel and one for whether the message came in or out of hours; you will use both later.

The labels you write in the first pass should be short and concrete. The standard advice from contact-center practice is to start with intent tracking, then route and resolve on top of it, using entrypoint, keywords and self-selected options as signals of what a message is about Heymarket. You are doing the human version of that first pass.

A starter set that covers most front desks:

Two rules keep the taxonomy usable. First, one label per message, even when the message contains two asks. If someone writes "can I move my appointment and do you take my insurance," label it booking and changes and note the second ask in a free-text column. Multi-label tagging feels more precise but makes counting and prioritization harder, and your first goal is counting.

Second, resist splitting too early. If you end up with 40 labels after 300 messages, merge the ones with fewer than five examples into the nearest parent. A label that appears twice is not a category yet. Microsoft's intent tooling takes the same posture at scale: it discovers intents from past interactions to build an intent library rather than asking an administrator to guess them up front Microsoft Learn. You are running the same idea by hand, with a much smaller dataset.

Keep the label text boring. "Booking and changes" survives handoff between people. "Customer wants to reschedule their thing" does not.

Once every sampled item has a label, count by label, then break the counts down twice: by channel and by hour band. This is the step that turns anecdote into a build decision.

A worked example. Suppose the sample is 320 items from a single clinic location over one week:

Read that table before you build anything. Hours and location is the single biggest chat category and a small slice of phone. Booking and changes dominates the phone. Complaints are small in volume but concentrated on the phone and expensive per item. A generic "AI receptionist" pitch would have you build one thing; the numbers say the chat and phone channels need different priorities.

The channel split is not cosmetic. Practitioners who run these deployments point out that channels are not equal, and a sensible setup lets a business permit an action on the phone but not by email, then redirect an email request to the phone rather than actioning it Elva's handoff guide. Your count table is where that per-channel permission list comes from.

Now take each label and ask one question: what would a competent staff member need to answer this? Answers fall into three buckets, and the bucket decides the build.

The third bucket has sharp edges worth writing down. Guidance on receptionist limitations puts sensitive decisions (advice, exceptions, refunds, contractual commitments), uncertain identity, and intense anger, threat or emergency into the "require a person" column VocalOps. It also recommends a recovery sequence for everything else: recognize uncertainty, clarify once, reduce scope from action to message capture, then transfer with context and record the event VocalOps. That sequence is a design pattern you can apply per bucket.

Run the test per intent, not per message. For each label, write down:

• The exact source that answers it (a page, a policy, a field in the booking system).
• Whether that source exists today and who owns it.
• The failure mode if the agent gets it wrong.
• The escalation path.

Operators who have shipped these systems say the practical line is judgment: if the front desk would need a script, the agent may handle it; if it would need judgment, the agent should escalate TeleCloud. The same source sets out three call types to define before go-live: what the agent fully handles, what it starts and then transfers, and what goes straight to a person TeleCloud. Your label table maps onto those three rows almost directly.

The seasonal sample. One week in your busiest month is not your year. If you sample during a promotion, a holiday week or a weather event, the mix will not hold. Fix it by noting anything unusual about the collection week in the write-up, and if you can, take a second sample two to three months later and compare. If the two mixes diverge by more than a few points on your top three labels, treat the taxonomy as provisional.

The channel difference. Chat and phone produce different intents, as the worked example shows. Two things follow. Sample each channel separately, and never assume a fix for chat transfers to phone. Voice has extra failure modes that text does not: misheard names, accents, background noise, overlapping speech and mid-call language changes VocalOps. A chat label of "booking and changes" may be straightforward to automate while the same label on voice needs a confirmation step and a fallback.

The "everything else" creep. An "everything else" bucket above roughly 15 percent means your labels are too narrow or you stopped reading carefully. Go back through that bucket and write what each item is in a sentence. Patterns will appear by the tenth item.

The silent majority. The messages you never received because nobody answered are invisible in your logs. Missed calls and abandoned chats are a category of their own, and vendors in this space base whole products on the idea that a missed call is a lost customer, citing the steep drop in contact rates after a five-minute follow-up window Boxplot. Pull the missed-call list from the phone system as a separate sample and count it. It often changes the priority order.

The transcript artifact. Machine transcripts contain errors, and reading them as if they were exact quotes will make callers sound stranger than they are. Spot-check a handful of transcripts against the audio before you label, and do not build a label around a single garbled phrase.

The one-person sample. A single reviewer's labels drift over 300 items. If two people can share the reading, have both label the first 30 items and compare. Disagreements are free definitions you have not written down yet.

The output of this week is a one-page artifact: the label table with counts, the channel split, and the three-bucket classification with a named source for each fixed-document intent. That page is what you scope from.

Build in the order the numbers justify. Start with the fixed-document bucket, because those intents need no integration and no permissions, and they tend to be the biggest share of chat. Add system lookups next, one system at a time, because each one is a permission and a failure mode. Leave the "needs a person" bucket to escalate, with the agent capturing enough context that the person does not start over. Warm handoff guidance in this space is consistent on that point: the staff member should receive the reason, the captured details and the cause of the handoff, so the caller continues a conversation instead of restarting one Elva.

If you want a low-risk way to test the agent's judgment before it writes to a booking system, borrow the review-mode idea: the agent proposes the action and a person confirms it until the team has watched enough real calls to trust it Elva. Your labeled sample is the test set for that period.

When the map is done and you are ready to build the agent itself, the routing between models and the surrounding integration work is the next decision. Quanta Inference puts text, audio and embedding models behind one OpenAI-compatible API key, which is useful when your agent needs speech-to-text for the phone channel and a text model for chat. For help turning the one-page artifact into a scoped build, a free discovery call is the natural next step: https://quantaintelligence.ai/calendar.