Prepared byIncredible
AI Discovery · Scoping Sprint · Poutama Trust

From a grant engine to a client-centred CRM

A working guide to what we heard across our discovery calls, and where AI and better systems can free your team. The foundation Heta framed: put the client at the centre, hold the grant and RBP data around it, and work backwards from the impact you want to measure.

Client-centred CRM Connect the systems Automate the busywork

Three layers, built in the right order

The picture Heta drew on our recent call reframed the whole engagement: the current platform was built to process grants, not to put the client at the centre. So we start with the foundation - the right data home - then connect the systems around it, then deliver the wins your team feels day to day.

A client-centred CRM

The anchor system

The client sits at the centre. Grant data and Regional Business Partner data are held around it, connected with marketing, finance and analytics - not bolted onto a 1990s grant-processing platform.

Foundation

Connect the systems

One source of truth

Chris's API, GraphQL and MCP layer over the existing database, plus Xero and the RBP portal, so 15-20 years of data flows where the team needs it rather than being re-keyed by hand.

Enabler

Automate the busywork

Wins the team feels

One-click board and monthly reporting, a financial scorecard that takes the guesswork out of assessment, AI checks on application completeness, and activity logs that fill themselves.

Quick wins

Nothing here is locked - we rank it together. Delivery follows pain and impact, not strictly this order: a quick win can ride alongside the foundation. The guiding principle is Heta's - start from the impact you want to show, then work back to the data the grants process needs to capture.

Priorities, in order

Ranked by impact against effort, and worked through with Chris and Von on the call. The CRM is the foundation; the rest scaffold off the existing grant engine. Incredible defines what's most valuable and how it fits together, and Chris builds a lot of it alongside us - we use what's there with extraction layers, not a rebuild. Tap any card to open it.

1

The client-centred CRM

Scaffold off the grant engine, put the client at the centre
Highest impactDesign first

The pain

  • The platform was built to process grants, not to put the client at the centre, and it's business-centric rather than contact-centric.
  • Marketing, finance and analytics aren't integrated, so AI-enabled work is weak without a proper data home.
  • Patching the existing system would only put "lipstick" on a 1990s-era design.

What we'd build

  • Month-one discovery and a prototype CRM with the priorities mapped onto it.
  • Define the data and capabilities you genuinely need, working backwards from the impact you want to measure.
  • Incredible sets the CRM's boundaries and how it integrates with the existing system; Chris builds a lot of it alongside us, using extraction layers rather than a rebuild.
"This was built to process grants. It wasn't built to put the client at the centre."Heta, reframing the current system (4 June call)
2

Automated reporting

Built where the data sits, surfaced where the team needs it
Highest painPart-built

The pain

  • Board and monthly reports are built by hand from CSV exports and a 20-year spreadsheet, with payments entered two or three times over.
  • The harder part isn't the build - it's pinning down exactly what the team needs reported on.

What we'd build

  • Generate the detailed reports in the existing platform where the data already sits, and surface a curated subset up in the CRM (Chris is already progressing this).
  • A natural-language / MCP layer so the team can ask for a report in plain English, get the data, and save the good ones as recurring reports.
  • Live dashboards with a fixed month-end snapshot for the board.
"My biggest pain point is the reporting side."Von, on what hurts most day to day
3

Follow-up & outcomes tracking

The missing impact data - restarted and automated
High impactFoundations exist

The pain

  • Poutama used to follow up on what businesses did with the funding, but that stopped about five years ago - so the real impact story goes uncaptured.
  • There's no prompt telling advisors which reviews are due, so the long tail just slips.

What we'd build

  • Restart the outcomes / review system - the data models already exist in the platform.
  • Scheduled, proactive check-ins (a month after payment, and again a year on) sent automatically via email / Campaign Monitor, with two or three quick questions.
  • Track who's responded, flag who to call, and feed it all back into the client record - a forward-looking activity log.
"That's critical for them, so they can see how that money is going."Chris, on restarting outcomes follow-up
4

Financial scorecard & prioritisation

