The Friendliest Voice in the Room

What a warm AI interface promises—and what an organisation can actually be responsible for

A digital assistant can begin with a friendly greeting, answer in the first person and apologise for an error. These are visible features of an interface. They do not yet show that the system understands, cares, is permitted to decide, or can keep a commitment. This is precisely where the design question begins: What role does the interface suggest, what function does the system actually have, and how can people check an answer, hand the matter over to a responsible person, or end the interaction?

A responsible team does not have to ban friendliness or overwhelm users with warnings. It must, however, separate design signals from verifiable product properties. The appropriate standard is neither as little trust as possible nor as much trust as possible, but informed, appropriately bounded use: people should be able to recognise what they are speaking with, what this system can do, who remains responsible for consequential decisions, and which routes are open when something does not fit.

1. An interface sends signals; the organisation bears promises

Imagine a wholly fictional small bicycle-rental business. Its website is to have a text-based assistant that explains opening hours, collection and return locations, and prepares a booking. It cannot, however, change an existing booking, trigger a payment, or make a binding commitment. The team is considering a personal avatar, a greeting such as “Hello, I’m happy to help you,” and a warm, attentive tone.

A visitor asks whether she can return the bicycle later. The assistant replies: “No problem, I’ll take care of it.” In the next sentence it becomes clear that it cannot change the return time. Perhaps the visitor understood the response as a polite conversational form. Perhaps as an indication that the change had already been initiated. Perhaps she was only looking for the opening hours. Without an appropriate study, we do not know which interpretation actually arises in this case.

We can nevertheless begin the examination if we separate three levels:

The distinction is practically important. A sentence can sound caring without actually taking over a case. An avatar can suggest human closeness without a person reading the dialogue. An apology can be polite without resolving a problem. These are neither diagnoses of a system nor claims about its developers’ intentions. They are differences between visible design, possible interpretation and institutional responsibility.

The question “Does someone trust the AI?” is also too broad if it does not say what the trust concerns. Is it the correctness of an opening time? An actual booking change? A binding commitment? Or whether a person can be reached when there is a problem? For the business, these questions are not interchangeable. An interface can feel pleasant and still suggest an incorrect expectation about its own responsibility. Conversely, a matter-of-fact interface can be hard to understand or unnecessarily off-putting.

The following terms are a working distinction for this article, not a complete or uniform psychological definition. A product team should distinguish at least four terms:

Likeability describes an evaluation of the encounter or presentation.

Trust denotes a willingness to rely on another entity under uncertainty; the intended action and risk must be specified.

Reliance or use is observable behaviour, for example whether someone adopts an answer or follows a next step.

Trustworthiness concerns the reasoned question of whether performance, limits and responsibility justify reliance.

A positive evaluation is not evidence of correct performance. Use is not proof that the interface was understandable. A human-like presentation is not an assurance that the system’s role was designed appropriately.

2. What research shows—and what it does not show

There is no scientific blank cheque for inferring a general effect from a friendly sentence. The original studies relevant here examine different signals, tasks and measures. Taken together, they provide useful prompts for examination, but no universal design formula for a bicycle-rental business, a chatbot or all users.

In an experimental study of a text-based messenger agent for a fictional flower order, informal language, a human name, and dialogic greeting and farewell forms were associated as a bundle with a more anthropomorphic perception. The final analysis included 175 participants. The study did not examine a profile picture. It also found no general significant main effect on social presence and no significant direct or total effect on company satisfaction or attitude towards the company. A finding about a particular signal bundle in a light, fictional task therefore proves neither the effect of an avatar nor a general trust effect in customer service. [1]

Three experiments from automation research report a different, equally important tension. Participants received advice from a computer, an avatar, or a human-presented entity whose reliability gradually declined. Under these conditions, anthropomorphic presentation was associated with greater resilience of measured trust. This result does not mean that people always trust more strongly, that the system was more reliable, or that a human presentation would be responsible. Rather, it shows why perceived reliability and actually tested performance must be considered separately. The task and system in the study were not a present-day booking assistant for a small business. [2]

