Do Customers Say Please to Chatbots? A Method for Counting Politeness

The word please is easy to count and difficult to interpret

A customer types, "Please check my delivery." Another writes, "I've asked three times. Just tell me where it is." A simple word count records one use of please and one absence. It says little about the larger interaction. The first customer may be using routine courtesy. The second may be frustrated after repeated attempts to obtain a straightforward answer. Neither message, by itself, establishes how the customer feels about the service.

Politeness in chatbot conversation design is a matter of language, sequence, and context. Please can soften a request, signal insistence, or appear in a sarcastic complaint. It can also be absent from perfectly cooperative exchanges. Customers are interacting with software through a service interface, and their language reflects individual habits, time pressure, accessibility needs, and expectations about the task.

A useful counting method therefore has two levels. The first identifies whether a courtesy expression appears. The second records what the expression is doing in the conversation. This distinction makes the resulting analysis more useful to conversation designers and less likely to turn ordinary language variation into a judgment about customers.

Define what counts before opening the chat logs

Start with a clear unit of analysis. A practical choice is the individual customer message, with the surrounding conversation retained for interpretation. Decide whether the count includes only please or also expressions such as "could you," "would you mind," "thank you," and "excuse me." These expressions are not interchangeable, so record them separately if the analysis needs to distinguish direct courtesy words from broader politeness strategies.

Set a fixed sampling period and use the same rules throughout it. For example, a team might examine 200 eligible customer messages from a defined service period. That number is an illustrative sample size, not a universal requirement. The important decisions are how messages are selected, which channels are included, and whether repeated messages from one conversation are treated separately or grouped together.

Write down exclusions before counting. System-generated messages, agent messages, automated greetings, and duplicated records should not accidentally enter a customer-language count. Teams should also follow their organization's privacy, retention, and access rules when working with conversation logs. Remove unnecessary personal information from working copies and restrict access to people with a legitimate operational reason.

• Define the message or conversation as the counting unit.
• Choose a fixed period and a reproducible sampling method.
• Separate customer messages from bot and agent messages.
• Record the exact courtesy expressions included in the count.
• Document exclusions and privacy safeguards.

Separate routine courtesy from conversational function

Once the relevant messages are identified, assign a context label. A simple coding scheme might distinguish routine courtesy, emphasis, sarcasm or irritation, and ambiguous use. For example, "Please send me a copy of the receipt" can be coded as routine courtesy. "Please, just answer the question" may signal emphasis after an unsatisfactory response. The same word appears in both messages, but it performs a different conversational job.

The surrounding turns matter. A customer who says please after the bot has offered a relevant option may simply be making a conventional request. A customer who adds please after two failed attempts may be intensifying the request or trying to regain control of an exchange. The coding should describe the observable interaction rather than speculate about the customer's personality or emotional state.

Include an uncertain category. Some messages do not provide enough context to support a confident interpretation. A short "please" following a menu prompt may be an answer, a request, or a continuation of an earlier turn. Recording uncertainty is more useful than forcing every example into a neat category.

A worked example of counting politeness

Imagine a constructed sample of 100 customer messages. Twelve contain the word please. A basic frequency count gives 12 percent. A closer coding pass might classify eight uses as routine courtesy, three as emphasis, and one as ambiguous. These figures are hypothetical and illustrate how the method works; they are not industry benchmarks or evidence about customer behavior in general.

The next step is to examine the conversations surrounding those twelve messages. If several emphasis cases follow repeated bot misunderstandings, the design team has a specific recovery problem to investigate. If routine courtesy appears mainly in longer requests, it may reflect the type of task or the way customers phrase detailed instructions. The count alone cannot establish either explanation.

The denominator also matters. Twelve messages containing please out of 100 messages is different from twelve out of 100 conversations. A conversation can contain several customer messages, and one person can use the word more than once. Always label the unit and report it alongside the percentage so that later comparisons remain meaningful.

Check consistency between people coding the same messages

Context labels require judgment, so a written coding guide is essential. Define each category and include a short example of what belongs in it. Two people coding the same sample should be able to explain why a message was classified as routine courtesy or emphasis. If their decisions regularly differ, the category definitions may be too vague or the available context may be insufficient.

A practical approach is to have two reviewers independently code a small shared subset, such as 20 messages, before dividing the remaining sample. Discuss disagreements and revise the guide. The shared subset is a calibration exercise, not a guarantee that every later judgment will be identical. For larger projects, teams can calculate an agreement measure and seek methodological support when the analysis needs formal research standards.

Keep examples that illustrate difficult decisions, with identifying details removed. These examples help new reviewers understand the scheme and make future rounds more consistent. If the coding rules change, record the change and apply it consistently before comparing periods.

Interpret politeness alongside repair and escalation

The most useful findings often concern the relationship between language and the service sequence. Compare messages containing please with messages that follow a failed answer, an unclear greeting, or an unsuccessful repair. Look for patterns in whether customers repeat requests, provide additional details, abandon the conversation, or ask for a person. These are separate interaction signals and should remain separate measures.

Bot repair strategies can influence the language customers use. A bot that asks a focused clarification may make it easier for a customer to respond cooperatively. A bot that repeats an irrelevant menu can encourage increasingly direct instructions. For example, "Please stop showing me tracking options. I need to change the address" contains courtesy language alongside a clear correction and a sign that the previous route was unhelpful.

Avoid using please frequency as a staff performance target or a measure of customer quality. A lower rate could reflect shorter tasks, changing message habits, or a different customer mix. A higher rate could reflect routine courtesy or customers having to repeat themselves. The finding should lead to a closer examination of interaction design, not a score assigned to the people using it.

Turn the count into a useful design question

A good report states the sample, unit, counting rules, context categories, and limitations. It then connects the findings to a concrete design question. If emphasis is common after clarification prompts, examine whether those prompts identify the missing information. If routine courtesy dominates, the result may simply describe the language habits represented in that sample. Either way, the report should distinguish observation from explanation.

The next step is to select a small set of conversations containing please and an equally relevant set without it. Compare the surrounding bot turns, repair attempts, and outcomes using the same coding guide. This gives the support team a practical starting point for understanding how politeness appears in its own service conversations.

Questions readers ask