Take out the guesswork, and rank against the budget
Medium painMedium build

The pain

  • Financial assessment leans on each advisor's read of the accounts, so it varies by advisor and industry.
  • With a fixed monthly budget, there's no easy way to prioritise which applications get funded.

What we'd build

  • A standardised scorecard (the method Heta brought from accounting) rating a business by figures, industry and headcount.
  • A role-aware dashboard - e.g. a board-member view - pulling the right data up.
  • A prioritisation board: application cards per business or region, shuffled against a budget "red line".
"Kind of taking that guesswork out."Von, on the scorecard approach
5

Application completeness check

AI vets the paperwork before a human does
Medium painQuick to build

The pain

  • The admin team manually checks every application for completeness.
  • Around 90% upload their attachments, but nothing verifies the documents against what's required.

What we'd build

  • An AI pass at the admin-review step that scans the uploads (business plan, financials, quotes) and flags anything missing.
  • Builds on the MCP and identification work Chris has already started.
"Does this have all of the stuff we need?"Chris, on an initial AI pass at review
6

Activity log, comms & client stories

Stop copying and pasting - and stop losing the good stories
Lower painQuick to build

The pain

  • Emails and call notes are copied and pasted into the activity log by hand - no drag-and-drop.
  • The team is too busy to capture success stories, photos and quotes when they happen, so by newsletter or press time the moment has passed.

What we'd build

  • Auto-capture and summarise email and call interactions into the client record.
  • Proactively gather stories, photos and quotes (with permission) for newsletters and press releases - Von already drafts newsletter articles via GPT and Campaign Monitor.
"We're just having to copy and paste that."Von, on logging interactions today
+

On the radar, not yet

Real ideas, parked until the foundation is set
Later

Ideas raised

  • Māori business directory & sustainability play - a verified directory the network funds itself, advertising to the Māori economy, and using the data to chase leads for more funding. A real revenue opportunity, raised by Matt and Chris.
  • Structured iwi / hapū / marae field - currently free text, so it can't be reported on accurately. Worth a structured (RBP) list, mindful of the political sensitivities.
  • RBP portal de-duplication - reduce the double data entry between the MBIE RBP portal and your own system.
  • Voice capture for field staff - hands-free notes and report generation on the road.

Why parked

None of these is unimportant - they simply sit below the foundation and the wins above. The directory in particular is a genuine revenue idea; we pull anything forward when it earns its place as we rank together.

Pain against ease of build

Top-right is where we look first: high pain, quick to build. The CRM sits high for impact but is a design-first piece, so it runs in parallel while the quicker wins land. Reporting drifts left on ease - the build is easy, pinning down what to report is the harder part. We'd rank these together with you.

Pain / impact →
1CRM foundation
2Reporting
3Follow-up & outcomes
4Scorecard
5Completeness
6Activity & comms
+Parked ideas
Ease of build →
Foundation & reporting Impact & assessment Quick wins Parked / later

The team, and how knowledge flows

Today, the knowledge lives in the system and in people's heads, but reports are rebuilt by hand in the middle. With the CRM as the single source of truth, knowledge-holders feed it and everyone else pulls straight out. Toggle to see the shift.

Asks / waits for an answer Holds knowledge to capture

From enquiry to impact - and where the CRM plugs in

01

Eligibility gate

Applicant

WordPress form filters serious applicants before the full application.

02

Online application

Applicant

Business plan, financials and quotes uploaded into the system.

03

Admin review

Admin team

Completeness check, link to business, allocate to an advisor. AI pre-check plugs in here.

04

Advisor assessment

Business advisor

Ratios, scorecard, due diligence and recommendation. Scorecard plugs in here.

05

Approval & letter

Advisor / admin

Status change and approval letter to the client.

06

Payment

Maaria / Xero

Paid on the 5th or 20th; reconciled in Xero.

07

Reporting & impact

Von / Maaria

Board and funder reporting. Automated reporting and the CRM plug in here.

The people

Von (Vonese Walker)

Business advisor · engagement lead