Disclosure that the counterpart is not a person but a chatbot likewise produces no simple pattern of effects. Two scenario-based experiments in an energy provider’s customer service varied, among other things, whether a concern was critical or routine and whether a service sequence ended successfully or failed. The measured trust effects differed by situation. In one study, a critical concern showed a lower trust value in the disclosed condition; routine concerns showed no corresponding effect. In the second study, the direction in the failed sequence differed from that in the successful sequence. These are context-bound findings from scenarios, not a reason to conceal an identity. They also do not prove that a single disclosure makes the actual role understandable to everyone. [3]

Work on human–machine handoff in dialogue systems makes a further contribution: handoff can be modelled as a concrete function with defined triggers and test cases. In the data examined, an explicit wish for a person, an unsatisfactory answer, negative sentiment or repeated utterances were among the categories that could indicate a handoff. The work examines tasks and model performance for particular data sets. It does not prove that a particular button is easy to find or that every handoff improves the experience. But it helps translate the vague statement “There is human support” into a testable product question: When is a handoff made, to whom, with what information, and what happens if no one is available? [4]

The NIST profile for generative AI classifies inappropriate anthropomorphisation, automation bias, excessive reliance and emotional entanglement as risks of human–AI configuration. It recommends documenting the context of use, expectations, limitations, risks and human oversight. This is a voluntary risk-management guideline, not an empirical effect size, not an EU legal norm, and not a statement that a particular avatar design would be harmful. For the bicycle-rental business, it is a reason to document the interaction as a sociotechnical decision, not an already established risk assessment. [6]

These findings yield a careful interim assessment:

1. In particular studies, design signals can change perception of a system; their effect depends on the signal bundle, task and measurement. 2. Trust and reliance are neither synonymous nor measures of actual correctness or institutional responsibility. 3. Disclosure can accompany different reactions. Such a reaction does not replace an ethical, organisational or legal examination of disclosure. 4. Handoff and exit can be designed and examined as concrete product functions. Which specific design is appropriate remains a design decision until it has been studied in an appropriate context.

Research therefore does not answer “How friendly should the interface be?” It requires a more precise question: What expectation might a concrete signal suggest in a concrete situation, which of these would be necessary for the function, and how can the organisation make mistaken assumptions recognisable and correct them?

3. The ethical tension: clarity without coldness, closeness without a false promise

It would be too simple to treat every human-sounding form of language as deception. A polite greeting can make an interaction accessible and less intimidating. A brief, understandable explanation can be more helpful than a technically correct but unreadable description. People with different linguistic or digital prior experience may need different forms of access. The article cannot claim a general effect from this; it can, however, state as a normative design question that intelligibility itself matters.

The opposing position must be taken seriously: if an organisation surrounds every sentence with warning text, it makes use laborious, directs attention to secondary matters and may obscure the relevant notices. For a business with limited staff resources, a human handoff available at all times may not be realistic. A neutrally worded assistant is not automatically more understandable than a warm one. An overly explicit interface is not automatically a fair one.

But the counterargument does not set its own boundary. Limited resources do not imply that an interface should promise more than the business can fulfil. A warm tone does not automatically imply a false role assumption. A disclosed role does not automatically imply that everyone notices it. The sustainable norm is therefore not to maximise closeness or warnings, but to align design, capability and responsibility.

This norm can be described philosophically as a question of truthfulness and autonomy. In a product, truthfulness is not exhausted by every individual line of text being literally true. Order, placement and omission can also shape expectations. Nor does autonomy require every uncertainty to be outsourced into a long liability text. It requires that information decisive for an action be findable: Who or what is answering? What is the system for? What can it not do? Who can change a decision? How can someone end or escalate the process?

The bicycle-rental business could formulate a meaningful performance promise: “This digital assistant explains collection and return information and helps prepare a booking. It does not change an existing booking and cannot make binding commitments. For changes, use the business’s contact route.” Whether this statement is repeated everywhere, shown at the start, or shown again for certain questions must be examined against the process and applicable law. What matters is that the claimed function corresponds to the actual performance of the system and business.

This question concerns responsibility. A single dialogue sentence is the result of product decisions: Which tasks were enabled? Which limits were tested? Who decides whether a handoff is available? Who checks a change? Who can update content and handle complaints? The interaction is performed by the system, but the organisation is responsible for the role it gives the system, the statements it permits, and how it responds to misdirection.

