What you will learn #
Use this chapter to make live chat available on a tracked website, prepare the people and settings that support it, reply to a visitor, and review how quickly the team responds. Hitsteps chat keeps available visitor and page context beside the conversation, so an operator can see what the visitor was doing when tracking permits it. For the public feature overview, see Website Live Chat.
Before you begin #
- You need a Hitsteps account, a website added to that account, and the Hitsteps tracking code installed on the pages where you want the chat widget. Chat cannot work on a page that does not load the site’s working tracker.
- The current public feature page says chat seats are included in paid plans and the Free plan includes none. Check current plans for the account’s actual allowance before inviting agents. The number of seats and plan-specific limits are not stated in this chapter.
- The account owner can manage chat availability, settings, agents, departments, and shortcuts. The dashboard source exposes the Agents section only to the account owner. Other account users may see only the conversations and actions allowed by their role and assigned chat access.
- A visitor can start a browser chat while an operator is available. A visitor may remain anonymous. Name or email is only known when the visitor provides it, and visitor journey fields depend on tracking, consent, browser conditions, and plan.
- To measure response time, chat must have been collecting the required conversation history and provenance. If the report says coverage is incomplete or unavailable, do not treat its numbers as a complete history.
Step by step #
A. Prepare chat before inviting a visitor
- Sign in as the account owner and select the website you want to support.
- Confirm that the Hitsteps tracker is installed on the visitor-facing pages. Use the separate installation guide if you need to install or repair it.
- Open Live Chat → Settings. Review the available chat settings, including whether the chat is enabled and whether the visitor is shown a form before starting. Choose settings that match your support process. Exact labels and options can vary with the current account interface.
- Open Live Chat → Agents. Add or enable the team members who should answer chats, and check that each person has the correct account access and an available chat seat. Do not share account credentials to work around seat limits.
- Open Live Chat → Departments if visitors should be routed to different teams. Create only the departments you can staff, then check the routing choices visible in the chat settings.
- Open Live Chat → Shortcuts. Add concise answers to common questions, such as where to find an order status page. Review every shortcut for accuracy before use. Shortcuts speed up replies; they do not send a message until an operator uses them in a conversation.
- Set the operator availability state or schedule shown in the dashboard. The dashboard has online, offline, and scheduled-offline states. Check the displayed state before relying on the widget to invite visitors to chat.
- Open a page on your own site in a private test browser and confirm that the chat entry point appears and can be opened. Do not send a message to a real customer as a test. If your account does not provide a safe test route, stop before submitting a visitor message.
B. Answer an incoming conversation
- Open Live Chat → Messages and select a conversation that your team is authorized to handle.
- Read the visitor’s message and the context shown beside it. Treat page history, source, device, and location as context that may be absent or incomplete, not as verified identity.
- If the conversation needs another team, use the available assignment or department controls. The conversation may show one or more assigned agents. Confirm the intended owner before handing it over.
- Type a reply in the message composer. Use a shortcut only after checking that its wording fits this visitor’s question. Avoid asking for passwords, payment card details, or unnecessary sensitive information in chat.
- Send the reply and confirm that it appears in the conversation. Continue the exchange there so the visitor can see the response in the website chat.
- When the conversation is resolved, use the close or completion control shown by the current interface. If a visitor replies and the conversation appears in the active queue again, review the new message and handle it using the same assignment and privacy checks.
C. Review response time
- Open Live Chat → Response time.
- Choose a week using the report’s week selector. The report uses the account timezone and accepts a complete Monday-to-Sunday week.
- Read the coverage notice first. Historical weeks before reliable capture began, or weeks with unknown conversation provenance, may be excluded or shown as unavailable.
- Compare the number of eligible visitor enquiries with replies before drawing conclusions. The report measures the first eligible manual operator reply, not every later exchange.
- Use the daily view, response-time distribution, and weekday/hour pattern to find periods that may need staffing. A blank or unknown period is not a zero-response period.
- Open a listed conversation only if you have access and a support reason to do so. The report is scoped to the selected site and may be restricted to conversations assigned to a delegated user.
D. Notifications and web push
The dashboard notification bell is a separate notification centre. It includes a badge, a searchable list, Mark all as read, Clear all, and a link to Notification settings. These are account dashboard notifications, not a promise that every visitor chat message will be delivered as a browser push notification.
Browser push is an operator notification channel, separate from the visitor chat widget and the dashboard bell. Its availability depends on your account and browser. Use the browser-push setup steps to check the actual control and permission state. A disabled or Unavailable control means this browser/account cannot subscribe through that screen. Enabling push does not guarantee delivery; browser and operating-system settings can block it.
Worked example #
Suppose a visitor on your-store.example/help/ asks, “Where can I find my order status?” The visitor may appear with the current page and other available journey context. If the visitor has not supplied a name or email, treat them as anonymous. An operator can select the conversation, use a previously reviewed shortcut that links to the store’s order-status page, and send the answer in the chat.
Expected result: the reply appears in that conversation and is available to the visitor in the site chat. A later response-time report may include the enquiry only if it is within the report’s supported coverage and meets its eligibility rules. This example is illustrative; it does not describe a real customer conversation or a measured result.
Controls and metrics #
| Control or metric | Meaning |
|---|---|
| Messages | The operator inbox for visitor conversations. Visibility and actions depend on account role and assignment. |
| Agent | A team member who can handle chat. The public feature page describes chat seats on paid plans; the account owner manages the agent list. |
| Department | A routing group for conversations. Available department choices depend on the site’s configuration. |
| Shortcut | Reusable text an operator can insert into a reply. Check it before sending. |
| Online / offline / scheduled offline | Operator availability states exposed in the dashboard. Scheduled offline means the dashboard indicates the schedule is currently controlling availability. |
| Visitor identity | Name or email the visitor supplies. Anonymous visitors are not identified by the feature. |
| Visitor context | Available page, journey, source, device, approximate location, or return signals. Exact fields depend on tracking, consent, browser conditions, and plan. |
| Eligible enquiry | A live visitor-originated chat enquiry with sufficient captured history and provenance for the report. Non-live, operator-initiated, or unknown/incomplete records are excluded from trustworthy calculations. |
| First response time | Elapsed time from the visitor’s first eligible enquiry to the first eligible manual operator reply. Automated, system, API, or otherwise unclassified messages are not treated as a manual reply by the report logic. |
| Median | The middle first-response duration in the selected cohort; for an even number of observations, the report uses the mean of the two middle values. |
| P90 | The nearest-rank 90th percentile of first-response durations. |
| Unanswered after 24 hours | A mature eligible enquiry with no eligible first manual reply by the 24-hour threshold. Newer enquiries remain pending rather than being counted as a failure. |
| Coverage | Indicates whether the report has enough known capture history to describe the selected period. Incomplete coverage prevents a reliable comparison. |
| Dashboard notification badge | Count of unread dashboard notifications currently loaded by the notification centre. It is distinct from chat availability and visitor push delivery. |
Problems and fixes #
- The chat entry point does not appear. Confirm the Hitsteps tracker loads on that page, the chat is enabled for the site, and the account has an available chat seat. Check that an extension, content blocker, consent choice, or site policy is not blocking the tracker.
- Visitors cannot start a conversation. Check the displayed operator state and schedule, the chat settings, and whether the team has an enabled agent. Test with a safe internal browser session and do not message a real customer as a diagnostic.
- The wrong team receives chats. Review the site’s departments and routing selections. Make sure each department has an agent who can actually respond.
- A delegated user cannot see Agents or a conversation. The Agents section is owner-only in the dashboard. Other visibility is role and assignment dependent. Ask the account owner to review access rather than sharing credentials.
- A visitor looks anonymous or has little context. This is expected when the visitor did not provide identity details or tracking is unavailable, restricted by consent, blocked, or outside the plan’s available fields. Do not infer a person’s identity from a device or approximate location.
- A shortcut is wrong or stale. Edit it under Live Chat → Shortcuts, then check the text before sending. A shortcut is reusable copy, not an automatic response.
- Response-time data is missing or marked unavailable. Check the report’s coverage message, selected week, and timezone. Unknown history, an unsupported or incomplete schema, or unavailable capture can prevent results. Do not substitute zeroes or compare incomplete weeks.
- Browser push does not arrive. If your account offers browser-push setup, check browser permission and the selected browser/device; do not assume the dashboard bell enables web push.
Access, privacy and limits #
- Chat messages and conversation context can contain personal information supplied by visitors. Limit access to staff who need it, avoid collecting sensitive information, and follow your own privacy notice and retention obligations.
- Hitsteps’ public feature page says journey context can include the current page, recent journey, source, device, approximate location, and return signals. It also says exact fields depend on tracking, consent, browser conditions, and plan. Treat those fields as optional context, not identity verification.
- Chat is listed on paid plans; the Free plan includes no chat seats on the current public feature page. Confirm current limits at the plan page before enabling chat for a team.
- The account owner manages agents. Delegated operators may have limited visibility. The response-time report applies site and assignment scoping and uses only eligible manual reply provenance.
- Use the current chat settings and account access messages for attachment, browser, retention and notification limits. A saved preference does not guarantee that an alert reaches a device.
- Do not include real visitor names, email addresses, message contents, or account identifiers in screenshots or public examples.
Last checked #
Checked 8 November 2026 using product documentation and source, with public pages and safe sample screens where available. Account-specific access, provider controls and effective limits can differ; use the current message shown for your website. Examples are illustrative.