Our main point of contact and the person driving this forward on the Poutama side. Carries grants assessment and the reporting - the reporting pain is hers. Conceptual sign-off on the scope. Knowledge feeder

Heta (Heta Hudson)

Chair & interim CE

Set the client-centred CRM direction and the scorecard method, drawing on his accounting-partner background. Holds the strategy, the impact lens and sign-off. Knowledge feeder

Chris (Chris Beaven)

Developer · Tactful

Built and maintains the core system; knows the data better than anyone. Standing up the API, GraphQL and MCP layer. We work alongside him, not over him. Technical sign-off. Knowledge feeder

Maaria

Admin & finance

Keeps the weekly tracking spreadsheet and reconciles payments in Xero. Her sheet is what the reporting is built from today. Knowledge feeder

Jeanna (Jeanna Love)

Commercial manager

Coordinates the RBP work, workshops and outreach. Connects the AI pilot and the wider Poutama programme. Consumer

Advisors & admin

~5 across grants

Assess applications, manage the pipeline and run the Monday dashboard stand-up. The day-to-day users who feel the wins. Consumers

Names and roles are as we understood them - tell us if we've got any wrong, and who else should be in the room.

The systems, and how they fit

The bespoke system is home. Everything else feeds into it or flows back out. Most clients can't expose their core system to AI - Poutama already can, which is a real head start.

The integration prize

15-20 years of structured data, plus Chris's API / GraphQL / MCP layer. A deep, consistent data trove and a way to reach it. That combination is what turns the CRM and the reporting from a wish into something we can build quickly.

Core system · Home

Bespoke system (Django + Postgres)

Built and maintained by Chris; evolved from a 1990s MS Access database. On a VPS with AWS backups. Holds the full grant and application history.

Becomes the CRM the others feed
Integration layer

API, GraphQL & MCP

Chris already exposes a REST API and GraphQL, and is standing up an MCP server, with per-developer tokens.

The bridge we build on
Front door

WordPress (poutama.co.nz)

Public site plus the JavaScript eligibility gate that filters applicants before the full application.

Keep as the applicant front door
Accounting

Xero

Payments and financials; reconciled manually by Maaria, then folded into reporting.

Integrate to end manual reconciliation
Government portal

MBIE RBP portal

Separate portal for Regional Business Partner work; data is re-entered and CSV-imported today.

Reduce double entry; hold RBP data in the CRM
Due diligence

Companies Register & insolvency

Chris built links for director, shareholding and 50% Māori-ownership checks.

Keep and surface inside the CRM
File storage · Core

Dropbox

Poutama's core file system - everything lives here. Predates Office 365; Von to set up a shared folder for the team. SharePoint / Office 365 is email and Word / Excel only.

Shared folder for spreadsheets and resources
Comms / marketing

Campaign Monitor

Newsletters and engagement tracking. Articles are drafted (via GPT) and sent from here; Denise organises the monthly newsletter.

Channel for automated follow-up comms
Manual / legacy

Tracking spreadsheets (x3)

Maaria's 20-year reconciliation sheet (the board reports are built from it), the Monday-hui pending-pipeline sheet, and the RBP KPI tracker - all maintained by hand.

Auto-produce from the system; free up ~a day
Capture / assist

Transcription (e.g. Otter)

Discussed for capturing client meetings and turning them into notes and actions.

Optional capture into the client record

Open questions, your input

This is what we'd like to work through. Please correct anything we've got wrong, add detail in your own words, and tick an item once it's confirmed and ready for us to build from. It's the fastest way to sharpen the roadmap between now and the next session.

Built from our WIP call on 17 June - items marked heard today were touched on, raised today are newer threads.

Your notes save automatically on this device as you type. When you're done, hit Copy responses and paste them into your reply to us - that's how they reach the Incredible team.

0 of 0 confirmed

The grants journey - where we start