A useful design aim is therefore calibrated reliance: users should be able to use a function where it fits, and pause or hand over when a question lies outside its limits. This is a normative product requirement, not a claim that a particular layout can already guarantee it. The team and users need not hold the same view of friendliness. But they must not be left in the dark about function, limits, responsibility and ways to correct matters.

4. The Questioning Model changes the initial question

In this category, Questioning Model F is not prompt magic and not a truth machine. It is a procedure for examining the initial question, keeping several explanations open, not concealing uncertainty, and only then recording a revised guiding question. Its order is A → B → D → C. [7] In this case, the method genuinely changes the working objective.

The premature initial question is: “How do we make the assistant as likeable as possible so that visitors trust it?” It contains at least three unexamined assumptions: that likeability is the relevant goal, that more trust would always be better, and that tone or an avatar can establish the factually appropriate trustworthiness.

A – Clarify terms, goal and cause

Socratic clarification first asks what “likeable,” “trust” and “help” mean in this specific product. A visitor may trust the assistant to state opening hours correctly, but not to make booking changes. The business, in turn, may not need a more likeable interface, but more reliable information and fewer confusions about collection locations.

Here, 5-Why serves the search for causes rather than proof of a single true cause. Why should the assistant appear trustworthy? Perhaps because repeated questions tie up staff. Why do questions recur? Perhaps return locations are described inconsistently on different pages. The first improvement could then be a clear information page rather than a personal avatar. SCAMPER then opens variants: organise existing information more clearly, limit the task, add a human source of information, or omit the assistant for now. The questioning techniques help create alternatives; they do not prove their effects.

B – Several hypotheses instead of a wishful story

Context analysis produces several competing explanations:

H1: A clear, friendly tone can make use more inviting, provided the function remains understandable.

H2: A personal avatar and sentences such as “I’ll take care of it” could, in this process, suggest more extensive responsibility than the system actually has.

H3: The meaning of such signals may depend on whether someone is only looking for a collection location or wants to change an already paid booking.

H4: The problem may be caused by the website’s structure; an AI interface does not remedy the cause.

The meta-question is: Whose effort should decrease, and who bears the effort or risk when an answer is understood as more binding than intended? It shifts attention from the persuasive force of a conversation to the distribution of its consequences.

D – Mark uncertainty and revise the question

No user tests are available for the fictional business. It is unknown whether the avatar changes a role assumption in the relevant tasks, whether a start disclosure is noticed, whether the contact route can be found on small screens, and how a handoff works when no one can answer at that moment. These gaps may be filled neither by intuition nor by an invented percentage.

The model does not require selecting any hypothesis as the winner here. It requires a documented follow-up question or a fallback. The business can first check whether the static pages become more understandable and use a limited prototype with fictional test tasks. If an assumption remains unclear, it remains open. The documentation records what observation might later change it.

C – Record a better question and an action plan

The revision yields a narrower working question:

Which signals and functions does a limited digital bicycle-rental assistant need so that its actual role and limits are recognisable, a human handoff is possible for unsupported or consequential concerns, and the interaction can be ended without a loop?

A GROW action plan can organise the next step: Goal – a testable prototype in which function, limits, contact and ending are visible; Reality – which routes and responsibilities already exist; Options – a clearer website without AI, a neutral assistant, a warm tone with explicit role clarification, or a limited pilot; Will – a responsible role creates three prototype variants, documents assumptions and decides after a defined test whether one of them will be pursued. The plan does not answer the ethical question automatically. It only makes the next decision testable.

The visible change is decisive: instead of “How do we gain trust?”, the team now asks which information, responsibility and exit function make the actual role comprehensible. Optimising an effect becomes an examination of conditions, rights and limits.

5. The Consultation Model turns perspectives into a governance decision

Consultation Model K is broader than a vote on two drafts. It connects a learning objective, different perspectives, reflection, decision, implementation and evaluation. Its methodological basic cycle has four steps: Exploration → Reflection/Analysis → Decision-making/Recommendation → Feedback/Evaluation. [8] In the detailed case scenarios, implementation becomes visible as a separate pilot step; this produces a five-step case elaboration: exploration, reflection, decision, implementation/pilot and final evaluation/optimisation. These five steps are the extended scenario form of Model K, not its four-step basic cycle. They are also not the five phases of the separate Advisory Model R.

