AI Perceptions at Work: How to Make Safer Automation Decisions

HubSpot’s reported findings suggest that AI became more recognizable and that more professionals reported using AI tools at work. They do not establish a controlled rise in adoption, prove that AI improved business results, or show that consumers actually replaced search engines with chatbots. The practical response is not to set a broad goal such as “use more AI.” It is to select one defined task and measure whether an assisted process performs acceptably.

HubSpot says its comparison draws on a 2017 survey of more than 1,400 consumers worldwide and a 2023 survey of more than 1,350 business professionals. Because the populations, questions, and contexts differ, treat the comparison as a source of pilot hypotheses rather than a comparable adoption trend.

For example, an operations owner could test whether AI-assisted categorization helps route eligible inquiries with less handling time and an acceptable correction rate. That question can be answered with task-level evidence even though the survey comparison cannot answer it.

What the AI perception shift actually tells businesses

The most defensible conclusion is that awareness and reported workplace use became more visible. In 2017, some respondents who said they had not used AI reportedly recognized voice search or assistants such as Siri when asked follow-up questions. By 2023, HubSpot reported use of named AI tools among several professional groups. Those are different kinds of evidence. Using an AI-enabled feature without recognizing it as AI is not the same measure as intentionally reporting use of a workplace tool.

That distinction matters when an organization interprets its own adoption data. A higher count of reported AI users might reflect more use, better recognition, or both. Perception findings can help identify a task worth testing, but the business decision should rely on the task outcome, not on the survey percentage.

A useful task definition might be “minutes to categorize one eligible inquiry” or “share of proposed categories that a reviewer corrects.” Those measures are specific enough to compare before and after a pilot.

Read the 2017 and 2023 numbers without treating them as a trend line

The table summarizes claims printed in HubSpot’s comparison article. The percentages are HubSpot-reported survey findings, not independently reproduced results.

Period and population	Reported signal	Safe interpretation
2017, more than 1,400 consumers worldwide	86% reportedly wanted to try AI tools; 57% were interested in real-time bot answers; 37% said they had used an AI tool. HubSpot also reported that 63% of apparent non-users later indicated use of voice search or assistants such as Siri.	Interest, self-reported use, and recognition are not equivalent to measured workplace adoption.
2023, more than 1,350 business professionals	HubSpot reported AI-tool use of 35% for marketers, 54% for bloggers, and 41% for business leaders.	These are distinct professional subgroups, not direct counterparts to the 2017 consumer sample or population-wide adoption rates.
2023, business professionals	80% agreed AI and automation could reduce time spent on manual tasks; 78% agreed they could create more time for critical work.	These are expectations, not measured time savings or productivity gains.
2023, professionals asked about future behavior	53% agreed with a forecast that most people would use chatbots instead of search engines by 2024.	This records an expectation in 2023, not observed behavior in 2024.

Use willingness or perceived usefulness to form a pilot hypothesis. For instance, interest in bot answers might justify testing a narrowly scoped inquiry-routing task. It does not show that a chatbot will improve service quality, reduce escalations, or resolve customer issues correctly.

The original 2017 research URL now redirects to a broader historical HubSpot story rather than a standalone chart or reproducible dataset. The comparison article also does not provide full sampling methodology, field dates, weighting, country breakdown, complete question wording, or subgroup base sizes. Preserve the stated population and question context whenever citing a percentage.

Choose a task before choosing an AI tool

Start with a repetitive task that has an observable input, a defined destination, a named owner, and a baseline. For CRM work, that could be categorizing an inquiry from its message and saving a proposed category to a review field. The operations owner should know which system is authoritative for the original message and which field, if any, the workflow may update.

Use deterministic rules for exact identifiers, known statuses, dates, amounts, and compliance conditions. Use AI when the input is unstructured and the job is bounded, such as summarizing text or proposing one category from an approved list. Keep legal, financial, employment, medical, and sensitive customer-escalation decisions behind an explicit human review gate.

A practical design test is:

• Input: What source data is eligible and how fresh must it be?
• AI task: What interpretation, extraction, summary, or classification is required?
• Typed output: What field type or allowlist can the process accept?
• Validation: What makes the result invalid, stale, contradictory, or unsafe?
• Action: Which owner-approved destination may be updated or routed?

If these questions cannot be answered, clarify the process before automating it. For organizations reviewing CRM ownership and workflow design, HubSpot systems work can include the surrounding operational design.

Two practical patterns for testing AI at work

The first pattern uses documented HubSpot workflow actions. HubSpot documents AI actions, including Data Agent actions, and testing an action on a specific record. Its Research action supports String, Number, or Boolean output. The precise action, access, credits, and options depend on the account’s configuration, permissions, subscription, feature rollout, and any beta status.

The second pattern is hypothetical and platform-neutral. It illustrates how to constrain AI-assisted service routing without presenting a verified HubSpot template or connector.

Trigger and input	AI responsibility	Validation and destination	Exception owner
Eligible HubSpot record has a description and stable record ID.	Use an available Data Agent action to propose a bounded classification or research result.	Test on a record; check type and allowed values before updating a compatible CRM property or routing onward.	CRM or operations owner reviews failed, stale, invalid, or sensitive results.
Hypothetical new service inquiry has a message, account tier, and received time.	For unresolved text, propose billing, technical_support, or account_access.	Rules resolve known conditions first. Check the category allowlist, source freshness, and review state before sending to an existing queue or review field.	Service operations owner handles unclear, sensitive, changed, or high-risk cases.

