# Pulse Energy — UX discovery board V2


12 September 2026. Version 1 preserved. Expert interpretation and proposed experience; no measured uplift.


## Annotated journey


### 01. Homepage — P2


Evidence: Electricity, gas and broadband share the homepage. JOIN NOW is the main hero action; My Account and Current Customer provide returning-customer entry.


Limit: The captured state also shows the Contact menu. Multiple join links lead to different campaign URLs.


Customer question (hypothesis): Where do I start for my task?


**Keep:** The hero names the services and offers a clear joining action; returning customers have a My Account entry.


**Improve:** Multiple acquisition and support routes compete. A first-time visitor may need to learn the navigation before comparing an offer.


**Proposed:** Keep one primary Check prices action, with visible Pay a bill, Move home and Get help shortcuts. Carry the selected task through the next domain.


**Validate:** Run a first-click study for joining, paying and moving; check keyboard access to menus.


**Measure:** First-click accuracy and time to the correct task.


References: [Meridian · account and moving help](https://www.meridianenergy.co.nz/help/for-home), [Nielsen Norman Group · usability heuristics](https://www.nngroup.com/articles/ten-usability-heuristics/)


### 02. Request a call — P2


Evidence: A promotional pop-up asks for name, phone, email and service interest. A close control returns the visitor to browsing.


Limit: Observed automatically during this visit. Submission and the resulting callback were not tested.


Customer question (hypothesis): Will asking for help trigger a sales call?


**Keep:** A callback offers an assisted route and the pop-up can be dismissed.


**Improve:** An automatic contact request interrupts browsing and asks for several details before the customer knows the price. The extent of follow-up is not demonstrated.


**Proposed:** Make callback an explicit choice. State contact purpose and an operationally achievable response window; ask only what the chosen channel requires.


**Validate:** Compare opt-in help with the automatic pop-up; verify focus containment and restoration.


**Measure:** Callback completion, unwanted-contact complaints and quote progression.


References: [GOV.UK · question pages](https://design-system.service.gov.uk/patterns/question-pages/), [W3C WAI · accessible forms](https://www.w3.org/WAI/tutorials/forms/)


### 03. New Customer menu — P2


Evidence: Two choices: Join or Compare rates. Join opens the $180 offer on the separate sign-up domain in a new tab.


Limit: This is the entry followed for the new residential electricity journey below.


Customer question (hypothesis): Does Compare rates show prices now?


**Keep:** Join and Compare rates recognise two useful customer intentions.


**Improve:** Compare rates leads to a contact request rather than an immediate comparison. The label may create a different expectation from the next page.


**Proposed:** Distinguish See prices for my home from Ask us to compare a bill. State what each path delivers and when.


**Validate:** Ask prospects to predict each destination before opening it.


**Measure:** Expectation match and backtracking from the comparison form.


References: [Nielsen Norman Group · usability heuristics](https://www.nngroup.com/articles/ten-usability-heuristics/), [Meridian · public plan comparison](https://www.meridianenergy.co.nz/for-home/pricing-rates)


### 04. Compare rates — P1


Evidence: The page requests contact details, comments and an optional recent power bill. The customer-care team provides the comparison later.


Limit: Full page available on click. The artboard displays the form section. CAPTCHA and Submit are visible; no request was sent.


Customer question (hypothesis): Can I compare without waiting or uploading a bill?


**Keep:** Bill upload supports a tailored assisted comparison for customers who need it.


**Improve:** Contact fields, comments and CAPTCHA create effort before a result. The captured page does not provide a self-service comparison.


**Proposed:** Offer an address-led estimate where pricing permits. Keep optional bill-based comparison with a clear turnaround and alternative to uploading.


**Validate:** Confirm quote-engine inputs before removing fields; test error recovery and an accessible CAPTCHA alternative.


**Measure:** Time to useful comparison, qualified sign-ups and assisted resolution time.


References: [GOV.UK · question pages](https://design-system.service.gov.uk/patterns/question-pages/), [W3C WAI · accessible forms](https://www.w3.org/WAI/tutorials/forms/), [Meridian · public plan comparison](https://www.meridianenergy.co.nz/for-home/pricing-rates)


### 05. Address-first sign-up — P2


Evidence: The $180 first-bill offer is limited to new residential electricity customers. Address entry starts the online journey.


Limit: The page links terms, eligibility and early-termination fees and introduces service bundling below the hero.


Customer question (hypothesis): What will I pay after the joining incentive?


**Keep:** The address-first entry is relevant to energy eligibility and the offer links to conditions.


**Improve:** A prominent initial credit may distract from ongoing costs, term and exit conditions. Later price screens were not reached, so their disclosure quality is unknown.


**Proposed:** Alongside the offer, preview the information customers will get: ongoing rates, daily charge, estimated total, contract conditions and promotion expiry.


**Validate:** Test offer comprehension, including the post-promotion position, without prompting.


**Measure:** Correct understanding of ongoing cost and offer conditions.


References: [Nielsen Norman Group · usability heuristics](https://www.nngroup.com/articles/ten-usability-heuristics/), [GOV.UK · check answers](https://design-system.service.gov.uk/patterns/check-answers/), [Meridian · public plan comparison](https://www.meridianenergy.co.nz/for-home/pricing-rates)


### 06. Alternative: enter ICP — P2


Evidence: Selecting “Enter your ICP manually” reveals an ICP field and GET A PRICE. Address entry remains an alternative.


Limit: ICP is not explained beside this control. The address route was used for the following screens.


Customer question (hypothesis): What is an ICP and where would I find it?


**Keep:** An ICP fallback can help when address matching fails.


**Improve:** Technical terminology adds recall effort; no explanation is visible beside this control.


**Proposed:** Explain ICP in plain language, show where to find it on a bill and retain an address-help route.


**Validate:** Test with people unfamiliar with energy terminology; label and announce format errors.


**Measure:** Successful recovery from unmatched addresses.


References: [GOV.UK · question pages](https://design-system.service.gov.uk/patterns/question-pages/), [W3C WAI · accessible forms](https://www.w3.org/WAI/tutorials/forms/), [Nielsen Norman Group · usability heuristics](https://www.nngroup.com/articles/ten-usability-heuristics/)


### 07. Select the matched address — P2


Evidence: The user-provided 38 Tokai Place address returns an autocomplete result. Selecting it loads the property-specific sign-up form.


Limit: The result shows “Auckland, Auckland 602”; the following summary resolves the suburb as Glen Eden.


Customer question (hypothesis): Is this definitely my property?


**Keep:** Autocomplete returns a selectable match and reduces manual entry.


**Improve:** The displayed location string differs from the later property summary. Even a valid lookup may look unreliable when address formatting changes.


**Proposed:** Use a consistent formatted address and ask customers to confirm the supply point. Provide No match and Wrong property recovery.


**Validate:** Check apartments, rural addresses, duplicate street names and keyboard autocomplete.


**Measure:** Wrong-property corrections and successful address matches.


References: [W3C WAI · accessible forms](https://www.w3.org/WAI/tutorials/forms/), [Nielsen Norman Group · usability heuristics](https://www.nngroup.com/articles/ten-usability-heuristics/)


### 08. Find My Price: property — P1


Evidence: The property summary supplies address, ICP, Standard User and promo code 180OFF. Holiday-home and user-type switches precede contact fields.


Limit: The visible four-step navigation is Find My Price → Choose Your Plan → Build Your Plan → Your Details. The page asks customers to have identity documents and moving dates ready.


Customer question (hypothesis): Why do you need my contact details to show my price?


**Keep:** Property details are carried forward and the four-step journey names what comes next.


**Improve:** The first stage includes contact collection and user-type choices before price visibility. Customers may not understand why these are needed or whether Standard User is suitable.


**Proposed:** Test a price preview before optional follow-up details. Explain any truly required contact field and make tariff assumptions visible and editable.


**Validate:** Validate pricing and contact requirements with operations; compare comprehension and completion in a prototype.


**Measure:** Price-view rate, completed sign-ups and quote accuracy.


References: [GOV.UK · question pages](https://design-system.service.gov.uk/patterns/question-pages/), [Nielsen Norman Group · usability heuristics](https://www.nngroup.com/articles/ten-usability-heuristics/)


### 09. Required contact fields — P1


Evidence: FIND MY PRICE with empty fields shows individual errors for first name, mobile number and email. The customer cannot advance to prices with these fields empty.


Limit: The page states that Pulse may contact customers who do not complete sign-up. This is an early contact-data requirement before plan comparison.


Customer question (hypothesis): Can I continue without agreeing to follow-up?


**Keep:** Empty submission produces individual errors for the required contact fields.


**Improve:** The flow blocks price discovery until name, mobile and email are supplied; the page also says Pulse may contact incomplete applicants. This is a trust and conversion hypothesis, not measured abandonment.


**Proposed:** Separate necessary quote inputs from optional follow-up permission where feasible. Keep entered values, an error summary and clear field guidance.


**Validate:** Audit actual data dependencies; test with prospective customers and measure before/after only after instrumentation.


**Measure:** Quote-to-price completion; guardrails: lead quality, complaints and pricing errors.


References: [GOV.UK · question pages](https://design-system.service.gov.uk/patterns/question-pages/), [W3C WAI · accessible forms](https://www.w3.org/WAI/tutorials/forms/)


### 10. Current Customer menu — P2


Evidence: The menu exposes My Account, account balance, support, moving, LPG refill, direct debit, payment options and other help.


Limit: The larger menu mixes account tasks with support information. The homepage Pay Bill link also points to the portal.


Customer question (hypothesis): Which route gets this account task done?


**Keep:** The menu exposes a broad range of support and account tasks, including moving and payment options.


**Improve:** Information pages and actions share a large menu. Customers may not know which paths require login.


**Proposed:** Group around customer tasks and label account-only actions. Keep public help available without making login a universal gate.


**Validate:** Tree-test bill, account, moving and broadband tasks.


**Measure:** Task-find success and unnecessary login detours.


References: [Electric Kiwi · Kiwi Central](https://www.electrickiwi.co.nz/mobile-app), [Meridian · account and moving help](https://www.meridianenergy.co.nz/help/for-home), [Nielsen Norman Group · usability heuristics](https://www.nngroup.com/articles/ten-usability-heuristics/)


### 11. Log in — P2


Evidence: Email and password, Show Password, recovery and registration links. The portal describes bills, balances, payments, services and usage.


Limit: Help is prominent. The small dashboard pictured here is a marketing image; the logged-in UAT dashboard from the supplied prior audit appears in C2; production access was not inspected.


Customer question (hypothesis): Am I joining Pulse or accessing my existing account?


**Keep:** Show Password, registration and recovery are visible; the portal explains its value.


**Improve:** A separate domain and a registration route can blur the difference between buying energy and enabling online access.


**Proposed:** Use Already a Pulse customer? and Register online access labels. Explain the domain transition and support password managers and pasted credentials.


**Validate:** Test login with keyboard and password managers; accessible-authentication support is unverified.


**Measure:** Successful login, recovery completion and misrouted new customers.


References: [W3C · accessible authentication](https://www.w3.org/WAI/WCAG22/Understanding/accessible-authentication-minimum.html), [Nielsen Norman Group · usability heuristics](https://www.nngroup.com/articles/ten-usability-heuristics/)


### 12. Register for My Account — P2


Evidence: Existing customers register online access using an email address and Pulse account number. Register is disabled while fields are empty.


Limit: This creates access to an existing energy account. Activation, email verification and successful registration were not tested.


Customer question (hypothesis): Where is my account number?


**Keep:** Registration asks for just email and an existing account number.


**Improve:** The account-number dependency can strand people who do not have a bill handy. A disabled button alone does not explain missing or invalid inputs.


**Proposed:** Show a bill example locating the number, explain email matching, and offer a recover-account route. Confirm the next verification step.


**Validate:** Test with first-bill and multi-account customers; inspect labels and status announcements.


**Measure:** Activation completion and account-number-related support contacts.


References: [W3C WAI · accessible forms](https://www.w3.org/WAI/tutorials/forms/), [W3C · accessible authentication](https://www.w3.org/WAI/WCAG22/Understanding/accessible-authentication-minimum.html)


### 13. Recover password — P2


Evidence: The recovery screen asks for an email address and offers a route back to sign-in. Recover Password is disabled while empty.


Limit: No recovery email was requested. The email, reset-link and password-change experience remains unobserved.


Customer question (hypothesis): What happens after I request a reset?


**Keep:** Password recovery is short and provides a route back to sign-in.


**Improve:** Only the empty state was observed. Delivery, expiry, resend and success states remain evidence gaps rather than confirmed defects.


**Proposed:** Design a clear, privacy-preserving confirmation, resend route and expiry recovery. Preserve the task after successful sign-in.


**Validate:** Capture the complete authorised reset journey; test email delay and expired links.


**Measure:** Reset completion and time to regained access.


References: [W3C · accessible authentication](https://www.w3.org/WAI/WCAG22/Understanding/accessible-authentication-minimum.html), [Nielsen Norman Group · usability heuristics](https://www.nngroup.com/articles/ten-usability-heuristics/)


### A1. Dashboard — P1


Evidence: The dashboard brings balance, payment actions and service usage together. The audit flags Pay Now beside a zero balance, competing financial figures, and shared header/navigation problems.


Limit: Findings 1–10 below retain the source numbering. Imported UAT screenshot; the logged-in production state has not been rechecked.


Customer question (hypothesis): Do I owe money, and what should I do now?


**Keep:** A calm card layout combines payment and service usage; direct debit is near the payment action.


**Improve:** The UAT capture shows Pay Now with zero due, several money figures and an overflowing greeting. The chat launcher competes with View more.


**Proposed:** Lead with one dated account state and a state-appropriate action. Keep ledger detail expandable; label the property switcher and make navigation consistent.


**Validate:** Recheck in production, then test whether customers identify amount due, date and next action without explanation.


**Measure:** Balance comprehension, accidental payment starts and billing contacts.


References: [Octopus UK · usage in money and units](https://octopus.energy/blog/track-my-energy-use/), [Nielsen Norman Group · usability heuristics](https://www.nngroup.com/articles/ten-usability-heuristics/), [Supplied My Account audit · 8 August 2026](https://labs.pulseenergy.dev/prototypes/audit/my-account-audit.html)


### A2. Bills — P1


Evidence: Billing history combines statements, payment details and SmoothPay information. The audit flags missing payment status and billing periods, a long ungrouped list, repeated download buttons and an email route to SmoothPay.


Limit: Findings 11–19. Preview shows the upper page; click to inspect the complete 31-statement capture. Filters, downloads and payment actions were not tested in this run.


Customer question (hypothesis): Was that bill paid, and which period did it cover?


**Keep:** Statements, bank details and SmoothPay information appear on one page.


**Improve:** The UAT list has repeated primary buttons, no visible paid/due status or billing periods, a large historical gap and an email route to SmoothPay.


**Proposed:** Use readable statement rows with period, amount and reconciled payment status. Add year grouping and preset filters; explain payment-plan eligibility before setup.


**Validate:** Confirm billing data can support accurate statuses; validate credit and partial-payment cases.


**Measure:** Correct bill retrieval, status comprehension and payment-plan completion.


References: [Mercury · SmoothPay eligibility and setup](https://www.mercury.co.nz/help-and-support/billing-and-payments/smoothpay), [Meridian · account and moving help](https://www.meridianenergy.co.nz/help/for-home), [Nielsen Norman Group · usability heuristics](https://www.nngroup.com/articles/ten-usability-heuristics/), [Supplied My Account audit · 8 August 2026](https://labs.pulseenergy.dev/prototypes/audit/my-account-audit.html)


### A3. Electricity usage — P1


Evidence: Daily/monthly controls and a year filter sit above a kWh chart. The audit flags absent cost context, unexplained blank months and an unclear Compare action.


Limit: Findings 20–25. Chart interaction, keyboard support, text alternatives and export availability require live verification; static captures cannot establish their absence.


Customer question (hypothesis): What did my electricity cost, and why did it change?


**Keep:** Daily/monthly controls and a year filter expose basic usage exploration.


**Improve:** The UAT view is kWh-only, with unexplained empty months and a Compare label that does not describe its comparison. Static evidence cannot establish keyboard or tooltip behavior.


**Proposed:** Provide money/units views, a named comparison period, fresh-data labels and a table alternative. Reconcile cost scope with the bill.


**Validate:** Verify rates, GST, daily charges and meter coverage; test chart interpretation and assistive technology.


**Measure:** Cost comprehension, reconciliation accuracy and usage-related contacts.


References: [Mercury · usage and cost breakdown](https://www.mercury.co.nz/electricity/usage), [Octopus UK · usage in money and units](https://octopus.energy/blog/track-my-energy-use/), [AGL · usage and projection calculations](https://www.agl.com.au/help-support/account-setup-management/energy-usage-calculations), [W3C · WCAG 2.2](https://www.w3.org/TR/WCAG22/), [Supplied My Account audit · 8 August 2026](https://labs.pulseenergy.dev/prototypes/audit/my-account-audit.html)


### A4. Broadband usage — P1


Evidence: The page combines usage totals, plan information and a monthly chart. The audit flags zero usage without a clear freshness explanation, missing-data ambiguity, inconsistent units and small plan text.


Limit: Findings 26–31. Figures and plan prices belong to the captured UAT account on 8 August; they are not a current offer or a verified service status.


Customer question (hypothesis): Is zero usage real, or is the data missing?


**Keep:** Broadband usage and the named plan are visible together.


**Improve:** The UAT summary shows zero while earlier months have usage; no clear last-read state resolves the uncertainty. Fine print and number formats vary.


**Proposed:** Distinguish no reads from zero consumption; show last update and a next step. Add relevant connection troubleshooting and plan-management routes.


**Validate:** Recheck real data states and the service API; test stale, disconnected and newly connected scenarios.


**Measure:** Correct state interpretation and avoidable broadband contacts.


References: [Electric Kiwi · Kiwi Central](https://www.electrickiwi.co.nz/mobile-app), [Nielsen Norman Group · usability heuristics](https://www.nngroup.com/articles/ten-usability-heuristics/), [Supplied My Account audit · 8 August 2026](https://labs.pulseenergy.dev/prototypes/audit/my-account-audit.html)


### 14. Account and current property — P1


Evidence: Customers enter their account number, contact details, current address, optional promo code and final meter reading, then their move-out date.


Limit: Urgent sign-up or reconnection is directed to the phone. The page says existing direct debit continues for the new property.


Customer question (hypothesis): Why am I re-entering details you already know?


**Keep:** The moving form covers account/current-property details and directs urgent cases to a phone channel.


**Improve:** A long public form requires account information without an observed authenticated shortcut. Date defaults may be mistaken for an intentional selection.


**Proposed:** Offer a signed-in route with confirmed saved details and an accessible guest fallback. Start with urgency and current/new-property dates.


**Validate:** Verify authenticated moving before assuming it is missing; test renters, owners and overlapping properties.


**Measure:** Move completion, re-entry effort and date corrections.


References: [Meridian · account and moving help](https://www.meridianenergy.co.nz/help/for-home), [AGL · track a new connection](https://www.agl.com.au/help-support/moving-meters-connections/track-new-connection), [GOV.UK · question pages](https://design-system.service.gov.uk/patterns/question-pages/)


### 15. New property and services — P1


Evidence: New address, move-in date and meter location lead into medical-dependency, usage type, gas, access, power status and broadband questions.


Limit: Several No answers and Standard usage are preselected in the empty form. Dates initially show the capture date.


Customer question (hypothesis): Which questions apply to my move?


**Keep:** Service and access questions could support a coordinated connection.


**Improve:** Many questions and preselected No answers demand sustained attention; medically dependent or unusual-property cases may be missed.


**Proposed:** Group by current home, new home and services. Reveal relevant questions progressively and require deliberate answers to consequential questions.


**Validate:** Review defaults with service operations; test conditional logic and recoverable back navigation.


**Measure:** Incomplete requests and corrections to dates, access or support needs.


References: [GOV.UK · question pages](https://design-system.service.gov.uk/patterns/question-pages/), [W3C WAI · accessible forms](https://www.w3.org/WAI/tutorials/forms/)


### 16. Terms and submission — P1


Evidence: The final section includes terms acceptance, a link to the terms, CAPTCHA and Submit. This is still the same public form.


Limit: No details were entered, terms accepted or move requested. Validation, confirmation and follow-up were not tested.


Customer question (hypothesis): Has my move been arranged, and when will power be on?


**Keep:** Terms and submission are visible at the end of the public form.


**Improve:** Review, confirmation and status were not observed. The long-form submission boundary provides no evidence of what assurance customers receive afterwards.


**Proposed:** Add a check-answers step and a receipt with reference, confirmed versus requested dates, remaining actions and trackable progress.


**Validate:** Observe an authorised completed move before claiming any current confirmation is absent.


**Measure:** First-time-complete requests and where-is-my-move contacts.


References: [AGL · track a new connection](https://www.agl.com.au/help-support/moving-meters-connections/track-new-connection), [GOV.UK · check answers](https://design-system.service.gov.uk/patterns/check-answers/)


### 17. Fern launcher — P2


Evidence: A fixed bottom-right “Need Help? Chat with Fern” launcher introduces the assistant with a character portrait. Opening it keeps the website visible behind a right-side panel.


Limit: The promotional callback pop-up also appeared during this visit. Minimizing and reopening Fern preserved this session’s conversation.


Customer question (hypothesis): Can this assistant help with my problem?


**Keep:** Fern is discoverable and stays alongside the page; the conversation persisted when reopened in this session.


**Improve:** A floating launcher and callback pop-up can compete for space and attention. Session persistence beyond this test is unknown.


**Proposed:** Keep a predictable safe area and a clear scope label. Preserve the current page and task when chat opens or closes.


**Validate:** Check zoom, small desktop windows, focus and collision with important controls.


**Measure:** Assistance discovery and obscured-control incidents.


References: [Electric Kiwi · Kiwi Central](https://www.electrickiwi.co.nz/mobile-app), [W3C · minimum target size](https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum.html), [Nielsen Norman Group · usability heuristics](https://www.nngroup.com/articles/ten-usability-heuristics/)


### 18. Welcome and Message us — P2


Evidence: The first panel says Welcome and “We’re here to help.” The customer must select Message us to enter the conversation.


Limit: This is an extra entry screen before the topic menu. The panel can be minimized without leaving the current web page.


Customer question (hypothesis): Why must I open chat twice?


**Keep:** The welcome panel clearly provides a Message us action.


**Improve:** The extra welcome screen delays reaching a useful prompt after the visitor has already opened Fern.


**Proposed:** Test opening directly to a compact task menu and text field, with assistant identity and scope in a short header.


**Validate:** Compare time to first useful response; verify panel focus and close behavior.


**Measure:** Time to first question and abandonment before first input.


References: [Nielsen Norman Group · usability heuristics](https://www.nngroup.com/articles/ten-usability-heuristics/)


### 19. Greeting and topic menu — P2


Evidence: Fern introduces itself as a virtual assistant, presents Utilities Disputes and Billy information, then offers billing, electricity, gas, broadband and Help/Other topics.


Limit: Users can select a topic or type a message. The conversation scrolls inside the panel; the screenshot shows the final menu. An attachment control is also visible.


Customer question (hypothesis): Which topic describes my issue?


**Keep:** Customers can use topic buttons or free text. Fern identifies itself as a virtual assistant.


**Improve:** Multiple introductory messages precede the menu. The Home-anytime promise creates an expectation the tested feedback state fails to meet.


**Proposed:** Lead with tasks such as Compare prices, Understand a bill and Moving home. Keep necessary disclosures available without burying the task menu.


**Validate:** Test task wording and whether new messages are announced without moving keyboard focus unexpectedly.


**Measure:** Correct topic selection and time to useful answer.


References: [Electric Kiwi · Kiwi Central](https://www.electrickiwi.co.nz/mobile-app), [W3C WAI · accessible forms](https://www.w3.org/WAI/tutorials/forms/), [Nielsen Norman Group · usability heuristics](https://www.nngroup.com/articles/ten-usability-heuristics/)


### 20. Clarify the joining query — P1


Evidence: For “How do I join Pulse Energy?”, Fern asks the user to type a number: Joining Pulse Energy, Offer to join Pulse Energy, or None of these.


Limit: The clarification choices appear as text in a message rather than the topic buttons used by the main menu. The test continued by entering 1.


Customer question (hypothesis): Why do I need to type a number for a simple question?


**Keep:** Clarification gives Fern a way to avoid answering the wrong joining topic.


**Improve:** The clarification switches from buttons to numbered text, adding recall and a new interaction convention.


**Proposed:** Answer clear joining intent directly; when uncertain, offer short tappable choices and an escape route.


**Validate:** Run paraphrase tests, including spelling errors; evaluate intent resolution rather than message count alone.


**Measure:** Correct first answer and unnecessary clarification rate.


References: [Nielsen Norman Group · usability heuristics](https://www.nngroup.com/articles/ten-usability-heuristics/)


### 21. Link to online sign-up — P2


Evidence: After selecting Joining Pulse Energy, Fern links to signup.pulseenergy.co.nz and asks whether the answer helped, with Yes and No buttons.


Limit: This answer routes the visitor into the separate sign-up flow shown in journey B. No address, quote or enrolment is handled within this observed chat answer.


Customer question (hypothesis): Will I have to restart on another site?


**Keep:** Fern provides the correct sign-up destination and a way to indicate whether it helped.


**Improve:** The generic link moves the customer into a separate flow and the Yes/No prompt asks about usefulness before task completion.


**Proposed:** Use a descriptive Check prices for my home link, explain the next step and retain safe task context. Make feedback optional.


**Validate:** Check continuity and referral state across domains; do not pass private data in URLs.


**Measure:** Chat-to-price completion and repeated information.


References: [Nielsen Norman Group · usability heuristics](https://www.nngroup.com/articles/ten-usability-heuristics/)


### 22. Home rejected during feedback — P1


Evidence: Although the menu says Home works at any time, typing Home at the Yes/No prompt is rejected. Fern repeats that the user must answer Yes or No.


Limit: After selecting Yes, typing Home successfully returned to the topics. This limitation was observed at the answer-feedback step; it is not a claim about every chat state.


Customer question (hypothesis): Why does Home not work when you said it always would?


**Keep:** A Yes response followed by Home did restore the menu in the observed conversation.


**Improve:** Home is rejected at the feedback prompt. This is a directly observed navigation inconsistency, not a hypothetical chatbot risk.


**Proposed:** Handle Home, Back, Cancel and human-help intent before the feedback state. Accept the next question without requiring a rating.


**Validate:** Regression-test escape commands from every conversational state, including errors and handoffs.


**Measure:** Navigation dead ends and successful task continuation.


References: [Nielsen Norman Group · usability heuristics](https://www.nngroup.com/articles/ten-usability-heuristics/)


### 23. Billing and payments menu — P2


Evidence: The billing branch offers overdue accounts, payment options, account balance, refunds, updating details, My Account and other billing queries.


Limit: The customer can choose a specific task without first supplying an account number. The account-balance option was selected for this walkthrough.


Customer question (hypothesis): Can I get straight to the billing task?


**Keep:** The menu recognises concrete tasks such as balances, refunds and updating details without demanding an account number first.


**Improve:** A broad menu still requires users to classify their problem; the tested balance path supplies guidance, not an account balance.


**Proposed:** Keep common tasks visible and state when secure sign-in is needed. Retain free-text input and a clear human route.


**Validate:** Test mixed intents such as a paid bill still showing as due.


**Measure:** Correct routing and repeat explanations after login or transfer.


References: [Electric Kiwi · Kiwi Central](https://www.electrickiwi.co.nz/mobile-app), [Meridian · account and moving help](https://www.meridianenergy.co.nz/help/for-home), [Nielsen Norman Group · usability heuristics](https://www.nngroup.com/articles/ten-usability-heuristics/)


### 24. Account link and further help — P1


Evidence: Fern directs the customer to My Account to view their balance and says payments can take up to 48 hours to appear. It then offers Previous menu, Home, Speak to our team and Provide feedback.


Limit: The screenshot shows the end of the response and all follow-up buttons. No account data was requested in this branch. Live-agent transfer, attachments and feedback submission were not tested.


Customer question (hypothesis): Can I reach a person without explaining everything again?


**Keep:** Fern links to My Account, states a payment-processing delay and offers team contact and navigation.


**Improve:** Agent availability, transfer success and context retention were not tested. A portal link alone may not resolve a disputed balance.


**Proposed:** Show available channels and realistic wait expectations. With customer agreement, carry a short conversation summary into a human handoff and confirm the next step.


**Validate:** Complete an authorised handoff and test unavailable-agent recovery; measure outcome rather than containment alone.


**Measure:** Resolved tasks, repeated-contact rate and handoff completion.


References: [Electric Kiwi · Kiwi Central](https://www.electrickiwi.co.nz/mobile-app), [Nielsen Norman Group · usability heuristics](https://www.nngroup.com/articles/ten-usability-heuristics/)


## Competitor benchmarks


### Mercury — New Zealand

App features; web usage route documented

Daily, weekly and monthly usage includes fixed charges, variable charges and GST. Manual-paying customers can set up SmoothPay in the app.

Conditions: Hourly costs exclude fixed charges. Legacy or non-communicating meters have reduced detail. Customers on direct debit or with less than three months’ tenure are directed to chat for SmoothPay.

For Pulse: Show calculation scope beside costs and eligibility before a payment-plan form. Do not promise universal self-service.

[Mercury · usage and cost breakdown](https://www.mercury.co.nz/electricity/usage), [Mercury · SmoothPay eligibility and setup](https://www.mercury.co.nz/help-and-support/billing-and-payments/smoothpay)


### Electric Kiwi — New Zealand

Kiwi Central mobile app; public product page

The app documents balances, service tabs, usage insights, Hour of Power savings, broadband speed testing, notifications and in-app support.

Conditions: These are documented app capabilities. Logged-in behavior and desktop parity were not tested.

For Pulse: Unify services around customer tasks and attach useful next actions to usage. Do not import a competitor’s tariff mechanic without validating Pulse’s offer.

[Electric Kiwi · Kiwi Central](https://www.electrickiwi.co.nz/mobile-app)


### Meridian — New Zealand

Online account and public help

Its public plan table compares term, household fit and offer conditions before a property-specific quote. Its help describes online contact updates, payment-method setup and eligible payment-date changes, alongside an online move form.

Conditions: The public table is not a personalised price quote. Payment-date changes have payment-method and timing conditions. Some cases still require contact; a public form alone is not evidence of a fully tracked move.

For Pulse: Give simple tasks a direct route and show the exception path upfront.

[Meridian · public plan comparison](https://www.meridianenergy.co.nz/for-home/pricing-rates), [Meridian · account and moving help](https://www.meridianenergy.co.nz/help/for-home)


### Octopus Energy — United Kingdom

App usage guidance; web forecast documented

Usage charts offer currency and kWh, with cost exclusions stated. A separate web Balance Forecast models future account balance.

Conditions: The cited currency view excludes VAT and standing charges. Forecast access depends on tariff and direct-debit eligibility. App detail exceeds some online views.

For Pulse: Provide transparent cost scope. Distinguish a forecast balance from the next bill and from money currently due.

[Octopus UK · usage in money and units](https://octopus.energy/blog/track-my-energy-use/), [Octopus UK · Balance Forecast](https://octopus.energy/help-and-faqs/articles/what-is-the-balance-forecast/)


### AGL — Australia

My Account web and email; app usage

Customers can follow connection progress and an estimated date through My Account or a confirmation-email link. Usage guidance explains bill projections.

Conditions: Projection availability and inputs vary by meter and customer history. Australian connection instructions are not operating guidance for New Zealand.

For Pulse: Create a persistent status page and explain what remains provisional. Tie estimates to visible assumptions.

[AGL · track a new connection](https://www.agl.com.au/help-support/moving-meters-connections/track-new-connection), [AGL · usage and projection calculations](https://www.agl.com.au/help-support/account-setup-management/energy-usage-calculations)


### PG&E — United States

Web preferences; email, SMS or voice alerts

Eligible customers set a dollar threshold and receive a Bill Forecast Alert when expected spending exceeds it, rather than every month regardless.

Conditions: Eligibility excludes some customer types. The forecast is an estimate and omits specified costs; it does not model weather.

For Pulse: Test opt-in budget alerts after data reliability is established. Show exclusions and let customers choose channel and threshold.

[PG&E · Bill Forecast Alert](https://www.pge.com/en/account/manage-my-account/online-account-preferences/bill-forecast-alert.html)


### Contact — New Zealand

Public desktop account help and published app preview

The account help page exposes named tasks and expands answers in place.

Conditions: No authenticated account inspected. Energy/broadband and mobile have separate apps.

For Pulse: Use consistent task language across help and My Account.

[Contact · energy and mobile app previews](https://contact.co.nz/support/guides/our-apps), [Contact · task-based account help](https://contact.co.nz/support/my-account)


### Genesis — New Zealand

Simplified public Energy IQ demo viewed on desktop

Sample household setup leads to usage and estimated-bill examples; Monthly to Daily navigation was inspected.

Conditions: Simplified mobile-shaped demo with inconsistent sample dates; not production evidence.

For Pulse: Use sample data to explain account value, and distinguish accrued costs from estimates.

[Genesis · public Energy IQ demo](https://demo.genesisenergy.co.nz/), [Genesis · monthly usage demo](https://demo.genesisenergy.co.nz/forecast), [Genesis · daily usage demo](https://demo.genesisenergy.co.nz/forecast/daily)


## Proposed ideal journey


### 01. Find the right route

A new visitor sees Check prices, Move home and Existing customer sign-in. An existing customer sees familiar account tasks.

Service rule: One intent follows the customer through website, quote, account and help.

Acceptance: Task labels are understood without explanation; switching routes keeps useful context.

[Nielsen Norman Group · usability heuristics](https://www.nngroup.com/articles/ten-usability-heuristics/), [Meridian · account and moving help](https://www.meridianenergy.co.nz/help/for-home)


### 02. Understand the offer

Confirm the property, then see a comparable estimate and ongoing rates before optional sales follow-up, where feasible.

Service rule: State usage assumptions, daily charges, GST, offer duration, contract and applicable exit conditions. Explain any required data.

Acceptance: The customer can explain the ongoing cost and edit an assumption; no invented exact price is shown.

[GOV.UK · question pages](https://design-system.service.gov.uk/patterns/question-pages/), [GOV.UK · check answers](https://design-system.service.gov.uk/patterns/check-answers/)


### 03. Join with confidence

Provide necessary details in short groups, choose services, review answers and submit once.

Service rule: Show why details are required, save progress safely and separate optional preferences from essential service information.

Acceptance: Back retains answers; errors are actionable; review edits return to the review page.

[GOV.UK · question pages](https://design-system.service.gov.uk/patterns/question-pages/), [GOV.UK · check answers](https://design-system.service.gov.uk/patterns/check-answers/), [W3C WAI · accessible forms](https://www.w3.org/WAI/tutorials/forms/)


### 04. Know what happens next

Receive a reference, status link, requested/confirmed dates, next actions and account-access guidance.

Service rule: A pending application is not presented as an active supply. Delays and exceptions have a clear owner and next update.

Acceptance: Customers distinguish received, in progress and confirmed; status is available outside email alone.

[AGL · track a new connection](https://www.agl.com.au/help-support/moving-meters-connections/track-new-connection), [Nielsen Norman Group · usability heuristics](https://www.nngroup.com/articles/ten-usability-heuristics/)


### 05. Understand the account

One headline says what is due and when. Pending payments and credits are dated; service and property context is clear.

Service rule: A zero balance has an appropriate next action. Bills show period, amount and actual reconciled status.

Acceptance: Customers identify amount, date and action; totals reconcile with the source bill.

[Meridian · account and moving help](https://www.meridianenergy.co.nz/help/for-home), [Octopus UK · usage in money and units](https://octopus.energy/blog/track-my-energy-use/), [Nielsen Norman Group · usability heuristics](https://www.nngroup.com/articles/ten-usability-heuristics/)


### 06. Control costs and changes

Inspect cost and usage with a named period, compare like-for-like, manage eligible payment options and move home with saved details.

Service rule: Missing, estimated, stale and zero data are distinct. Forecasts are labelled and optional alerts explain their scope.

Acceptance: The customer understands the displayed cost and can complete an eligible change without repeating known information.

[Mercury · usage and cost breakdown](https://www.mercury.co.nz/electricity/usage), [Mercury · SmoothPay eligibility and setup](https://www.mercury.co.nz/help-and-support/billing-and-payments/smoothpay), [AGL · usage and projection calculations](https://www.agl.com.au/help-support/account-setup-management/energy-usage-calculations), [PG&E · Bill Forecast Alert](https://www.pge.com/en/account/manage-my-account/online-account-preferences/bill-forecast-alert.html)


### 07. Get help without a dead end

Fern answers routine questions, honours navigation commands and makes human assistance easy to find.

Service rule: Sensitive account actions move through secure authentication. Feedback never blocks the next task; transfers carry agreed context.

Acceptance: The user can exit, change topic or reach an available channel from every state. Handoff resolution is measured.

[Electric Kiwi · Kiwi Central](https://www.electrickiwi.co.nz/mobile-app), [W3C · accessible authentication](https://www.w3.org/WAI/WCAG22/Understanding/accessible-authentication-minimum.html), [Nielsen Norman Group · usability heuristics](https://www.nngroup.com/articles/ten-usability-heuristics/)


## Priorities — provisional estimates


### 1. Remove Fern navigation dead ends (P1, S)

Screens: 22, 20–24. Owner: Chat owner + service team. Dependency: State-machine ownership and approved support routing.

Measure: Escape-command failures; handoff success. Guardrail: No fall in answer accuracy or loss of context.


### 2. Clarify the account balance and current action (P1, S–M)

Screens: A1. Owner: Portal product + billing. Dependency: Revalidate the UAT issue in production; reliable balance states.

Measure: Amount/date/action comprehension. Guardrail: No misleading pending-payment or credit state.


### 3. Test earlier price visibility (P1, M–L)

Screens: 04, 08–09. Owner: Acquisition + pricing + privacy. Dependency: Confirm minimal pricing inputs and follow-up requirements.

Measure: Address-to-price and price-to-completed-sign-up rates. Guardrail: Quote accuracy, service eligibility and unwanted-contact complaints.


### 4. Fix measured accessibility blockers (P1, M)

Screens: All; especially forms and A1–A4. Owner: Design system + engineering. Dependency: Live DOM, keyboard, zoom and assistive-technology audit.

Measure: Task completion using keyboard and screen reader. Guardrail: No blanket compliance claim from screenshots.


### 5. Make bills and usage tell a consistent story (P1, M–L)

Screens: A2–A4. Owner: Billing + data + portal. Dependency: Statement metadata, reconciliation and freshness signals.

Measure: Bill retrieval and cost interpretation. Guardrail: Status accuracy and no false-zero displays.


### 6. Simplify moving and expose progress (P1, L)

Screens: 14–16. Owner: Service operations + portal. Dependency: Confirm existing authenticated route; connection status integration.

Measure: Completed requests and status-related contacts. Guardrail: No missed dates, access or medically dependent support needs.


### 7. Align task labels and reduce unsolicited interruption (P2, S–M)

Screens: 01–03, 10, 17–19. Owner: Website + content. Dependency: First-click study and callback operations.

Measure: Task-find success and time to useful answer. Guardrail: Assisted help remains easy to discover.


### 8. Improve activation and recovery (P2, M)

Screens: 11–13. Owner: Identity + support. Dependency: Observe verification and expired-link journeys.

Measure: Activation/reset completion. Guardrail: Privacy-preserving errors and accessible authentication.


### 9. Explore forecasts and opt-in budget alerts (P3, L)

Screens: A3–A4; unobserved capability. Owner: Data + service product. Dependency: Reliable meter data, rates, eligibility and explicit opt-in.

Measure: Forecast calibration and useful-alert ratings. Guardrail: False alarms, alert fatigue and unsupported precision.


## Evidence limits
24 live captures from 12 September and 4 supplied UAT captures from 8 August. Competitor evidence is public first-party documentation, not logged-in testing. Customer reactions and proposed improvements are hypotheses. Accessibility, downstream quote states, completed moves, verification, recovery and agent transfer require live testing. No analytics baseline or customer interviews were available.

## Expanded visual benchmark library

17 fresh public-source captures across 8 providers, 12 September 2026. App previews and the public Genesis demo are labelled; no competitor authenticated account was inspected.

### Compare before committing

A useful comparison can begin before a sales conversation.

Pulse evidence: Pulse carries the property forward and names the sign-up stages, but the observed price route stops at required contact fields. Prices beyond that gate were not inspected.

Adapt: Show household fit, term, recurring charges and offer expiry in consistent rows. Then request only the inputs needed for an accurate property price.

Tradeoff: Do not make promotional credits or export buy-back rates look like the cost of imported electricity. Do not claim an address-only quote is feasible until pricing inputs are confirmed.

Test: Ask prospects to choose a plan and explain first-year versus ongoing cost. Measure correct understanding and address-to-price completion.

### Explain the money, then offer an action

The most useful balance is a sentence, not just a number.

Pulse evidence: The supplied Pulse UAT dashboard brings several services together. Competing money figures need production revalidation before any redesign decision.

Adapt: Give amount due, available credit, payment processing and next scheduled payment distinct labels. Show the effective date and one relevant primary action.

Tradeoff: Do not treat “in credit” as proof that no future payment is scheduled. Do not copy an illustrative competitor balance as a complete state model.

Test: Use four scenarios: credit, amount due, zero due and pending payment. Ask what is owed, when, and what action is needed.

### Turn usage into an answer

Customers need a period, a unit and an explanation—not a chart alone.

Pulse evidence: The supplied Pulse UAT electricity screen shows kWh and period controls. The audit flags data clarity issues; production behavior and available reads remain unverified.

Adapt: Show money and energy where calculations support them. State included charges, update time and missing reads; provide a table alternative.

Tradeoff: Do not compare unlike totals. Mercury and Octopus document different cost inclusions. Do not show missing data as zero or promise live data without the required meter feed.

Test: Ask users to find a high-use day and reconcile the view with a bill. Include keyboard-only use and a missing-data scenario.

### Make every service useful

An account becomes useful when information leads to a relevant task.

Pulse evidence: Pulse already places broadband alongside electricity in the supplied UAT account. That is a foundation to retain; the next question is what users can do from each service.

Adapt: Give broadband a clear route to connection help or troubleshooting, and electricity clear bill and usage tasks. Retain a coherent overview across services.

Tradeoff: Do not add decorative service tiles with no useful destination. A router speed test needs technical support; it is not just a frontend control.

Test: Start with “my internet is slow” and “why did electricity cost more?”. Watch where users go and whether support keeps the selected service context.

### Warn early, with customer control

Forecasts need a clear distinction between known cost and uncertainty.

Pulse evidence: The inspected Pulse states do not establish whether forecasts or alerts exist. This is a capability exploration, not a confirmed production gap.

Adapt: First separate accrued usage cost from amount due. If forecasts are reliable, show estimate assumptions and let customers choose a threshold and channel.

Tradeoff: Do not make a forecast look like a bill or an enforced budget cap. Do not copy PG&E’s eligibility rules or Genesis’s sample values into a NZ service design.

Test: Measure forecast error by customer segment, then test whether customers distinguish actual from estimated values. Include opt-out and stale-data behavior.

### Carry reassurance beyond the form

Submitting a move starts a service process; customers need to see what happens next.

Pulse evidence: Pulse’s public move form gathers property and service details. The confirmation, tracking and operational outcome were not submitted or inspected.

Adapt: Show received, awaiting information, scheduled and confirmed states where operationally valid. Give the customer one secure status link and the next required action.

Tradeoff: Do not label a submitted request as a completed connection. Do not transplant Australian safety or connection instructions into Pulse copy.

Test: Walk through delayed and changed-date cases with operations; test whether customers can find status again from an email and their account.

### Make help a route back to the task

Good assistance lets customers change direction and recover.

Pulse evidence: Fern offers topics and free text, but the captured Home command was rejected during feedback. A human transfer was not completed in the audit.

Adapt: Use shared task labels across help and account navigation. Make feedback optional; give Fern persistent restart, back and human-help routes with accurate availability.

Tradeoff: Do not infer that a competitor’s promised seamless handoff works in practice. Do not pass account details or chat history without a secure, appropriate context transfer.

Test: Test a wrong answer, topic change, feedback refusal and after-hours request. Measure confirmed resolution and successful recovery, not bot containment alone.

### Capture 01: Mercury — Show the account before asking for a download

Published app preview

![Show the account before asking for a download](benchmarks/deep/01-mercury-usage.png)

Strength: The preview connects balance, weekly cost and daily usage in one visual story.

Limit: These are app illustrations. Desktop parity and real account states were not tested.

Pulse: Show a realistic account preview beside the benefits of activating My Account.

Validate: Can a prospect identify the three tasks the account will help them complete?

[Mercury · usage and cost breakdown](https://www.mercury.co.nz/electricity/usage)

### Capture 02: Genesis — Switch between time scales

Interactive public demo

![Switch between time scales](benchmarks/deep/02-genesis-monthly-demo.png)

Strength: Monthly, Daily and Hourly controls stay together; clicking Daily changed the chart.

Limit: The monthly heading shows July 2026 while axis labels in the DOM refer to 2023. The chart extends below the demo viewport.

Pulse: Keep the time-scale control visible and every date consistent.

Validate: Test period changes, keyboard navigation and an accessible data table.

[Genesis · monthly usage demo](https://demo.genesisenergy.co.nz/forecast)

### Capture 03: Genesis — Make changes in usage explorable

Interactive public demo

![Make changes in usage explorable](benchmarks/deep/03-genesis-daily-demo.png)

Strength: The selected Daily state is visible and its chart differs from Monthly.

Limit: Sample values and dates are inconsistent; this is a simplified demo, not authenticated production.

Pulse: Use progressive detail, with explicit units and a clear date range.

Validate: Ask users to find a high-usage day, then explain what the bars represent.

[Genesis · daily usage demo](https://demo.genesisenergy.co.nz/forecast/daily)

### Capture 04: Meridian — Start with household fit

Public desktop page

![Start with household fit](benchmarks/deep/04-meridian-plan-cards.png)

Strength: Plan names and short use cases give customers a starting point for comparison.

Limit: Offers and solar buy-back rates are not a complete household price. Conditions apply.

Pulse: Explain who each plan suits before the property-specific quote.

Validate: Can prospects pick a plausible plan without mistaking a promotional credit for its price?

[Meridian · public plan comparison](https://www.meridianenergy.co.nz/for-home/pricing-rates)

### Capture 05: Meridian — Compare the same attributes side by side

Public desktop page

![Compare the same attributes side by side](benchmarks/deep/05-meridian-comparison.png)

Strength: Consistent rows align term, fit and offer across plans.

Limit: This is plan comparison, not a personalised quote; qualifications continue below the captured table.

Pulse: Give Pulse plans shared comparison rows and keep full cost assumptions close.

Validate: Test plan-fit decisions and total-cost comprehension separately.

[Meridian · public plan comparison](https://www.meridianenergy.co.nz/for-home/pricing-rates)

### Capture 06: Electric Kiwi — Separate overview, insights and account tasks

Published app preview

![Separate overview, insights and account tasks](benchmarks/deep/06-kiwi-account.png)

Strength: Three labelled previews distinguish service overview, usage and account administration.

Limit: Preview images do not prove task success or desktop availability.

Pulse: Keep a concise account home with direct routes to details.

Validate: Can customers predict where to find a bill versus a usage chart?

[Electric Kiwi · Kiwi Central](https://www.electrickiwi.co.nz/mobile-app)

### Capture 07: Electric Kiwi — Give each service a useful action

Published app preview

![Give each service a useful action](benchmarks/deep/07-kiwi-services.png)

Strength: Power, mobile and broadband examples pair information with relevant controls.

Limit: Plan and device conditions apply; actual actions were not executed.

Pulse: Pair Pulse broadband usage with a useful support action.

Validate: Test a slow-broadband task from the account home.

[Electric Kiwi · Kiwi Central](https://www.electrickiwi.co.nz/mobile-app)

### Capture 08: Electric Kiwi — Explain when AI hands over to a person

Public support guidance

![Explain when AI hands over to a person](benchmarks/deep/08-kiwi-ai-handoff.png)

Strength: Published guidance states human choice and wait-time expectations.

Limit: The promised transfer and account verification were not tested. Email alone must not be assumed to prove identity.

Pulse: Give Fern clear exits, hours and a confirmed transfer state.

Validate: Test topic changes, failed answers and after-hours handoff without sending private data.

[Electric Kiwi · AI and human support expectations](https://www.electrickiwi.co.nz/ai-assist)

### Capture 09: Contact — Make self-service benefits tangible

Published app preview

![Make self-service benefits tangible](benchmarks/deep/09-contact-app.png)

Strength: An app image sits beside practical billing, usage and moving tasks.

Limit: Energy/broadband and mobile use separate apps. This is not evidence of one unified account.

Pulse: Explain what the account covers, and where any separate service goes.

Validate: Can a customer find the right service without downloading the wrong app?

[Contact · energy and mobile app previews](https://contact.co.nz/support/guides/our-apps)

### Capture 10: Contact — Organise help around customer questions

Public desktop interaction

![Organise help around customer questions](benchmarks/deep/10-contact-task-help.png)

Strength: A question expands in place and gives a direct route to more specific instructions.

Limit: The disclosure opened, but its accessibility state remained labelled collapsed in the captured tree; semantic behavior needs checking.

Pulse: Use task language across Fern, help and My Account.

Validate: Test findability, expanded-state announcements and return to the original task.

[Contact · task-based account help](https://contact.co.nz/support/my-account)

### Capture 11: Octopus — Keep period, quantity and units together

Published app preview

![Keep period, quantity and units together](benchmarks/deep/11-octopus-usage.png)

Strength: Period tabs, totals and a money/energy switch sit with the chart.

Limit: The guide says money views exclude VAT and standing charges; live views need Home Mini. These controls were not operated in the app.

Pulse: Label Pulse chart scope and explain missing readings.

Validate: Test whether a customer confuses chart cost with the bill.

[Octopus UK · usage in money and units](https://octopus.energy/blog/track-my-energy-use/)

### Capture 12: Octopus — Explain a balance in plain language

Published app preview

![Explain a balance in plain language](benchmarks/deep/12-octopus-balance.png)

Strength: The balance example states that the account is in credit and shows the recurring payment.

Limit: A recurring payment is not the same as a bill due. This is one illustrative credit state.

Pulse: Pair each Pulse amount with its meaning, date and next action.

Validate: Test credit, arrears, zero due and pending payments.

[Octopus UK · usage in money and units](https://octopus.energy/blog/track-my-energy-use/)

### Capture 13: AGL — Make the move trackable after submission

Public support guidance

![Make the move trackable after submission](benchmarks/deep/13-agl-track-move.png)

Strength: The guide documents tracking through both the account and confirmation email, including an estimated date.

Limit: The tracker itself was not inspected. Australian connection instructions are not guidance for NZ.

Pulse: Give Pulse move requests a reference, status and return route.

Validate: Test delayed, incomplete and confirmed requests with operations.

[AGL · track a new connection](https://www.agl.com.au/help-support/moving-meters-connections/track-new-connection)

### Capture 14: AGL — Connect a bill with payment and assistance

Published app preview

![Connect a bill with payment and assistance](benchmarks/deep/14-agl-billing.png)

Strength: The app illustration groups a bill amount, payment help, direct debit and a breakdown.

Limit: Promotional imagery is not a completed payment or evidence of settlement timing.

Pulse: Keep bill explanation and payment help beside the next action.

Validate: Test a failed or pending payment as well as a successful one.

[AGL · app billing and usage previews](https://www.agl.com.au/residential/agl-app)

### Capture 15: PG&E — Let customers control bill alerts

Published setup illustration

![Let customers control bill alerts](benchmarks/deep/15-pge-alert.png)

Strength: The tutorial illustrates an alert switch with on/off text and a customisation link.

Limit: Eligibility is restricted; no setting was changed. Forecasts are estimates, not a spending cap.

Pulse: Offer opt-in thresholds only when Pulse forecast data is dependable.

Validate: Test opt-out, delayed data and whether alerts cause confusion or repeated contacts.

[PG&E · Bill Forecast Alert](https://www.pge.com/en/account/manage-my-account/online-account-preferences/bill-forecast-alert.html)

### Capture 16: Genesis — Let prospects try a sample household

Interactive public demo

![Let prospects try a sample household](benchmarks/deep/16-genesis-demo-entry.png)

Strength: Household tiles start a public demo without real account credentials.

Limit: The entry is a constrained demo, not a quote or verified household model.

Pulse: Use clearly fictional examples to explain My Account before activation.

Validate: Test whether users distinguish sample costs from their own estimate.

[Genesis · public Energy IQ demo](https://demo.genesisenergy.co.nz/)

### Capture 17: Genesis — Separate cost so far from a projected bill

Interactive public demo

![Separate cost so far from a projected bill](benchmarks/deep/17-genesis-demo-dashboard.png)

Strength: The demo puts accrued cost, an estimated bill and time remaining together.

Limit: The site labels sequences simplified. Sample dates, services and figures cannot establish production forecast accuracy.

Pulse: Separate actual, pending and estimated amounts in Pulse.

Validate: Check comprehension and forecast error before offering alerts.

[Genesis · public Energy IQ demo](https://demo.genesisenergy.co.nz/)