AMS360 servicing guide
Copy / share
For AI agents
How to streamline servicing work in AMS360
Settle the interface, version and grant before any AMS360 servicing step, and close every service item on a readback, not an action response. Start each item with the right policy, transaction date and source edition, retrieve and reconcile the current comparison, and prepare a narrow reviewed change plan.
Talk through your agency's workflows
See Decla with your team
Book a demo to walk through how Decla fits the day-to-day work your agency team handles, and where to start.
Discuss your servicing task and evidence needsOn this page
- Start with the interface, version and grant
- Read the release note for the operation, not for every task
- Use four checkpoints before closing a service item
- Settle these questions before delegating a servicing task
- Worked example: wrong transaction date, revised source and missing readback
- Give each exception an owner and a stop
- Start with one servicing task
- Related pages
- Frequently asked questions
This guide is for servicing account managers and the operations or system owner at an AMS360 agency.
Start with the interface, version and grant
Vertafore's general help lists application programming interface (API) options: Web Service API (WSAPI) versions 2.4 and 3.0, OData and Enterprise Management Service (EMS). Record the interface and version your agency actually uses before choosing a retrieval or change operation. Its Web Service setup guidance describes entity-specific access actions; an available interface is not an agency grant.
Use this map to plan what to verify on your own setup.
| Interface | Provider context | Check before relying on it |
|---|---|---|
| WSAPI 2.4 and 3.0 | Separate versions listed in Vertafore's general help | Confirm the exact version, permitted entity or action, and agency identity. Do not carry permissions across versions. |
| OData | Listed separately from WSAPI and EMS | Identify the supported retrieval and its date or filter basis. A returned record does not mean a change is allowed. |
| EMS | Enterprise Management Service; operation-specific release notes | Match the exact endpoint, required identifiers and transaction context before considering any action. |
Sources
- Vertafore — general API help — accessed
- Vertafore — Web Service API Setup — accessed
Read the release note for the operation, not for every task
Vertafore's June 26, 2026 EMS entry describes POST /policy/commercial-locations/search as retrieval of commercial policy locations using PolicyId and TransactionEffectiveDate, with sorting and pagination. Despite POST, this is a search—not a location update.
The September 16, 2026 entry for PUT /policy/transaction-premiums says values absent from the request remain unchanged and that billed premiums restrict certain fields. It does not identify every allowed maintenance field in that paragraph. Check the applicable contract and billing state rather than assuming a description or premium value can be changed.
The reviewed help pages display an October 2, 2026 last-updated footer; checked October 6, 2026. Confirm your agency has deployed a service pack before relying on an operation it describes.
Sources
- Vertafore — EMS / API Release Notes — accessed
Use four checkpoints before closing a service item
Pin the record and transaction context.
Match the account, policy and affected item to the selected source edition. Record the policy term, the requested change date and the record's transaction-effective date separately. A policy match alone does not settle which dated transaction you retrieved. Owner: servicing account manager.
Retrieve and reconcile before preparing a change.
Use an allowed retrieval to establish the current comparison. Check completeness, source period and edition. Keep missing values unknown and retain the previous source. A corrected query date resolves the query gap; it does not approve the change described in the returned material. Owner: assigned source reviewer.
Write a narrow, versioned change plan.
Identify the exact fields to change, values to preserve, supporting source and required review. Have the system or billing owner check operation-specific prerequisites, including any billed-state restriction. If a later source changes the request, return the affected plan to review before acting. Owner: agency system or billing owner.
Separate action evidence from record verification.
When the specific action is authorized and accepted, retain its attempt and response reference. Obtain a separate allowed readback for the intended record, transaction date and field values. If the result is unknown or the values disagree, keep the service item open and assign investigation before deciding on a retry. We hold this line because of a report from one agency: a task came back with some requested items done and others not, and a per-item result is what shows which. Owner: receiving servicing colleague.
Settle these questions before delegating a servicing task
Before handing a servicing task to a colleague or a tool, answer the question in each row on your own setup.
| Servicing task | Question to settle | Evidence that settles it |
|---|---|---|
| Certificates | Does the action update the certificate record the AMS uses for later reissues, or only attach a file to the account? | A readback of the certificate record itself, not only the attachment list. |
| Agency-bill invoices | Is the invoice operation both documented and exposed to your account, license and interface version? | Documentation for your interface and version, a permitted test showing the operation is available to your account, and a readback of the result. |
| Emails logged as activities | Is the logged activity the final edited version that was actually sent, from the right sender, and how are duplicates caught? | Sender, recipient, sent status and final version; an activity readback that matches them; the duplicate-check result for that send. |
| Commercial applications and ACORD forms | Source data, missing fields, review, signature and any write-back are separate steps. Which can your setup actually complete? | Separate evidence for each step. A completed form does not show that it was signed or that the record was updated. |
Worked example: wrong transaction date, revised source and missing readback
Take Account A, a sample account with a January 1–December 31, 2026 term. The task is to prepare a reported location-description change for review, with a requested servicing date of October 15, 2026. Its source and billing-state checks remain held. Each row closes only the gap it names.
| Step | Record and date basis | Evidence available | What remains open | Next owner and output |
|---|---|---|---|---|
| First comparison | Policy A, Location A; query dated October 1, 2026 | Comparison uses an earlier transaction date | Does not establish the requested October 15 context | Account manager: correct the retrieval scope |
| Corrected comparison | Policy A, Location A; requested October 15, 2026 | Date corrected; the comparison's second page is incomplete | Date gap closed only; full location set still unknown | Source reviewer: obtain the missing page |
| Earlier instruction | Location A; requested October 15; equipment storage | Earlier description retained as comparison | Superseded by the revised instruction | Source reviewer: keep as reference, not as clearance |
| Revised instruction | Location A; requested October 15; adds equipment servicing | Revised source received October 8, 2026 | Description changed; exact use and change plan await review | Account manager: return the revised question to review |
| Billing question | Policy A; selected transaction; proposed description field | Question assigned; no answer yet | Billed status and permitted field maintenance unknown | Billing owner: return dated prerequisite evidence |
| Investigation accepted | The held task above | Colleague accepts obtaining the missing page and the billing answer | Investigation accepted only; no change, issuance or readback | Receiving colleague: return evidence to source reviewer |
When the action returns only an acknowledgment. Now take a different task where identity, context, grants, prerequisites and a reviewed plan are all in place, and the action returns only an acknowledgment with no readback. The intended values are still unverified. The next step is a separate permitted readback before any retry.
Give each exception an owner and a stop
- Wrong policy, item or transaction date. Retain the conflicting references and return the exact match question to the account manager.
- A requested field is omitted or blank. Record that distinction in the change plan. Use the selected operation's documented semantics; do not substitute a generic "clear all" rule.
- Billing prerequisite or allowed action is unresolved. Hold that change and obtain the system or billing owner's disposition. A successful retrieval does not authorize a premium change.
- Action response is missing or readback disagrees. Retain the attempt reference, assign investigation and check whether the original action took effect before any retry.
Start with one servicing task
Pick one servicing task. Write down the interface, version and grant it uses, run it through the four checkpoints, and close it only when a readback matches the plan. An action response tells you something was attempted; the readback tells you what was saved.
Frequently asked questions
How can AI streamline servicing work in AMS360?
Settle the interface, version and grant before any AMS360 servicing step, and close every service item on a readback, not an action response. Start each item with the right policy, transaction date and source edition, retrieve and reconcile the current comparison, and prepare a narrow reviewed change plan.
What is Decla?
Decla is AI software for independent insurance agencies and brokerages. It connects to your AMS, email and carrier portals and does back-office work inside them. Your team reviews the work before it goes out.