Your AMS and back-office automation: what each one does
An agency management system (AMS) and a back-office automation tool are often confused. They do different jobs, and you need to know where one stops and the other starts before you buy either.
"Doesn't our AMS already do this?"
An agency principal hears about back-office automation and asks the obvious question: the agency already pays for an AMS with workflows, activities and a certificate module. Why would it need anything else?
The answer is in where the work starts. The AMS is excellent once someone has opened the right customer and started an activity. But every request starts as an email in a shared inbox, and the AMS does not read that inbox, decide what each email is, find the right customer, or notice that a certificate request from Thursday is still unanswered. That gap, between the inbox and the record, is where back-office automation works.
The AMS is the system of record
Your AMS holds customers, policies, documents and activity: the authoritative record. It is where policies are recorded, certificates and ID cards are produced from master data, carrier downloads land and the file is kept. Anything that replaces it is a migration project, not an automation project.
Back-office automation is the work around it
The work happens in the inbox before and after the AMS: finding the request, understanding it, getting it to the right person, drafting the output, getting an approval, replying and filing. That is the layer Shlix IBS covers. It does not try to replace your AMS; it reads from it, and writes back to it where a connection allows.
A request, followed through
- An email arrives asking for a certificate of insurance (COI).
- Automation recognizes it, matches the customer, and routes it with a due time.
- The record in the AMS supplies the producer, insurers, limits and dates.
- A person approves; the reply goes out in the same thread and the email is filed.
- The activity is recorded: in the AMS once a connection is in place, and always in the task's own history.
AMS workflows versus inbox automation
Many AMSs have workflow features: activity templates, suspense dates, task assignment. They are useful, and you should use them. They start once someone has created the activity. Inbox automation starts earlier, at the email, and its job is to make sure the activity exists, with the right customer, owner and due time, without a person reading every message first.
How the two connect
Ask for a written list of what a vendor can read and write in your specific AMS, today, and what is planned. For Shlix IBS: Microsoft 365 is connected today; AMS360 is in build; other systems are planned, and until a connection exists, the agency supplies the record.
- Read: customer, policy and master certificate data, so drafts come from the record.
- Write: activities and attachments, so the AMS file stays complete.
- Limits: what each AMS's integration allows varies, and some actions are only possible in the AMS's own screens.
Where each one keeps its records
The AMS keeps the policy record and the activity history that your E&O carrier, auditors and carriers expect to see. A back-office automation tool keeps its own record of the work: when the email arrived, what it was recognized as, who it was assigned to, what was drafted, who approved and when it was sent. The two records answer different questions. The AMS says what the policy is; the automation record says how a request was handled.
Make sure the automation record can be exported, and that the important outcomes, such as a certificate issued or an endorsement requested, are also logged in the AMS. If you ever stop using the automation tool, the AMS file should still be complete.
Security and access
Your AMS holds your whole book; any tool that connects to it should get only the access it needs. Ask whether the connection is read-only or read-write, which user account it runs as, whether access can be limited to certain customers or record types, and how it is switched off. The same goes for the mailbox: the automation should use the email provider's official interface, with permissions you grant and can revoke, rather than a shared password.
Choosing in the right order
If you are changing your AMS, do that first and let it settle. Automation built on a system you are about to leave has to be rebuilt. If your AMS is staying, automation can start with the inbox straight away, even before a deep integration exists: recognizing, routing and timing requests delivers value on its own, and drafting improves as the connection to the record gets deeper.
Ask your AMS vendor what it offers for inbox handling, too. Some offer email capture or attachment filing. Compare those with dedicated automation on the same questions above, and choose what covers your actual requests.
Questions to ask any vendor
- Does it write into my AMS, or only read? Which fields, and who checked?
- Who approves, and can the person who prepared the work approve it?
- What does it do when it is not sure: guess, or ask a person?
- Where does my customers' data live, who can see it, and is it used to train models?
- What is on the roadmap versus working today, in writing?
- What happens to my data if I stop?
AMS and automation: vendor questions
Integration
- What it reads from my AMS
- What it writes, and which fields
- What is live vs planned, in writing
Control
- Who approves
- Preparer cannot approve
- What happens when it is unsure
Data
- Where data lives
- Who can see it
- No training on our data
- Return and deletion when we leave
Download this checklist as a PDF (one page, free, no sign-up).
Common mistakes and what they cost
Each of these is a common route to an errors-and-omissions (E&O) problem. None of it is legal advice; follow your carriers' rules and your agency's procedures.
- Buying automation to replace the AMS. Two systems of record disagree, and nobody is sure which one a certificate came from.
- Accepting "integrates with your AMS" without detail. Integrations vary from read-only to full write; discovering the gap after signing leaves manual steps you thought were gone.
- Letting activities live only in the automation tool. The AMS file is incomplete, which matters when a claim or audit relies on it.
Questions
Does Shlix IBS replace our AMS?+
No. It works in the inbox around your AMS and reads from it. The AMS stays your system of record.
Which AMSs do you connect to?+
Microsoft 365 for email today. AMS360 is in build. Others are planned; see the integrations page for each system's status.
Can automation work with more than one AMS?+
Usually, if each has a connection or the agency supplies the record. Agencies that have acquired other books often run two systems for a while; ask how the vendor handles that.
Do we need IT staff to connect an AMS?+
Usually not much. Someone with admin rights grants access, often on a short call; the vendor should do the rest and document what was connected.
Who owns the data the automation creates?+
The agency should. Check the contract says so, and that the data is returned or deleted when you leave.
Will automation change how our AMS is set up?+
It should not need to. It reads the records you already keep. Agencies often tidy master certificates and contact records first, which helps both systems.
What if our AMS has no integration?+
Requests can still be read, sorted, routed, timed and approved. Drafting uses a record the agency maintains until a connection exists.