EMB app in use.png

The challenge: answering everyday billing questions without a phone call

The questions customers ask are common and predictable, but the answers are not generic. ‘Has my bill gone up?’ depends on this customer’s billing history; ‘what can I do about my balance?’ depends on whether they are in credit or debit, and whether they pay by direct debit. Static FAQs and scripted phone menus cannot personalise to that level, so can end up routing the customer to an agent anyway.

What was needed was a way to give a natural-language, account-aware answer to a fixed set of approved questions — accurate enough to trust, constrained enough to be safe, and cheap enough to change as the business learns what customers actually ask.

The architecture: proven models behind APIM

The app does not talk to a model directly. A question travels down the app’s existing layers — view model to facade to repository — and out through the organisation’s API management gateway (APIM) to a proven, hosted model. The gateway authenticates the app with a subscription key and forwards a structured request containing a system message and the user message.

The request the model receives has two parts: a system message carrying the company’s rules, and a user message combining the chosen question with a compact, non-identifying snapshot of the account:

// request sent via APIM
{
    System: "<company rules + guard-rails>",
    User: "{question}\\n\\n----------\\n\\n{accountData}"
}

Because the model sits behind the gateway, it is backend-controlled: the business can upgrade or swap the underlying model as the field improves, with no change to the app. The app depends only on a stable, strongly-typed contract — not on any particular model or vendor.

Configured from the portal, not the app store

The questions a customer sees, the system message that governs the model, the per-question prompts, and even whether the feature is switched on at all, are not baked into the app. They are fetched from the content portal at runtime.

Each refresh pulls down whether the feature is active, the percentage of users it is rolled out to, the system message, and the list of questions with their prompts. This means the business can reword a question, tighten a rule, add a new approved enquiry, or dial the rollout up and down — all from the portal, with no release and no app-store review cycle. The same mechanism restricts who sees the feature while it is being proven.

In practice that turns prompt engineering into a configuration activity rather than a development one. The people who understand billing policy can iterate on the wording and the rules directly.

Safe by design: non-identifying data and layered rules

Safety is built in at two levels. First, the account data sent to the model is deliberately non-identifying. It is a small JSON payload of billing and meter facts only — balances, dates, amounts and flags — with no name, address, email or phone number:

{
  "balance": -42.50,
  "lastBillAmount": 96.00,
  "previousBillAmount": 78.00,
  "nextPaymentDate": "2026-07-01",
  "paysByDirectDebit": true,
  "hasWaterMeter": true
}

Second, the model is constrained by layered rules. The system message sets company-wide policy, and each question can wrap its prompt in explicit guard-rails — for example, instructing the model to stay strictly within billing matters and never to request or repeat personal information:

<RULE>Don't send personal information.</RULE>
<RULE>Only provide information related to customer billing.</RULE>
{question prompt}

Because both the payload shape and the rules are controlled centrally, the safety posture can be reviewed and tightened in one place, and applied to every question at once.

Tailored to the account

Tailoring happens before the model is ever called. The app inspects the live account state and removes questions that do not apply — hiding a ‘why has my bill increased?’ option when the bill has not increased, or credit/debit-specific questions that do not match the current balance. The customer is only offered questions that make sense for their situation.

The answer is then framed with contextual follow-up actions — making a payment, setting up a direct debit, or finding financial support — so the feature does not just explain the bill, it points to the next useful step.

Tested without a real account: the AI utility tool

Because the question data originates from the portal, the same questions and rules can be exercised outside the customer app. A small internal utility tool reuses the production services but lets a tester supply draft account data and fire the live portal questions at the model, then read back the response.

This gives the team a safe loop for prompt engineering: try a wording, see how the model answers for a given account shape, adjust the rule or the prompt in the portal, and try again — all without a real customer account and without shipping anything.

Proven safe by the test suite

AI responses are non-deterministic, so the automated tests focus on the deterministic plumbing around them — and they do so thoroughly. Unit tests assert that questions are filtered correctly for a given account state, that the expected rules are wired onto each question, that selecting a question navigates with the right parameters, and that the feature’s availability and rollout gating behave as configured.

The two halves are complementary: the test suite proves the scaffolding is correct and stable, while the AI utility tool validates the quality of the model’s answers by hand. Together they cover both ‘does the machinery work?’ and ‘is the answer any good?’.

Why this matters

For a feature that sounds ambitious on paper, the value is concrete and low-risk:

  • Deflects common contacts — predictable, account-specific questions are answered in the app, freeing agents for complex cases.

  • Controllable without releases — questions, prompts, rules, availability and rollout all change from the portal, instantly and reversibly.

  • Safe by construction — no personal data leaves the device with the question, and layered rules constrain the model in one central place.

  • Future-proof — the model sits behind the gateway, so it can be upgraded as the field improves with no app change.

Towards a reusable AI-assist framework for mobile

Nothing about this approach is specific to billing. The pattern — a strongly-typed contract to a backend-controlled model, portal-driven questions and rules, a non-identifying data payload, and account-aware filtering — is a reusable foundation for any ‘explain my …’ journey.

New assisted experiences can be added largely as configuration plus a small, non-identifying data payload for that domain, reusing the same safety model, rollout controls and test patterns already proven here.

In short

For a feature that sounds ambitious on paper, the value is concrete and low-risk:

  • AI is most valuable when it is narrow and safe. A fixed set of approved questions, answered against the customer’s own account, deflects everyday contacts without exposing the business to open-ended risk.

  • Configuration beats releases. Driving the questions, prompts, rules and rollout from the portal means the feature evolves at the speed of the business, not the app store.

  • Safety is a design choice. Non-identifying data and layered, centrally-managed rules make the feature safe by construction — and the test suite proves the machinery around it stays correct.