Let a buyer who is not an engineer ask your services site in plain language
IT services sites — implementation, custom systems, managed support, cloud work, security retainers — are written in layers. The buyer is often a general manager trying to learn whether you can work with the system they already run, how long a rollout takes, and whether a smaller company is in scope.
WebsiteChat answers from the public service pages and from text-selectable PDFs on eligible plans. It does not inspect the customer’s environment, and it does not invent an SLA or a specification you never published.
Buyers who are not engineers still have to read a deep services site
This is the services firm, not a self-serve product. A SaaS pricing page answers a different question than a project site.
Compatibility is described in product names, not in the buyer’s words
They ask “can this talk to what we already use?” The site answers with a platform list. The chat can connect those only when both sides are written down.
Rollout time is a range with conditions
“About three months after discovery” is not “three months from today.” Dropping the condition is how proposals get misquoted.
Support hours and an SLA are not the same sentence
A business-hours help desk is not a 99.9% commitment. If the SLA is absent, the assistant must not create one.
Scope for smaller companies is easy to oversell
A page aimed at mid-market projects should not be stretched into “yes, any size” because the visitor hopes so.
Questions a non-technical buyer actually types
The value is finding the published answer without learning your sitemap.
- Can you connect this to the system we already use?
- How long does a typical rollout take?
- Do you have an API?
- What time does support stop answering?
- Do you work with smaller companies?
- Is there an upfront fee?
- Which environments do you support?
- Can you help us move off our current setup?
Let them ask in plain language, from the pages you published
The assistant translates the buyer’s question onto your service, security, and support pages. It does not design the integration.
Crawl services, security, and support pages
Offerings, environments, API notes, onboarding steps, support hours, and the company sizes you say you serve.
Add a technical PDF you are willing to stand behind
Eligible plans can use a text-selectable overview or support description. Do not upload a draft SLA.
Map the question to a sentence you wrote
If the integrations page names a system, the reply can say so. “We can probably connect” is not a sentence you published.
Send a fit question to the inquiry you already use
A contact form or a consultation link is the handoff. The chat does not open a ticket in the customer’s IT tool or write a CRM record.
Compatibility, SLAs, and specs that are not written down
Silence on the site is not a yes.
- Do not promise a technical integration that the services pages do not describe
- Do not generate an SLA, an uptime figure, or a response time you did not publish
- Do not invent supported versions, regions, or security certifications
- Do not quote a project price or a fixed timeline that skips the conditions on the page
The shortlist moment before a sales call
Buyers are deciding whether a call is worth the time. The statement of work is still a human document.
A manager with one system name
They name the tool they run. The reply checks it against the integrations or environments page and, if it is absent, says a person needs to confirm.
A rollout question with a fiscal-year deadline
The published range is repeated with its conditions. The chat does not promise the deadline.
Support coverage for a small team
Hours and whether smaller organizations are in scope come from the support and services pages, separately from any SLA heading.
An API that may only be a paragraph
If you documented an API, the reply points to that page. If you did not, the answer is that it is not described, not a guessed endpoint.
Crawl the services site and test buyer questions
Include the pages a skeptical buyer opens: security, support, and how a project starts.
- 01
Create the services site
Use the company name on the proposal, not an internal practice code.
- 02
Crawl offerings and constraints
Services, environments, support hours, onboarding, and any API or migration pages.
- 03
Add a public technical PDF sparingly
Text-selectable, and only documents you want quoted to a prospect.
- 04
Greet non-technical buyers
Invite questions about fit, timing, and support. Say detailed compatibility is confirmed by the team.
- 05
Install it on service and contact pages
That is where shortlist questions happen.
- 06
Test an SLA question you did not publish
The reply should refuse to invent the number.
“Can this talk to what we already run?”
The sample matches a named system and refuses a made-up SLA.
We run Salesforce. Can you integrate, and what’s your uptime SLA?
The integrations page lists Salesforce among the systems the team has connected. It does not publish an uptime SLA. Support hours on the support page are weekdays until 18:00. A fit check for your environment goes through the inquiry form.
Talk to the team
IT services are not a productized SaaS page
Support hours and “what happens after go-live” are customer support questions on a services site.
Published constraints — hours, environments, fees you listed — are FAQ material buried in long pages.
Helping a buyer see whether a service is even in range is AI sales, stopping before a custom proposal.
A product with its own pricing and docs is closer to SaaS.
Install steps are in the guide.