Short answer

As a rule, we don't import asset registers from spreadsheets — but it depends on the quality of the data. Civic.ly needs two things a spreadsheet almost never has: precise locations (latitude/longitude or what3words) and properly itemised assets (one row per physical item). Most council spreadsheets fail both — they group assets into single line items (one row for a whole playground, or "22 benches" on a line), carry no photos, and are often years out of date. So spreadsheets are usually not fit for purpose for import, and the better route is to capture assets in the field by walking the town and village — which doubles as a chance to ground-truth what's actually still there.

Two exceptions where we can import: a council with good location data already in Parish Online or Pear Mapping (we have imported from both), and a genuinely high-quality spreadsheet that is itemised and does carry precise locations — send it over and we'll assess it.

Detail

Why spreadsheets usually don't work:

  • No precise locations. Civic.ly is a mapping platform — every asset sits at a point or area on the map. A spreadsheet typically has a postal address or a free-text location ("Recreation Ground") at best, not the latitude/longitude or what3words coordinate the platform needs to place a pin. Without that, there's nothing to import the asset onto.
  • Not itemised. Most asset registers are grouped, because they were built for an accountant's fixed-asset register, not for field operations. A single line covers a whole playground rather than each swing, slide, and safety surface; "22 benches" sits on one row. Civic.ly works at the level of the individual item that gets inspected, serviced, and has its own history — so a grouped register can't be mapped to individual assets without re-doing the itemisation by hand.
  • No photos. Field capture in Civic.ly is photo-led; spreadsheets carry none.
  • Often out of date. A spreadsheet is only as current as the last time someone physically checked. Councils frequently haven't visited every location to confirm assets are still there, in what condition, or whether new ones have appeared. Importing a stale register just bakes the staleness in.

Why field capture is the better route anyway:

Customers who've built their register by walking the town and village have almost always discovered their old spreadsheet was out of date — assets gone, assets added, conditions changed. So capturing in the field isn't just a workaround for the import limitation; it's a genuine opportunity to ground-truth the whole register at the point of onboarding.

When we can import:

  • Parish Online / Pear Mapping. Councils already holding their asset locations in one of these GIS tools have proper coordinates, so we have imported from them.
  • A genuinely good spreadsheet. If a council does have a well-built register that is itemised down to the individual asset and carries precise locations (lat/long or what3words), it's worth sending over — we'll assess whether it's fit for purpose and, if so, import it. The bar is the two requirements above: precise locations and one row per real item.

Watch-outs

  • "It's all on a spreadsheet" is the most common prospect/onboarding objection — frame it as an opportunity (ground-truthing), not a blocker, and set expectations early that walking the assets is the norm, not a fallback.
  • Don't promise an import before seeing the file. The decision turns entirely on data quality (locations + itemisation). Ask to see the spreadsheet before committing.
  • Bulk imports are an internal/back-end operation, run from the DataImport process — not a self-service feature in the web app. A council can't upload a spreadsheet themselves.