Contact ASCAND Support with the context that matters

Contact ASCAND Support with the context that matters

Use this page when published guidance does not resolve a question about an ASCAND product, your configuration, 3D-Scan.Online access, an order or a technical problem.

A useful support request does not need to be long. It needs to identify what you were trying to do, which part of the workflow you reached, what you directly observed and which evidence you preserved.

Before contacting Support:

1. check current Documentation for configuration- or version-dependent instructions;
2. use Troubleshooting for an observable technical symptom; and
3. remove credentials, payment details and unrelated personal or project data from anything you intend to share.

You do not need to identify the cause. Describe the first observable difference between the expected and actual result.

Choose the route that owns your question

Choose the closest request type:

• Product or configuration: You need help identifying an ASCAND component, documented setup or appropriate starting configuration.
• Account or platform access: You cannot reach an expected account, project, upload, processing or download state.
• Technical support: A capture, reconstruction, merge, mesh, export or import result is reproducibly different from what you expected.
• Order or physical product: Your question concerns an order reference, delivery, supplied component or observable hardware condition.
• Privacy or scan data: You need verified information about personal data, project material, retention, deletion, access or rights.
• General, institutional, partnership or commercial enquiry: Use the separate general Contact page.

If several symptoms belong to one workflow failure, submit one request and state the earliest stage at which the problem appears. If the topics are unrelated—for example, an order question and a separate reconstruction fault—keep them as separate requests so each retains a clear evidence trail.

Product and configuration questions

For a product or setup question, explain the intended task before asking whether a component is suitable.

Include:

• the product or configuration you own or are considering;
• any visible model, revision or package identity;
• the object conditions relevant to the decision;
• the intended scan method or workflow, if known;
• the recording device or downstream tool only when relevant;
• the current document or product page you consulted; and
• the exact uncertainty you need resolved.

Do not infer compatibility from physical fit, a photograph or a similar product name. Do not assume that an optional extension changes every limit of the complete capture relationship.

If the question is primarily about object geometry, stability, visibility or surface response, begin with Object Suitability. If it concerns the differences between currently documented configurations, use Compare ASCAND Options.

Package contents, compatibility, availability, price and supported combinations are current operational facts. They must be verified against the applicable product record rather than reconstructed from historical material.

Account and 3D-Scan.Online access questions

Describe the platform state you can see without sharing anything used to authenticate you.

Provide, where available and safe:

• the affected workflow stage: sign-in, project selection, upload, submission, processing, review or download;
• the time and date of the observation, including your time zone;
• the exact visible message;
• a privacy-safe account or project reference exposed for support use;
• the browser, device or destination application when it is relevant;
• whether the same state remains reproducible; and
• the current documentation step you expected to follow.

Never send your password, authentication code, recovery secret, session data or full payment-card details. Support does not need your theory about the internal cause.

Keep sign-in problems separate from project-processing problems. A successful sign-in does not prove that a project was submitted, and a completed job does not prove that the expected representation was generated or transferred.

For a visible upload or processing symptom, begin with Submission and Processing diagnosis. If current interface behavior is unclear, consult Platform Documentation.

Build a technical support request from preserved evidence

Start with one sentence:

I was trying to [goal]. The first unexpected result appears at [workflow stage] and looks like [observable symptom].

Then add only the context needed to reproduce or understand that statement:

1. System: ASCAND product, visible revision and configuration.
2. Object: Stable identifying description and any relevant geometry or surface condition.
3. Method: Vision, Laser, Combo, Multi-Scan/Multi Merge or downstream operation.
4. Source lineage: Which capture, project and result belong together.
5. First failing stage: Capture, transfer, submission, processing, reconstruction, registration, mesh, export, download or import.
6. Observed result: Exact message, missing region, distortion, doubled surface, unexpected file behavior or other visible symptom.
7. Baseline: The original source and last known-good result.
8. Controlled test: One variable changed, what remained constant and what changed in the result.
9. Prior actions: Recapture, retry, conversion, repair or import already attempted.

Preserve the original capture, source project and first failing output. Do not overwrite them with a cleaned, repaired, transformed or re-exported derivative.

Screenshots should show the relevant region and enough context to identify the stage. Crop or redact unrelated names, projects and personal information. Send original files only when the verified support channel specifically requests them and you have permission to share their contents.

A plausible diagnosis can help organize a test, but label it as a suspicion. “The model is doubled after the second source is registered” is an observation. “The registration algorithm is broken” is a cause claim that the evidence may not yet support.

Orders and physical-product questions

For an order, delivery or physical-product question, include:

• the purchasing channel;
• the order reference;
• the product and visible component identity;
• the date or delivery stage relevant to the request;
• a concise description of the observable issue; and
• clear photographs of the product, label, packaging or affected area when relevant and safe.

Do not include full payment-card details or unrelated billing information in the free-text description.

Order history does not by itself determine warranty, return, replacement, shipping or availability outcomes. Those depend on the verified transaction, product, channel, condition and governing terms. Describe the request and allow the responsible route to establish what applies.

For a general pre-purchase, institutional, partnership or commercial question that is not a support case, use the general Contact page.

Share only what the request requires

Apply data minimization before submitting:

• remove passwords, authentication codes, keys and session information;
• remove full payment details;
• redact unrelated names, email addresses and project identifiers;
• do not share third-party objects, images or model files without permission;
• do not attach an entire archive when one message, screenshot or affected result is sufficient; and
• keep confidential institutional, student, visitor or customer information out of the request unless a verified process specifically requires and permits it.

Technical documentation explains how the system works. It does not define current privacy policy, access, storage, retention or deletion behavior.

For those questions, read Privacy and Scan Data and the governing privacy information before sharing source or result files. If your question concerns rights to scan, reproduce or distribute an object, resolve that permission separately; technical access does not create usage rights.

Submit one clear request and preserve its reference

The support form should collect:

• request type;
• name and reply address;
• concise subject;
• goal and observable issue;
• product, configuration and workflow stage;
• relevant order, account or project reference where appropriate;
• exact message and time of occurrence;
• troubleshooting already completed; and
• confirmation that sensitive and unrelated data has been removed.

Attachment controls should appear only when the supported file types, limits and handling are confirmed. The page must not ask users to upload scan sources or project archives by default.

Before submitting, review the description from the perspective of someone who has not seen the project. Can they identify the goal, system, first failing stage, observable symptom and preserved evidence?

Keep a copy of the submitted description and preserve any reference that the verified channel actually issues. Avoid sending duplicate requests for the same unchanged case. If material new evidence becomes available, connect it to the existing case where the channel permits.

Submitting a request does not by itself establish a diagnosis, warranty outcome, recovery result or response schedule. It creates a clear, privacy-conscious starting point for review.

Return to SupportUse this page when two or more independently reconstructed ASCAND scans should describe the same unchanged object, but Multi Merge does not produce a trustworthy shared result.