For the bicycle-rental business, exploration begins by identifying the actual tasks and roles: Who is looking for opening hours? Who answers booking changes? Who is responsible at the business? Which people need an alternative to chat? Not every perspective needs personal profiles. The exercise can work with fictional tasks and voluntary, data-minimising feedback.

In reflection and analysis, values come into tension. Fast self-service can be convenient; a clear limit can prevent the assistant from suggesting a change that has not been made. Repeated disclosure can support transparency but overload the page. A person available at any time would be useful, but may require staff resources. The model requires these tensions not to be resolved into a fictional score or an allegedly neutral consensus.

The decision must change a concrete, attributable rule. For the fictional business’s design, it could be: “The greeting identifies the assistant as a digital tool and names its supported tasks. For a request to change something, it immediately shows that it cannot change the booking and offers the actually available contact route. An end function remains visible.” This is an editorial product decision for the exercise case, not an empirically determined optimal solution.

The pilot does not measure “trust” or “ethical quality” with a single approval score. Instead, the business specifies observable examination questions in advance:

Can test participants correctly name the supported tasks? Do they recognise that the interface is digital and does not perform binding booking changes? Can they find the actual contact and end routes without detours? Is there an error case in which the assistant suggests a handoff that did not occur? Which user group or access situation is missing from the test setup?

Feedback/evaluation then examines whether a design rule must be changed. This includes qualitative feedback and simple task observations, not blanket monitoring of real conversations. Any real data collection would need a clear purpose, an appropriate legal and data-protection examination, and comprehensible information. A new misinterpretation reopens the governance decision: the role is not labelled once and then settled forever.

The Consultation Model therefore works here not by mentioning “stakeholders,” but by being able to change the preferred design. If test participants repeatedly understand a wording as confirmation of a booking, the wording is discarded. If a permanent contact option is not offered for lack of resources, the team may not act as though it were available; it must define an actually reachable alternative or reduce the scope of the function. Different perspectives are part of the decision, not decoration around a solution already fixed.

For teaching, the model proposes a 70/30 division of practice and theory as a design option. The number is not a validated dose and is not presented in this article as learning effectiveness. The proposed 45-minute exercise below can be adapted to the course objective and group independently of it.

6. Advisory Model R hands concrete legal questions to specialists

R is an independent five-phase specialist-review path for contractual, legal and regulatory questions. It does not begin with a spontaneous AI answer to “Is our chatbot legally compliant?” Its five phases are Preparation/Anamnesis → Analysis/Problem Definition → Advice/Solution → Implementation/Documentation → Evaluation/Follow-up. [9] The model creates a structured mandate and an evidence trail. It makes neither a course article nor a completed form into legal advice.

For the fictional assistant, a legal or compliance specialist review could require the following information:

1. Preparation/Anamnesis: collect the technology, concrete function, participating organisations and roles, contracts, records, data flows, communication channel, legal jurisdiction and reference date.

2. Analysis/Problem Definition: determine gaps, risks, opportunities and priorities in the named case; for example, clarify whether it concerns direct interaction with an AI system, consumer communication, the contractual effect of a statement, data protection or accessibility.

3. Advice/Solution: a qualified specialist develops possible solutions in professional collaboration, examines the current primary norm, and identifies conditions and open questions. The article does not decide this in advance.

4. Implementation/Documentation: responsible people implement the reviewed solution, document version, responsibility and evidence, and communicate the change to the affected roles. Even an understandably worded interface needs an actual process behind it.

5. Evaluation/Follow-up: follow up the outcome and open issues; make adjustments and review again when the function, organisation, provider, legal jurisdiction or material norm changes. An earlier review is not a timeless approval.

On 25 September 2026, the European Commission guidelines identify Article 50 of the AI Act as applicable from 2 August 2026. Article 50(1) concerns providers of AI systems intended for direct interaction with natural persons: they must design the system so that persons are informed that they are interacting with AI, unless this is obvious from the circumstances and context. Whether and how a particular organisation, function and interface fall within this is a specialist question. The bicycle-rental case is not legally classified here; the signal/role map replaces neither legal review nor evidence of compliance. [5]

