Four custom coded forms your agents run on the appointment. They are not
CRM surveys, and the difference is not cosmetic.
Add as many as the case needs
A real household has five children, three existing policies and six beneficiaries.
CRM surveys cannot repeat a field group, so they ship two hardcoded slots and a
free-text box. These add a row when you need a row.
It writes the whole record
One submit creates the contact, the tags, the opportunity, the follow-up task and a
full note. Repeating groups become real linked records: each policy and each
beneficiary is its own object, associated to the client.
It PDFs the form
At the end your agent downloads the completed form as a PDF, every answer on it. A
second PDF files itself on the contact in the CRM as the record that the form was
completed, and when.
Versioned, not hand-clicked
Every CRM survey is built by hand, per account, and cannot be created by API. These
are code. They deploy in one command and every change is diffable.
Agent facing, deliberately. These are not public lead forms. They are the tool
your producer drives on the appointment, they carry a not-for-public-distribution notice,
and answers stay on the device until submit.
And the two PDFs are not the same document, on purpose. The one your agent
downloads holds every answer. The one filed in the CRM holds none of them: who, which
form, when, and the consent wording with its timestamp. A CRM file attachment sits at a
public link, and these forms collect social security and bank details, so the copy that
lives at a link is the copy that says nothing. The answers stay on the contact record,
behind your login.