?
Can we walk one real application end to end - the “Coworker” example Von offered - from enquiry to payment and reporting?heard todayVon demoed the general flow on the kickoff; this is the deep, single-journey walk to pinpoint where time is lost between systems.
?
The model is business-centric today, with a one-to-many person table - do we restructure toward a genuinely client / contact-centric record?heard todayChris confirmed the business is the primary entity and has long wanted it more contact-centric; “must keep” the data, “nice to have” the restructure.
?
Lots of unattached enquiry contacts (0800 callers with no business yet) already sit in the database - how should the CRM hold and track those?heard todaythey're the top of the funnel we want to track from first contact.
?
How should the CRM handle the monthly budget caps, the $10k limit, prioritisation and carry-over into the new financial year?heard todayChris's idea: a board of application cards per business or region, shuffled against a budget red line.

The client-centred CRM foundation

?
Extend the existing system as the foundation (with extraction layers), rather than adopt an off-the-shelf CRM - agreed?heard todayHubSpot was discussed and set aside as costly and clunky; the steer is to build on Chris's back-end, not replace it.
?
Of the 20-year schema, what is must-keep, what is nice-to-have, and where should we start preserving historical business snapshots?heard todaynothing has been retired (deprecated fields kept), but only the latest business data is held - some history is currently overwritten. Chris to dump the full schema.
?
What does “client at the centre” need to hold, and what should each role - applicant, advisor, admin, board - see and do?defines the core model and the three stakeholder journeys.
?
Working backwards: what impact must the board and funders be able to show?Heta's principle - it drives the questions the grants process must capture, and links to outcomes tracking below.

Reporting, reconciliation & where it lives

?
Should detailed reports live in the existing platform, with a subset surfaced up to the CRM, rather than rebuilt CRM-side?heard todayChris's strong steer - it's easier to build where the data sits, and he's already doing more reporting work.
?
Can we end the triple-handling of every payment - the 20-year reconciliation spreadsheet, the database's financial section, and Xero?heard todaytoday each grant payment is entered in all three; the board reports are pulled from the spreadsheet. A single entry point, synced out, is the prize.
?
Can the system auto-produce the three manual spreadsheets - the reconciliation sheet, the Monday pending-pipeline sheet, and the RBP KPI tracker?raised todaythe data already lives in the system; generating these would save Von roughly a day and remove the risk of a missed entry skewing the board report.
?
For “they don't always know what to report on”, does a natural-language / MCP reporting layer fit - ask in plain English, get the data, save the good ones as recurring reports?heard todayit tackles the real challenge Chris flagged: getting to the right fields, not the build itself.
?
The exact reports - board, monthly, funder and government - with cadence, recipients, and live dashboard vs month-end snapshot?to scope the automation precisely (Von to send examples through).

Follow-up, outcomes & client stories

?
Restart outcomes tracking - following up on what businesses did with the funding - which stopped about five years ago?raised todayVon wants it back and Chris sees it as critical; the data models already exist. This is the missing piece of real impact data.
?
Scheduled, proactive follow-ups - a check-in a month after payment, and again a year on - sent automatically via email / Campaign Monitor?raised todaytakes the load off advisors and behaves like a forward-looking activity log; responses flow back into the record.
?
Capture client stories, photos and quotes as they happen, for newsletters and press releases?raised todaythe team is too busy to gather these later; the newsletter (organised by Denise) is already drafted via GPT and Campaign Monitor. Sits between reporting and comms.

The core system & integrations