The R→K handoff is as important as the referral to specialists. If the review returns a concrete condition or open question, the governance decision must be adjusted. Perhaps the interface needs clearer initial information; perhaps a performance promise must be removed; perhaps the use case needs to be limited differently. R therefore does not operate as a fifth stage of the K case elaboration. The two models have different tasks and inputs.

7. The signal, disclosure and exit map

The article’s working artefact is a map completed for a concrete interaction. Its fields prevent an observable sentence from being silently reinterpreted as a factual claim about users, the system or the company.

The map can be applied to three versions of the same product function:

Variant A – without AI: A structured information page with clear opening hours, locations, FAQs and a contact option. It can address the cause of a recurring question before a dialogue interface is added.

Variant B – matter-of-fact assistant: A short role description, limited task list, clear answers, and a contact and end route that remains findable.

Variant C – warm assistant: An attentive tone remains possible, but a humanising voice does not replace the role description and limits. It does not suggest that a booking change has been carried out.

No variant is the best solely on the basis of this description. For each one, the team documents which assumption it requires, which burden it creates for staff, which forms of access it opens or impedes, and which concrete observation would lead to a change. If the simpler information page reliably fulfils the task, a dialogue AI does not have to be used for reasons of prestige or modernisation.

8. A 45-minute exercise for courses and SMEs

Objective: Participants distinguish an observable signal, a possible interpretation and an actual product commitment. They practise a reasoned revision and derive from it a testable rule for disclosure, handoff and exit. What is assessed is the quality of the reasoning, not agreement with a prescribed solution.

Materials: two fictional cards with the same function and different interfaces. Card 1 uses an avatar, first person and a warm tone; card 2 uses a matter-of-fact presentation. Both have identical capabilities and limits. An information page without AI is available as a third option. No card contains real usage data or reconstructed conversation histories.

Procedure:

1. Minutes 0–5 – Initial question: “Which card seems more trustworthy?” The group records spontaneous answers, but marks that likeability, reliance and trustworthiness are different things.

2. Minutes 5–15 – F-A: Clarify terms and assumptions. Each group records visible elements verbatim and separates them from an assumed role. 5-Why examines which business or information problem the interface should solve. SCAMPER or a simple options round produces a non-AI alternative.

3. Minutes 15–22 – F-B: Formulate at least three competing hypotheses about possible interpretations or obstacles. A meta-question must state who receives a benefit and who would bear the consequences of a misunderstanding.

4. Minutes 22–27 – F-D: The group marks which hypothesis remains open for lack of evidence. It must not invent percentage values. It formulates which short, data-minimising observation could examine the assumption.

5. Minutes 27–37 – K: Exploration and reflection identify affected roles and the strongest objection. The group chooses a concrete product rule, such as changing the performance promise or providing a visible exit. It names a test condition and a revision trigger.

6. Minutes 37–42 – R handoff: If a legal question remains open, the group writes a specialist-review mandate with function, organisation, channel, legal jurisdiction, reference date and required documents. The group does not decide the legal question itself.

7. Minutes 42–45 – F-C: A new, narrowly framed question and a next step are recorded. The GROW plan names the goal, current state, options and a responsible action.

Submission criterion: a completed set of cards with (a) an observed signal, (b) an interpretation clearly labelled as a hypothesis, (c) an actual functional limit, (d) a chosen governance rule, (e) a real handoff/exit route, (f) an open specialist question and (g) a revision condition. Two reasoned but different decisions can be equally good when they disclose evidence, values, affected parties and limits.

In an SME workshop, the task can be shortened to 45 minutes or embedded in a longer prototype session. The group should not be pressed to describe personal experiences or private customer conversations. Test tasks can be wholly fictional. If real feedback is collected, it needs its own purpose, appropriate information, data minimisation and a suitable legal review.

9. A short rule for product teams

Before releasing a dialogue assistant, a small team can answer five questions in writing:

1. What is visible? Describe the concrete signals precisely, without presenting terms such as empathetic, understanding or reliable as system properties.

2. What is actually possible? Substantiate tasks, limits and the scope of the function relevant to users.

3. What can a person understand about the role? Mark possible interpretations as hypotheses and examine them with counterexamples.

4. What happens at a limit? Handoff, return to static information and exit must exist as actual processes, not merely as friendly wording.

