Your Questions, predicted and answered.

Most AI tools labelled "AI-powered analytics" do one thing: translate your question into SQL and run it. If your question is ambiguous, or your column is called GRS_SLS_AMT instead of "revenue," the answer is wrong - confidently wrong, which is the most dangerous kind. Agentic reasoning means SmartenBoT works out what you actually mean before deciding how to query. It plans the approach, resolves the ambiguity, applies your business context, and chooses the right path to the answer - then explains how it got there. The difference shows up most clearly on the complex or imprecise questions, which are precisely the ones that matter most.

Accuracy depends on two things: how well your semantic layer is configured and how clearly the question is framed. For well-modelled datasets, SmartenBoT answers correctly the vast majority of the time. Crucially, every answer shows the logic, the columns used, the time period, and the assumptions made - so you can verify it rather than simply trust it. If something looks wrong, you ask it to explain or recalculate, and the conversation continues from there. It is designed to be auditable, not just authoritative.

This is handled through column polarity - a one-time configuration in the semantic layer that defines, for each metric, whether higher or lower is the favourable direction. Once set up, SmartenBoT applies it consistently across every question from every user. "Best machines by maintenance cost" returns the lowest-cost machines. "Top salespeople by discount given" returns those with the smallest discounts. No one has to add a note in the chat explaining which way round they mean - the platform already knows.

It tells you - which puts it ahead of a surprising number of alternatives. SmartenBoT does not guess or fabricate. It states clearly when the data needed to answer the question is not in your datasets. Where a question depends on events outside your data, such as a competitor's pricing change or an unplanned factory closure, SmartenBoT flags that too (see Q16).

This is exactly what the semantic understanding layer is for. SmartenBoT maps your internal vocabulary - acronyms, synonyms, informal terms, historical naming conventions that nobody remembers the origin of - to the correct columns and values in your data. Once configured, any of those three terms resolves to the same underlying metric. Users never need to know the technical column name or agree on a single "official" term. The configuration is done once and applies to every user's queries from that point forward.

Yes. SmartenBoT identifies which datasets a question requires and joins them automatically during the reasoning process. You do not need to pre-build a combined view or tell it which sources to use. The data preparation layer underneath handles connecting, cleansing, and blending across multiple sources - including the five-year-old flat files, which are not disqualified for being vintage. Everything that is modelled and published is available to the conversational layer.

Every SmartenBoT response combines a visualisation and a written summary in a single reply. The chart or table and the written explanation appear together - the explanation stating the metric used, the time period, the logic applied, and any assumptions made. You are not choosing between a chart and an explanation. You get both, in context, every time. You can then ask a follow-up and the next answer builds on that same context, with a new chart if the data warrants it.

No - and if you have ever typed "same as above but by region" into a report request email, you will appreciate this. Context is retained across the entire conversation. Once you establish a metric, time period, dimension, or filter in an earlier question, every follow-up inherits it automatically. "Now break that down by plant" or "Compare it to the same period last year" works exactly as you would expect in a conversation with a human analyst.

SmartenBoT has two levels of memory. Within a session, context flows across every question. Across sessions, persistent memory carries preferences and earlier conversations forward - you do not start from scratch each Monday morning as if nothing has been established. You can also explicitly save a chat and resume it later with the full context intact, which is particularly useful for ongoing investigations that span more than one sitting.

Your data is never stored on the SmartenAI server. When a question is asked, SmartenBoT queries your data where it already lives - in your own infrastructure - and returns the result. The underlying data does not move and is not cached on external servers. What travels is the question and the query result - not the dataset itself. The query result is processed by the LLM on the SmartenAI server only for the duration of the session and is released as soon as the session ends.

SmartenBoT is LLM-agnostic by design. You have the freedom to switch the LLM - you are not permanently married to a single AI provider. If your compliance requirements, data residency policy, or infrastructure preferences call for a specific model - including a private or on-premise one - that can be configured. The LLM is a replaceable component of the architecture, not the architecture itself.

The meaningful differences are architectural, not cosmetic. Microsoft's AI features process data through Microsoft's cloud - your data and query context travel to their infrastructure. SmartenBoT queries your data in your own environment. Microsoft's conversational AI also requires significant Fabric capacity for enterprise workloads, and is bundled with a specific data platform. SmartenBoT is designed as an embeddable, platform-independent conversational layer with LLM flexibility. SmartenBoT does not store your data in Smarten's cloud or on the SmartenAI server; it uses only the query result needed to answer the question and releases it once the session ends.

Dashboards answer the questions their builder anticipated - usually at nine in the morning, on a good day, when the requirements were clear. Conversational analytics answers the questions users think of in the moment, including the ones nobody built a report for and the ones that only occur to you after you have seen the first number. The two serve different purposes: dashboards for structured review, SmartenBoT for investigation, root-cause analysis, and the kind of iterative drilling that dashboards approximate through many clicks. "Why did the North region drop last quarter?" is not a dashboard question. It is a conversation.

