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 systemThe 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.
Connect the systems
One source of truthChris'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.
Automate the busywork
Wins the team feelsOne-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.
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.
The client-centred CRM
Scaffold off the grant engine, put the client at the centreThe 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.
Automated reporting
Built where the data sits, surfaced where the team needs itThe 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.
Follow-up & outcomes tracking
The missing impact data - restarted and automatedThe 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.
Financial scorecard & prioritisation
Take out the guesswork, and rank against the budgetThe 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".
Application completeness check
AI vets the paperwork before a human doesThe 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.
Activity log, comms & client stories
Stop copying and pasting - and stop losing the good storiesThe 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.
On the radar, not yet
Real ideas, parked until the foundation is setIdeas 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.
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.
From enquiry to impact - and where the CRM plugs in
Eligibility gate
ApplicantWordPress form filters serious applicants before the full application.
Online application
ApplicantBusiness plan, financials and quotes uploaded into the system.
Admin review
Admin teamCompleteness check, link to business, allocate to an advisor. AI pre-check plugs in here.
Advisor assessment
Business advisorRatios, scorecard, due diligence and recommendation. Scorecard plugs in here.
Approval & letter
Advisor / adminStatus change and approval letter to the client.
Payment
Maaria / XeroPaid on the 5th or 20th; reconciled in Xero.
Reporting & impact
Von / MaariaBoard and funder reporting. Automated reporting and the CRM plug in here.
The people
Von (Vonese Walker)
Business advisor · engagement leadOur 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 CESet 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 · TactfulBuilt 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 & financeKeeps 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 managerCoordinates the RBP work, workshops and outreach. Connects the AI pilot and the wider Poutama programme. Consumer
Advisors & admin
~5 across grantsAssess 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.
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 feedAPI, 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 onWordPress (poutama.co.nz)
Public site plus the JavaScript eligibility gate that filters applicants before the full application.
Keep as the applicant front doorXero
Payments and financials; reconciled manually by Maaria, then folded into reporting.
Integrate to end manual reconciliationMBIE 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 CRMCompanies Register & insolvency
Chris built links for director, shareholding and 50% Māori-ownership checks.
Keep and surface inside the CRMDropbox
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 resourcesCampaign Monitor
Newsletters and engagement tracking. Articles are drafted (via GPT) and sent from here; Denise organises the monthly newsletter.
Channel for automated follow-up commsTracking 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 dayTranscription (e.g. Otter)
Discussed for capturing client meetings and turning them into notes and actions.
Optional capture into the client recordOpen 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.
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.
The grants journey - where we start
The client-centred CRM foundation
Reporting, reconciliation & where it lives
Follow-up, outcomes & client stories
The core system & integrations
The financial scorecard & prioritisation
Adoption, governance & getting started
Bigger bets - parked for later
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.
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.
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.
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).
Xero integration scope
Feasible in principle; exact scope and approach to be confirmed in scoping.
Contract signature outstanding
Heta gave the verbal green light; the signed copy hasn't landed yet. The kickoff starts on signature.