Outbound Objections
Use these answers when prospects reply to early outreach. Keep them short and concrete.
Safe Claims To Lead With
- embedded signing inside your app
- hosted signing links for external recipients
- reusable templates
- webhook callbacks
- completion certificate / audit trail
- signed PDF storage
- white-label / in-app UX
Claims To Avoid Leading With
- broad compliance promises
- advanced enterprise workflow claims
- perfect mobile claims
- strong identity verification claims
Identity verification is still a placeholder path in the current product, so do not pitch it as a finished capability.
Objection: "We already use DocuSign."
That makes sense. Aoexl fits best when you want the signing experience inside your own product instead of sending users out to a generic external workflow. The wedge is embedded signing plus hosted signing links for your own onboarding flow, not trying to replace every legacy document process on day one.
Objection: "Do you support mobile?"
Yes, and we should describe it carefully. Mobile signer flows are working, including next-field navigation, signature capture, and submit flow. The product has gone through significant compact/mobile polish, and we still keep real-device validation as part of the final rollout checklist before claiming "perfect mobile."
Objection: "How do webhooks work?"
Each server-backed signing request can trigger webhook delivery through the signing-complete path. The product already includes webhook delivery logging, HMAC signing support, and request lifecycle linkage so completion events can be consumed by your backend.
Related doc:
Objection: "Can this be white-labeled?"
Yes. The strongest version of the product today is the embedded/in-app flow, where the signer stays inside your UI and brand context. Hosted signing links also work when you need to involve external recipients.
Objection: "How fast is integration?"
Hosted signing requests are the fastest path because they let you generate a signing link and listen for completion events. If you want the experience fully inside your app, the SDK path is also viable and already validated in a real React host app.
Related docs:
Objection: "What happens after signing?"
After signing, the product can generate completion artifacts, store the signed PDF, and notify your backend through webhook callbacks. That gives you a practical operations story: send, complete, store, notify.
Objection: "Can you prove this is built for our workflow?"
Use the merchant-onboarding demo first. It is a better proof point than a generic editor because it shows one end-to-end business flow: template-like onboarding packet, signer completion path, and post-signing delivery story.