Spreadsheet replacement
Replace the insurance operations spreadsheet with a connected AI workflow.
Move insurance teams tracking prospects and operations in spreadsheets from fragile spreadsheet handoffs into a focused workflow with clearer ownership, live context, and connected execution.
Introduction
Administration wrapped around a system that cannot change.
Almost every insurance operations process starts in a spreadsheet, and for a while that is the right call. A sheet holding prospects, quotes issued, renewal dates, and outstanding documentation costs nothing, takes an afternoon, and fits the process exactly — because the person who built it is the person who runs it.
Renewal dates live in a column that is only reviewed when somebody remembers to sort by it, which is usually close enough to the date to be uncomfortable. Manual administration around a core system is workable at low volume. It becomes the constraint when volume grows, because the core system cannot change on the timescale the business needs and everything flexible has moved into a spreadsheet.
What follows covers that transition for insurance teams tracking prospects and operations in spreadsheets: what the sheet holds, why it fails, what the replacement records instead, and — set out plainly further down — the case for leaving it where it is.
The problem
Four ways an insurance sheet carries risk.
The core system holds policy data and cannot be extended quickly, so the flexible work-in-progress state lives in a sheet beside it. That sheet then becomes a second record of things the core system owns, and the two disagree — which in a regulated business is a materially different problem from ordinary data drift.
Two administrators update the sheet from different customer conversations and the resulting record reflects one of them, with no indication that the other happened.
The sheet holds prospects, quotes issued, renewal dates, and outstanding documentation, and the authoritative version of most of it already lives in Salesforce or Gmail. The core system says the policy is in force, the administrative sheet says documents are outstanding, and the customer has been told two different things by two people.
You're likely here because
- The flexible part of the process lives entirely in spreadsheets
- Renewal dates live in a column that is only reviewed when somebody remembers to sort by it, which is usually close enough to the date to be uncomfortable.
- When a row is stale, a renewal window passes without contact because the row was not surfaced in time
The operating problem
Why the current process stops scaling.
Move insurance teams tracking prospects and operations in spreadsheets from fragile spreadsheet handoffs into a focused workflow with clearer ownership, live context, and connected execution.
Failure mode 1
Policy data gets duplicated
The sheet starts holding what the core system owns, and the two disagree. In a regulated business a second, unauthoritative record of policy state is a compliance exposure rather than an inconvenience.
Failure mode 2
No audit trail on administrative decisions
Who did what and when is not recorded. Record-keeping obligations attach to communications and decisions, and a spreadsheet satisfies none of them.
Failure mode 3
Regulated judgement drifts into the workflow
A sheet with a decision column invites underwriting or coverage determinations to be recorded and eventually made there, which is outside what any general tool should support.
Failure mode 4
Document collection is manual and untracked
The highest-volume administrative task has no ageing, no reminders, and no cross-customer view, so chasing is done from memory during the busiest periods.
The record model
What the replacement holds that the sheet cannot.
- Core system boundary
- What the core system owns versus what the workflow layer owns, in writing. Duplicating policy data is the failure that makes these projects worse than the spreadsheet.
- Administrative state between transactions
- The work in progress the core system has no representation for, which is why it currently lives in a sheet.
- Outstanding document with age
- The highest-volume administrative task and the point at which customers most often feel the process has failed.
- Regulated-decision routing flag
- So anything requiring underwriting, coverage, pricing, or claims judgement goes to a qualified person rather than being processed.
- Customer communication record
- Retained to your regulator’s requirements rather than a general default, because communication records are themselves regulated artefacts.
- Complaint indicator
- Because complaint handling carries specific obligations and timelines that a general request queue will not meet.
- Policy reference read from core
- Read rather than copied, so the workflow layer never becomes a competing record of policy state.
How it works
From manual administration to a tracked workflow.
Step 01
Describe the insurance operations process
Define what the core system owns and what the workflow layer owns, in writing, before anything is built. That boundary is the whole design.
Step 02
Connect the systems of record
The core system supplies policy state, email supplies customer correspondence, the document store holds what has been received. Reading the core system rather than copying it is what prevents a second source of truth.
Step 03
Build the operating surface
Document collection status for one workflow, with ageing and reminders. It is the highest-volume administrative task and it touches no regulated decision.
Step 04
Migrate the workflow, not just the data
In-flight administrative work moves. Anything in the sheet duplicating core system data is removed rather than migrated, and that review comes first.
Step 05
Route the exceptions
Anything requiring underwriting judgement, a coverage decision, or a regulated determination routes to a qualified person rather than being processed.
Step 06
Measure renewals contacted before their notice window closes
Administrative cycle time and outstanding items by age. Both are countable without touching any regulated decision.
Implementation path
Building around the core system rather than replacing it.
- 01
Audit what the sheet currently holds that the core system owns. Removing that duplication is the first task and it is a compliance improvement rather than a tidy-up.
- 02
Have record-keeping, retention, and complaint-handling requirements reviewed before go-live. These are regulated obligations rather than configuration preferences.
- 03
Start with document collection, which is administrative in every jurisdiction and where most of the recoverable time is.
- 04
Confirm what interfaces the core system genuinely exposes before designing around them. Vendor policy constrains these integrations more often than technology does.
- 05
Run it alongside the sheet for one full cycle, then retire the file only after the parallel run holds.
Controls
Controls that matter.
Control 01
A hard boundary against underwriting, coverage determination, claims adjudication, and pricing — those route to qualified people rather than being automated
Control 02
Record retention and audit trail configured to your regulator’s requirements rather than to a general default
Control 03
The core system read rather than copied, so the workflow layer never becomes a competing record of policy state
Build with Launch
Turn the operating requirement into working software.
- • Build a insurance operations app
- • Add forms, views, status, and workflow logic
- • Create role-specific dashboards
Operate with Grow
Keep the workflow connected after the interface exists.
- • Attach follow-up where the workflow touches revenue
- • Keep customer context connected
- • Measure activity through the same context
Connected context
Keep systems of record. Fix the gaps between them.
These are representative connections. UbiGrowth supports 700+ connections across business systems. Connection availability and permissions depend on workspace configuration.
The case against
When the spreadsheet is still the right answer.
If volume is low enough that administration fits comfortably around the core system, this is premature. But a sheet duplicating policy data should be addressed regardless of volume, because that exposure does not scale with it.
Examples
Three administrative gaps that close.
The document chased four times
Outstanding items with age and receipt-driven reminders remove the manual chasing that consumes administrative capacity and irritates the customer more than the request itself.
Where is my application?
Administrative status visible to the customer removes status enquiries, which are typically a large share of inbound contact and carry no information the system lacks.
The renewal that came round unprepared
Renewal preparation as a tracked workflow with lead time turns a recurring scramble into scheduled work, without touching any pricing or coverage decision.
Measurement
Measure the workflow, not the demo.
Choose a baseline before implementation so speed, quality, exceptions, and downstream impact can be compared using the same definitions.
Model the value of moving repetitive spreadsheet work into a connected workflow.
Use the ROI calculator with your own workload, lead volume, close rate, and deal assumptions. The result is illustrative, not a guaranteed outcome.
Open the ROI calculator →Limitations and considerations
Where the regulated line is drawn.
- This is administrative software. Underwriting, coverage determination, claims adjudication, and pricing are regulated activities requiring qualified judgement and are outside what this should touch.
- Insurance is regulated differently in every jurisdiction, and record-keeping, complaint handling, and customer communication all carry specific requirements. Review before go-live with whoever is accountable.
- Core system integration is frequently constrained by the vendor. Confirm what interfaces exist before designing a workflow that depends on them.
- Connector coverage varies: Salesforce, Gmail, Google Calendar are representative rather than guaranteed, and the fields exposed depend on your workspace permissions.
Keep people in control of consequential decisions.
Automate bounded, observable work first. Keep explicit approvals, escalation paths, permissions, and auditability around financial, legal, clinical, employment, coverage, or other consequential decisions. The goal is faster execution with clearer control—not unbounded autonomy.
FAQ
Questions teams ask before moving off the sheet.
Does this make underwriting decisions?
No. Underwriting, coverage determination, and claims adjudication are regulated activities that route to qualified people. This handles the administrative workflow around them — intake, documents, status, scheduling — which is where the recoverable time is.
Will it replace our core system?
No, and attempting it is how these projects fail. The core system stays authoritative for policy data; the workflow layer holds the administrative state between transactions, which currently lives in spreadsheets and email.
What about the policy data already in our sheet?
Remove it rather than migrating it. A second, unauthoritative record of policy state is a compliance exposure in this business, and eliminating it is one of the clearest wins available.
Where does it save the most time?
Document collection and status enquiries. Both are purely administrative, both are high volume, and neither requires touching a regulated decision — which makes them the right place to start.
Do we still need Salesforce?
Yes. Salesforce stays authoritative for what it owns, and the new surface reads it through a governed connector rather than storing a second copy.
How do we know whether it actually worked?
Measure renewals contacted before their notice window closes against the baseline you took before switching, alongside manual updates removed and how often a record turns out to be stale.
Start with ARIA
Ask ARIA to build the replacement.
Describe what the spreadsheet is really doing. ARIA plans the operating surface, connects the systems that stay authoritative, builds it, and keeps it running.
- ARIA acts only through the systems and permissions you connect.
- Connections use scoped credentials you can change or revoke.
- Actions are recorded, and consequential ones can require approval.
Start here
Rebuild the insurance operations workflow, not the file.
Keep the core system authoritative, remove duplicated policy data first, and route every regulated judgement to a qualified person.