Documented HubSpot workflow pattern

1. Set enrollment criteria so the record has the required source properties. Keep the original source field and record ID available for review.
2. Add an available AI workflow action for a bounded research, extraction, or classification task. HubSpot’s workflow action documentation lists AI-related actions, subject to current account availability and requirements.
3. Test the action on a specific record and inspect its result, as described in HubSpot’s AI workflow instructions. Testing shows the action’s response and status. It does not establish that the result is factually correct.
4. Apply a separate validation gate before a later action writes or routes the value. For a category, check that it is on the allowed list. For any field, reject empty or stale input and avoid overwriting a populated value without an explicit precedence rule.
5. Send failed or rejected results to a named reviewer or exception queue. Leave the source field unchanged when the source changed during processing or the output does not satisfy the contract.

An illustrative record contract could contain the following fields:

{
  "source_record_id": "123456",
  "source_updated_at": "2026-10-14T09:30:00Z",
  "prompt_version": "industry-classification-v1",
  "input_hash": "illustrative-normalized-input-hash",
  "output_value": "Illustrative category",
  "output_type": "String",
  "validation_status": "pending_review",
  "ai_run_id": "illustrative-run-id",
  "writeback_status": "not_attempted"
}

This is a suggested implementation contract, not a HubSpot-published schema. The documented Research action supports String, Number, or Boolean output; do not promise arbitrary multi-field JSON from that action. Store the source record ID, source freshness, prompt version, result, validation state, and write-back status in the systems your design supports.

Hypothetical deterministic-first service routing

For an inquiry intake process, first use ordinary rules for exact cases: a known account tier, an explicit status, or a fixed form value. Send only unresolved message text to AI and ask for one category from a fixed list.

A proposed result could be:

{
  "category": "technical_support",
  "needs_human_review": true,
  "source_inquiry_id": "illustrative-inquiry-id"
}

Parse the output and reject a category outside the allowlist before routing. Check that the inquiry has not changed during processing and that no newer successful run has already been accepted. If the message is ambiguous, sensitive, or potentially high impact, create a review task or place it in an existing human queue. Keep the original message as the source of record, and have the service operations owner record whether the proposed category was accepted or corrected.

For broader ownership across CRM records and destinations, CRM systems design can help clarify which system owns each field and what should happen when a value changes.

Design validation, ownership, and duplicate prevention

Before write-back, decide which system owns each field, what counts as fresh source data, and who handles a rejected or failed result. A useful implementation contract can include a source record ID, source update timestamp, normalized input hash, AI run ID, prompt version, typed output, validation status, reviewer details where required, and write-back status. These are recommended design fields, not a vendor-published schema.

Keep data at the correct grain. One event row represents one source event. One run row represents one AI execution. One citation row represents one citation. One aggregate row represents a defined reporting period, entity, model or engine variant, and measure. Do not combine these into a generic result record.

For repeated enrichment, an idempotency key might combine source_record_id, input_hash, and prompt_version when the intended grain is one enrichment per record and content version. An event-level process should use its event identifier. An AI execution should have its own run identifier. A citation should be unique within its run, and a daily aggregate should include its entity, date, variant, and aggregation definition. A new source version or prompt must be distinguishable from a replay of the same work.

When external writers can run concurrently, a lookup followed by an insert can race. Use a database-enforced unique constraint on the selected key and a transactional upsert where available. HubSpot documents deduplication in specified CRM contexts and custom unique-value properties, but those behaviors are not a universal guarantee of race-safe integration writes.

If a webhook is involved, the receiving application is responsible for validating, persisting, and processing the event. Acknowledge promptly, enqueue enrichment asynchronously, and handle retries and rate limits in the receiving application. A webhook notification is an event, not proof that an AI run or write-back has completed.

Measure the pilot, not the promise

Choose a baseline for the same task and unit of work before rollout. Depending on the task, measure handling time, correction rate, review time, completion time, or appropriate routing rate. Keep AI activity counts, such as runs or records processed, separate from task outcomes. More runs do not by themselves show time saved or better customer service.

For customer-facing work, review service outcomes and escalation quality directly. Set the decision rule before the pilot: expand if the task outcome meets the agreed standard and error costs remain acceptable; revise if the process or validation needs work; keep the task human-led or stop if results do not justify the risk or effort.

What the survey comparison cannot answer

HubSpot’s comparison article does not disclose enough survey detail to support a controlled 2017 to 2023 adoption trend. It gives approximate sample descriptions, but not full sampling methodology, field dates, weighting, country breakdown, complete question wording, or subgroup base sizes. The original 2017 research URL now redirects to a broader historical story rather than a standalone chart or reproducible dataset.

The 2023 usage rates also lack enough disclosed context to treat them as overall labor-market adoption estimates. The article does not establish subgroup sample sizes, frequency of use, tool inclusion rules, or whether respondents could select multiple professional categories. The 80% and 78% figures describe agreement with expectations, not observed productivity. The 53% chatbot figure describes a forecast made in 2023, not behavior measured in 2024.

Survey attitudes and self-reported use provide context, not observed productivity gains, customer-experience improvements, or market-wide chatbot behavior. Use them to identify questions worth testing. Use task-level operational evidence, with a defined baseline and accountable owner, to decide whether an automation should continue.