?
Core system: the data-model dump, and what the REST / GraphQL / MCP layer exposes today vs needs adding, plus per-developer tokens and a test environment.heard todayChris to dump the full schema; he can add layers or raw API as we need them.
?
Xero: it isn't integrated today and only the finance team use it - what should sync, and in which direction, to remove the manual reconciliation?heard todayXero is bank reconciliation and invoicing only; grant payments are also tracked in the database and the spreadsheet.
?
Dropbox is the core file system - we'll work from the shared folder Von is setting up. Anything else we should know about how files are organised?raised todayeverything lives in Dropbox (it predates Office 365); SharePoint / Office 365 is email and Word / Excel only.
?
Campaign Monitor - fold it in as the channel for newsletters, engagement tracking and the automated follow-up comms?raised todaya system we hadn't captured; it's already where Poutama's newsletters and engagement data live.
?
Should the system become a wider compliance hub - holding the trust's broader investments and the audit checklist, not just grants?raised todayChris's idea: less reliance on individuals' spreadsheets and memory, so a board member can see “are we compliant?” at a glance.
?
MBIE RBP portal: confirm the registration flow (regional partner email, e.g. Cedar EDA, plus the Poutama team) and what can be automated rather than re-keyed.heard todaya recurring duplication pain - one for Jeanna and Von.
?
WordPress front door (set up by Dan, self-updated by the team), Companies Register / insolvency checks, and the iwi / hapū / marae field - keep, surface, and structure?keep the front door and due diligence; a structured iwi field is what makes that reporting accurate, mindful of the sensitivities.

The financial scorecard & prioritisation

?
Confirm the exact scorecard tool and licensing (we heard a name like “NowAnalysis”), its inputs - figures, industry, headcount - and the rating it produces? Or derive a Poutama scorecard from the 20-year dataset?your own data of approvals and outcomes may beat an external tool.
?
A prioritisation view that ranks applications against the available budget?heard todayChris's idea: drag application cards against a budget red line, per business or region.

Adoption, governance & getting started

?
Who are the champions across advisors, admin and the board, and what devices and training will they need?adoption decides whether the wins actually stick - and trust matters (Maaria will want to see the system match her sheet before letting it go).
?
What does the board need to see to release the next phase of budget?the scoping document is built specifically for that sign-off.
?
The signed contract from Heta, and the promised resources into the shared Dropbox folder - process map, reports, the “Coworker” example, the scorecard, the data model?needed to start the kickoff.

Bigger bets - parked for later

?
Using the data for sustainability: a verified Māori business directory, advertising to the Māori economy, and leads for more funding.raised todaya genuine revenue opportunity Matt and Chris both flagged, but it sits below the foundation - we park it and pull forward if it earns its place.

Working assumptions

These shape the estimates. The first one is usually the biggest risk on a job like this - and for Poutama it's largely good news.

The usual big unknown - API / MCP access - is already a green light

On most engagements, the largest risk is whether the core system can be reached programmatically. Here, Chris has confirmed a REST API and GraphQL, and is building an MCP server. We just need the endpoints and the data model confirmed. No fallback layer required.

A deep, consistent data trove

15-20 years of structured data in Postgres, with deprecated fields retained - a strong foundation for analytics and AI.

High confidence

Chris has real capacity

Around 15-20 hours a week and largely free of his other client for ~2 months. We build alongside him, not over the top of him.

High confidence

Sprint model, board-ready output

First 35-hour sprint is discovery, scoping and quick wins. Output: a board-ready roadmap scoping document (plain-English, a technical companion, and a visual layer), signed off by Von conceptually and Chris technically.

Confirmed

Extend the existing system as the anchor

On the call the steer was clear: build on Chris's back-end with extraction layers rather than adopt an off-the-shelf CRM (HubSpot was discussed and set aside as costly and clunky).

Leaning confirmed

Xero integration scope

Feasible in principle; exact scope and approach to be confirmed in scoping.

To confirm

Contract signature outstanding

Heta gave the verbal green light; the signed copy hasn't landed yet. The kickoff starts on signature.

To confirm

Where to from here

  • We chase the signed contract from Heta, then run the internal kickoff.
  • Von to set up a shared Dropbox folder (Stephen + a developer) and drop in the spreadsheets - the reconciliation sheet, the Monday pending-pipeline sheet and the RBP KPI tracker. Anonymised or multiplied numbers are absolutely fine.
  • Chris to dump the full data-model schema for us to look over.
  • We'd like a short call with Maaria around her end-of-month reconciliation - it connects into most of what we're building.
  • Matt is away next week, so we'll skip that catch-up and trade items async by email. Next working session: 1pm, Tuesday 30 June.
  • Output by month-end: a board-ready roadmap scoping document to release the next phase of budget.