5. Who changes the rule? Name responsibility, evidence, revision triggers and required specialist review.

These questions are a learning and governance tool, not a certificate. They can fit on one page for a small product team; they do not replace an in-depth examination where the use has significant consequences, involves special data or raises legal obligations. Their usefulness depends on whether answers are examined and changed when necessary.

Conclusion: friendliness needs a verifiable role

A friendly AI interface is neither automatically caring nor automatically misleading. It is a designed encounter whose role people can interpret differently. Scientific findings from narrowly defined tasks show that anthropomorphic signals, reliance and disclosure do not converge in one simple rule. Their limits are part of the result, not footnotes appended after a design decision.

Questioning Model F dismantles the premature search for an effect and develops a narrower question that remains open to revision. Consultation Model K requires the organisation to turn perspectives and counterpositions into a concrete governance rule that can be examined in a pilot. Advisory Model R hands only the precisely delimited legal and contractual questions to a responsible specialist review and returns its conditions to the product decision. None of these models supplies the “right” interface by itself.

For the fictional business, this means: a warm tone can remain if it does not blur the boundary between information and a booking change. An avatar need neither be removed as a matter of principle nor assumed harmless. Disclosure must be examined in the specific product and legal context. A person should not merely be reachable in a marketing sentence, but through a functioning route. And an exit becomes an option only when it is findable and usable.

The central question is therefore not whether an AI sounds nice. It is: Can the organisation substantiate the role its interface suggests—and can it act when people understand a different role?

Sources

1. Araujo, T. (2018). “Living up to the chatbot hype: The influence of anthropomorphic design cues and communicative agency framing on conversational agent and company perceptions.” Computers in Human Behavior, 85, 183–189. https://doi.org/10.1016/j.chb.2018.03.051.

2. de Visser, E. J., Monfort, S. S., McKendrick, R., Smith, M. A. B., McKnight, P. E., Krueger, F., & Parasuraman, R. (2016). “Almost human: Anthropomorphism increases trust resilience in cognitive agents.” Journal of Experimental Psychology: Applied, 22(3), 331–349. https://doi.org/10.1037/xap0000092.

3. Mozafari, N., Weiger, W. H., & Hammerschmidt, M. (2020). “The Chatbot Disclosure Dilemma: Desirable and Undesirable Effects of Disclosing the Non-Human Identity of Chatbots.” Proceedings of ICIS 2020, Paper 1415. https://aisel.aisnet.org/icis2020/hci_artintel/hci_artintel/6/.

4. Liu, J., Gao, Z., Kang, Y., Jiang, Z., He, G., Sun, C., Liu, X., & Lu, W. (2021). “Time to Transfer: Predicting and Evaluating Machine-Human Chatting Handoff.” Proceedings of the AAAI Conference on Artificial Intelligence, 35(7), 5841–5849. https://doi.org/10.1609/aaai.v35i7.16731.

5. European Parliament and Council. Regulation (EU) 2024/1689, Article 50(1), consolidated text dated 27 July 2026. EUR-Lex: https://eur-lex.europa.eu/eli/reg/2024/1689/2026-07-27/eng. European Commission, “Guidelines on transparency obligations for providers and deployers of certain AI systems,” last updated 6 August 2026: https://digital-strategy.ec.europa.eu/en/policies/guidelines-ai-transparency-obligations. Accessed 25 September 2026.

6. National Institute of Standards and Technology (2024). Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile. NIST AI 600-1. https://doi.org/10.6028/NIST.AI.600-1.

7. SAKIZLI.AI. Questioning Model v5 (German method version), pp. 1–3. Model sequence A → B → D → C; methodological description, not evidence of effectiveness.

8. SAKIZLI.AI. Consultation Model (German method version), basic cycle pp. 7–8; detailed case scenarios pp. 20–33. The four-part basic method and the separate five-part case elaboration are distinguished.

9. SAKIZLI.AI. Five-Phase Advisory Model (German method version), overview pp. 1–3; detailed discussion pp. 4–16. Methodological specialist-review path, not legal advice.

Note on the case: The bicycle-rental business, website, dialogues, tasks and product rules are entirely fictional. They do not claim an observed user effect, a real product property or legal compliance. The model descriptions explain methodological ways of working; they do not establish their scientific effectiveness.