Yes. SmartenBoT supports multilingual Q&A - ask in any language and it responds in that same language. No additional configuration is required per language, and there is no requirement to standardise on English as the operational language of analytics. Teams in different regions can interact with their data naturally, in the language they think in, not the language the system was built in.

SmartenBoT has two features for this. Autocomplete finishes the question as the user types, suggesting the right metric, field, or value from what is actually in the data. Look-ahead goes a step further and suggests the next relevant question based on the conversation so far - even before the user has typed anything. Together they solve the blank-page problem - the paralysis of opening a chat interface and not knowing where to begin. As the conversation develops, the suggestions adapt to the current context. Even users who have never used an analytics tool before can find their way to useful answers without needing to know what a dimension is.

SmartenBoT is built with external context awareness. When an answer requires information not present in your data - market events, seasonal factors, an unplanned event - it flags this explicitly rather than producing an answer that silently ignores the gap. This is the difference between a system that gives you a confident-sounding answer that is wrong and one that tells you what it knows and is clear about what it cannot determine from the data it has access to.

SmartenBoT enforces data access at the query level, not the interface level. It inherits your existing role-based access rights and row-level security - every query is automatically filtered to return only the data that user is permitted to see. This cannot be bypassed by rephrasing the question or asking creatively. The access control is structural, not dependent on what the user types.

Comprehensively. Row-level security is applied to every query SmartenBoT runs, so each user sees only the rows they are authorised to see - by region, business unit, customer, or any other rule you define. SmartenBoT inherits the roles, permissions, and security rules already set in the data environment, so there is no second security model to build or keep in sync. Because these rules are tied to the identity of the logged-in user, not to what is typed in the chat, they cannot be bypassed through the conversation - no rephrasing, prompt, or request to "show all data" can widen what a user is permitted to see. The same rules apply to every follow-up question, every saved chat that is resumed later, and every embedded deployment. Governance extends beyond access: SmartenBoT works only with published, governed datasets, and metric definitions, synonyms, and business rules are managed centrally in the semantic layer. Every user, in every department, gets answers based on the same approved definitions. Data stays in your environment and is never stored on the SmartenAI server (see Q10). Security and governance are built into the platform, not left to how carefully a user words a question.

When you embed SmartenBoT via API, it is native to your product - your interface, your branding, your workflow. Your customers interact with your product. There is no separate login, no context switch, and no visible Smarten or SmartenBoT identity unless you choose to surface it. From your customer's perspective, they are talking to your product. Which is exactly the point.

Implementation has three layers. First, the data preparation layer - connecting your sources, cleansing, blending, and publishing datasets. Second, the semantic layer - mapping your business vocabulary, setting column polarity, defining hierarchies and synonyms so questions are interpreted correctly for your specific context. Third, the integration layer - embedding via API for ISVs and SIs, or deploying the ready-to-use interface for in-house teams. For organisations already running on Smarten datasets, only the third step applies, and most teams are live in approximately one week.

No. Changes to your data model require updating the corresponding dataset and, where relevant, the semantic layer mapping for the affected fields. Existing configurations for everything else remain intact. The platform is designed to evolve with your data - you update what changed and the rest continues to work as it did before. It does not treat a renamed column as an existential crisis.

For most queries on well-modelled datasets, responses return in seconds. Complex multi-dataset joins or very large data volumes take a little longer, but the conversational interface is designed for real-time use - including the specific situation where a senior stakeholder asks an unexpected question and the room goes quiet. Getting an answer in that moment is, it turns out, considerably better than saying "I'll follow up with a report by end of week."

SmartenBoT is connected to your business data, not the internet. If a user asks about the weather, the cricket score, or the meaning of life, it will let them know - politely - that it cannot answer from your datasets and redirect toward the data it does have. It is a business analyst, not a general-purpose assistant. It stays in its lane, which is a quality more analysts should have.

The investigative questions: What happened, Who drove it, When did it change, Where is the concentration, and Why. These five questions represent most of what business users actually need from data, and they are exactly what dashboards answer poorly - because dashboards reflect the questions the dashboard builder anticipated, not the ones that occurred to you this morning. SmartenBoT answers all five in plain language, in any order, in any combination, with each answer building on the last. The full investigative arc - from initial question to root-cause conclusion - happens in one conversation.

The interface is a chat window. If your users have used any messaging application, they can open SmartenBoT and ask a question. Two built-in features help along the way: autocomplete finishes the question as the user types, suggesting the right metric, field, or value from the data; look-ahead suggests the next relevant question based on the conversation so far, so users who do not know where to begin always have a place to start. The explainability in every answer teaches users what is possible as they go. That said, a short orientation - twenty minutes, not two days - that helps users understand what kinds of questions work well and how to interpret the answers does accelerate adoption meaningfully. The goal is to go from "I did not know I could ask that" to "I ask this every morning" as fast as possible.