Important limitations

Give unsupported requests a useful human handoff

Last materially reviewed 2026-09-23

Quick answerAn honest manual-review path is better than a precise estimate for work the model cannot understand.
Likely to work well when

✓ Small service teams with bounded estimate models

✓ Readers checking formula and saved-result behavior

✓ Operators comparing a paid calculator with free alternatives

Important limitations

— Binding or regulated pricing advice

— Enterprise CPQ and private live-price guarantees

— Generic surveys or a free contact form with no calculation need

What to know

Recognize the model’s limits early

Some requests should not receive an automatic numerical estimate. Examples include quantities outside the supported range, a service type not covered by the model or a condition that needs inspection. These are not necessarily bad leads. They are cases where the available answers do not support the promised precision. Identify the boundary before collecting a long set of irrelevant details, and tell the visitor that the request needs a reviewed quotation rather than implying the software rejected them personally.

What to know

Avoid a fake default price

A fallback value can be useful in software, but using zero or the cheapest rate for an unknown service creates a misleading commercial result. Likewise, a very high placeholder price can appear like a genuine offer. Prefer an explicit unavailable-estimate state with a clear next step. Keep the visitor’s relevant answers in the request summary, label the unresolved issue and avoid substituting a number solely because the result template expects one to exist.

What to know

Design the workaround as a real task

Name what the next person needs to review: a measurement, a service category or an unusual condition. If contact information is necessary for that response, explain why and request only what is needed. The notification guide distinguishes submission events and recipient settings; it does not prove that your team is monitoring the inbox. Establish a realistic ownership process and do not promise a response time that nobody has agreed to meet.

What to know

Verify the exception before launch

Use a harmless unsupported example and follow it through the whole path. The visitor should understand that no automatic quote was produced, and the recipient should see the unresolved requirement. Check that a missing notification does not lead staff to create a duplicate request blindly. A useful exception path preserves identity and context while keeping the uncertainty visible. If no safe human handoff exists, narrow the public calculator promise until it matches what the team can actually support.

Source boundary

Where the safety evidence stops

This guide draws on Input validation options, Submission notifications, Using calculators. Merchant-controlled records describe the provider’s own capabilities, terms or standards; they do not independently validate those claims. These records do not establish independent confirmation of the product claims.

Verify any current price, plan limit, label direction, compatibility rule, or commercial term that would materially change the decision. The dated source ledger shows the underlying records so this conclusion can be checked and updated.

Sources used for this page

These records support the facts and comparisons above. Merchant-controlled records are labelled so you can separate product claims from independent evidence.

  1. Input validation options — Merchant documentation · help.involve.me · Merchant-controlled · checked 2026-09-23
  2. Submission notifications — Merchant documentation · help.involve.me · Merchant-controlled · checked 2026-09-23
  3. Using calculators — Merchant documentation · help.involve.me · Merchant-controlled · checked 2026-09-23