The same question every prospect asks us.

On every first call with a prospect, the first technical question is the same.

"Can it really read our drawings?"

The phrasing changes. Sometimes it's "can it read a STEP file?" or "what about hand-marked redlines?" or "what about the legacy drawings from before we standardized on SolidWorks?" The question underneath is identical. Can this thing actually do what you say it does?

The technical answer is yes, with caveats. The interesting question is what they're really asking.

The technical answer

Yes. STEP and STP for 3D models. PDFs for 2D drawings, both vector and scanned. Image files when that's what the customer sent. The drawings come in over email, sometimes embedded in the body, sometimes attached, sometimes as a link to a customer's portal. Forgepoint handles all of them.

The drawing parse extracts the data points that matter for quoting. Part number if there's one. Material and grade. Dimensions, tolerances, thread callouts. Surface finish notes. Coating and plating requirements. Inspection callouts. For 3D models, the parse also computes geometry, envelope, surface area, finished weight, and identifies machined features. The extraction takes seconds for a clean drawing, longer for a messy scan.

The output goes into a structured record that downstream pricing logic operates on. The estimator sees the parsed data, can correct any field that looks wrong, and can ask the system to re-parse if the customer sent a revised drawing.

Where it works well

Clean PDFs. Standard CAD outputs from any major package. STEP files with proper geometry. Customer drawings that follow common practice for callouts and dimensions. That's most of what most shops see, most days. The hit rate on clean drawings is high enough that the estimator is reviewing, not building from scratch.

Repeat customers help. When a buyer at a customer sends drawings consistently formatted the same way, with the same conventions, the parse gets faster and more accurate over time. The customer history is part of it.

The boring stuff also helps. Quote requests that come in as line items in an email body with no drawing attached, just specs. Forgepoint handles those too. Same structured output, different input path.

Where it falls apart

Hand-drawn sketches scanned on a 2009 copier with coffee stains and ambiguous callouts. The system does its best. The hit rate is materially lower. Plan for that. If 20% of your inbound RFQs are hand-drawn, you're going to spend more estimator time on those than on the typed ones. The trade-off is still favorable, but it isn't free.

Drawings with non-standard symbology. Some shops have customers who use legacy industry conventions that aren't in any of the standard CAD packages. The system can learn these with shop-specific training, but the first few weeks are bumpy.

Highly complex assemblies. Multi-part assemblies with twenty subcomponents, each with their own drawings, each cross-referenced through assembly diagrams. The parse handles the parts. The assembly logic still needs an estimator to confirm the right components are pulled together. The system flags this, but the human is still in the loop.

Drawings with errors. When the customer's drawing is internally inconsistent, like a dimension that contradicts the bill of materials, the system doesn't guess. It flags the inconsistency and drafts a clarification email to the customer asking which is right. That's the right behavior for a quoting tool. A wrong assumption locked into a quote is more expensive than a one-day delay to confirm specs.

The deeper question

The technical answer covers the explicit question. There's a different question being asked underneath.

When someone says "can it really read our drawings?" they're often asking a version of "can I trust this thing with my customer relationships?"

Quoting isn't just data processing. The quote is the artifact that goes to the customer. It carries the company's reputation. If the quote is wrong, the customer notices. If the quote is professional but slightly off the customer's expected format, the customer notices. If the quote takes too long, the customer notices.

Operators who've been burned by software that promised more than it delivered are appropriately skeptical. The question "can it really read our drawings?" is shorthand for "if I put this in front of my customers, am I going to regret it?"

The honest answer involves two things.

The first is technical. The drawing parse handles the inputs your shop sees most often. Accuracy is high on clean drawings, lower on messy ones, and the system surfaces uncertainty rather than burying it. You can see what it thinks the spec is, and you can correct it before the quote goes out.

The second is structural. Every quote the system drafts goes through a human approval step before it reaches a customer. Always. No exceptions. The human reviewing the quote sees the parsed inputs, the pricing logic that was applied, the customer history that influenced the recommendation, and the final quote. If anything looks off, the human catches it before the customer ever sees it.

That structure is the answer to the trust question. The risk that a buyer is actually worried about, sending a wrong quote to a customer, doesn't exist in a workflow with a human approval step. The risk that does exist is that the system misses something subtle and the human, reviewing 30 quotes a day, doesn't catch the miss either. Worth talking about. But it's a different risk than the one most prospects are picturing.

What the call usually looks like 20 minutes later

By the time we've walked through the drawing parse with a shop, the conversation has usually shifted. The question stops being "can it read drawings?" and starts being "how does the human review actually work?" That's the right question. The drawing parse is a starting point. The human-in-the-loop design is the part that determines whether this thing fits into a real shop's actual workflow.

The drawings work. The hard part of the implementation is everywhere else.