From NPS 20 to NPS 60: How a Financial Advisory Firm Fixed Service Quality Without Hiring

Operations started breaking at 50 clients. NPS was 20. A manager was hired to fix it. The chaos continued.

The same team, with the same service, went on to serve 2,000+ clients. NPS reached 60 within twelve months of the system being in place.

The team did not change. The system did.

The Situation Before

The operations started breaking at around 50 clients. At that point the team was two people, tracking everything on a shared spreadsheet, scheduling calls by email, and sending every update manually. It was not a sustainable model — but at small numbers, it held together through effort.

Then client volumes grew. The spreadsheet could not keep pace. Emails were falling through. Calls were being scheduled by back-and-forth that took days. The team was spending more time managing administration than doing financial planning. NPS at this stage was 20-25. Clients were frustrated. The team was stretched. Escalations were becoming routine.

A senior manager was hired to bring structure. It did not work. A manager is still a human, which meant the same lag, the same missed updates, the same gaps in visibility. The chaos continued.

The service itself was a three-stage financial planning process. Stage one: a data collection call. Stage two: the financial plan built and presented. Stage three: a final action plan delivered. In theory, this took 15-20 days. In practice, it was taking 3-4 months — not because the work was slow, but because everything around the work was broken.

• Client status was tracked on a shared spreadsheet that advisors couldn't keep up with.
• Email response SLA was one business day. It was being missed by two, three, four days regularly.
• No one knew which tasks were pending, which were overdue, or which clients were at risk of escalating.
• Scheduling the next call required back-and-forth emails between the advisor and client that could take days.
• The 10-15 minutes an advisor spent sending a templated welcome email was enough to break their flow mid-plan.
• Escalatory emails from frustrated clients were going unnoticed until the situation had already deteriorated.

A senior manager was hired to bring structure. It did not work. The manager was a human, which meant the same lag, the same missed updates, the same gaps. The chaos continued.

Before building anything, the team established three design principles for whatever system came next. First: advisors should only advise. Nothing that was not directly related to financial planning should touch their day. Second: anything repetitive should be automated. Third: the system should reduce friction for its users, not introduce new kinds of it. The Excel sheet had failed partly because maintaining it became its own burden.

The Foundation: Airtable as the Operations Layer

PhotonMan chose Airtable as the backbone. Not as a spreadsheet replacement — as an application platform. The database schema was designed before a single automation was configured. Entities defined included clients, advisors, analysts, tasks, plans, calls, and emails. Relations between them were established properly from the start.

Two integrations were then connected via Zapier. Google Calendar — so that every call scheduled on any advisor's calendar was automatically logged in Airtable against the right client. Gmail — so that every inbound and outbound email in every advisor's account was logged in Airtable against the right client.

This created a single source of truth. The complete history of every client — every call, every email, every deliverable — was visible in one place. That data pipeline was the foundation everything else was built on.

See our Airtable consulting approach for how we apply this database-first design principle across different industries.

Automatic Task Creation

The journey of each client involved three milestone calls: data collection, financial plan presentation, and action plan delivery. Each milestone had a predictable set of tasks that followed it — for both the advisor and the analyst assigned to the client.

Because Google Calendar was already synced to Airtable, the system knew the moment any of these calls was scheduled. That event became the trigger.

• Data collection call scheduled: task created for the advisor to send meeting minutes to the client, due the day after the call.
• Financial plan call scheduled: task created for the analyst to complete the plan four days before the call; task created for the advisor to review it three days before; task created for the advisor to send meeting minutes the day after.
• Action plan call scheduled: same pattern — analyst builds, advisor reviews, advisor sends minutes.

No human had to create any of these tasks. No manager had to check whether they existed. The calendar event was the signal. The system did the rest.

Automatic Task Closure

Creating tasks automatically was useful. Closing them automatically was harder — and more important.

The problem with manual task closure is that humans are unreliable markers of their own completion. They forget. They mark things done early. They mark things done late. None of this is bad intent — it is just what happens when you ask people to maintain metadata about their own work while also doing the work.

The solution used the outgoing email as proof of completion. Every client-facing task required an email to be sent. That email contained an invisible identifier — a task stamp — embedded in a consistent position in the email body, invisible to the client but readable by Airtable.

When the email was sent, Airtable intercepted it. Three validation checks ran automatically: does this stamp belong to the advisor who sent the email? Does the task belong to the client the email was sent to? Does the email content match the expected task type? If all three passed, the task was closed in real time. If any failed, an alert was raised.

For analyst tasks — which did not involve client emails — a simple Airtable form served as the completion mechanism. The analyst submitted the form. The task closed.

Advisor Assignment and the Welcome Email

Every new client needed to be assigned to an advisor. Previously, the owner would manually check the workload across all advisors and allocate accordingly. On a good day this happened within a few hours. On a busy day — or a Sunday — it could take two or three days.

The welcome email compounded the problem. Once assigned, the advisor was supposed to send the client an introductory email: their name, the data collection checklist, their Calendly link, and how the process would work. Even copying from a template and personalising it took 10-15 minutes. When an advisor was deep in a financial plan or back-to-back on calls, that email got delayed.

The result was a client who had paid, received nothing for two or three days, and started wondering whether the service was real. That silence was not indifference. It was a process gap. But the client could not tell the difference.

Airtable fixed both gaps at once. The moment a client completed onboarding, a round-robin script allocated the most available advisor automatically. A WhatsApp message went to the client within seconds confirming who their advisor was. The welcome email — complete with checklist, calendar link, and onboarding instructions — was sent automatically from the advisor's email address. The advisor did not write it, trigger it, or remember it. It went out immediately, every time.

Escalation Detection

Even with the task system running cleanly, some clients would still escalate. A delayed response, a misunderstanding, a plan that did not meet expectations — these things happen in any service business.

The problem was detection speed. All client emails were copied to the owner, but manually reading every email in real time was not possible. By the time an escalatory thread was noticed, the client had often already sent a second or third message, each one more frustrated than the last. The situation had compounded before anyone could act.

Since all inbound emails were already being logged in Airtable, the solution was straightforward. Around 50-60 phrases commonly found in escalatory emails were identified from past cases and stored as a detection list. Airtable scanned every incoming email against that list. When a match was found, the owner received an immediate alert — not a digest, not a summary at end of day. A notification in real time, so the response could happen before the client's frustration grew further.

This was a rule-based keyword system. No AI involved. But it was effective — and it would be significantly more capable with a modern LLM doing the classification today.

The NPS Feedback Loop

When the final action plan was delivered, the task closure triggered one more step before marking the engagement complete. A task was created for a second advisor — not the one who delivered the plan — to manually review the deliverable. Human in the loop, at the right step.

Once that reviewer marked the quality check as done, two things happened automatically. The client received a feedback email asking how their experience had been. Attached to that email was an NPS survey.

This meant every client who received their plan was asked for feedback. Not some clients. Not clients the team remembered to follow up with. Every client, every time, automatically.

Performance Visibility and the End of the Leave Policy

Every team member received automated weekly and monthly email summaries of their task performance: how many tasks were completed, how many were on time, how many were delayed, and where they sat relative to their targets.

Incentives were tied to on-time completion rates. If more than 80% of tasks were completed within their due dates, the team member was eligible for their bonus. The system tracked this automatically. No manager needed to assess it.

The leave policy was scrapped entirely. The team was given quarterly delivery targets — a number of financial plans to complete, calculated from available hours and average plan duration. As long as those targets were met, how and when the team worked was their own business. Sick days, personal days, travel — none of it required approval. The numbers either met the target or they did not.

A team that managed its own time against clear, automatically-tracked performance targets behaved like adults. Because they were treated like adults.

The Results

The NPS improvement from 20 to 60 in twelve months is the headline, but understanding what drove it matters. NPS at 20 was not a product quality problem. The financial plans were good. It was a delivery reliability problem. Clients were waiting 3-4 months, not hearing back on emails, and feeling like they were being ignored after paying.

The system fixed those things without changing the product or the people. Plans started arriving in roughly one month for active clients. Emails were responded to on time because tasks were automatically created and tracked. Clients felt the service was responsive because it was.

The capacity ratio is the number that demonstrates the scale of what was achieved. Operations were breaking at 50 clients. With the system, 2,000+ clients were served. That is not a marginal improvement in efficiency. That is a different operating model.

What This Means for Similar Businesses

Any service business with a team delivering multi-step work to a growing client base will hit a version of this problem. The spreadsheet stops working. Emails pile up. Good people start spending their day on administration instead of their actual work. Hiring a manager feels like the obvious answer.

The lesson here is that the manager is not the problem. The absence of a system is the problem. A manager inserted into a system without structure becomes another person trying to manage chaos manually.

The architecture that worked here — calendar as the task trigger, email as the task completion proof, a relational database as the single source of truth — is applicable to any professional services business: consulting, legal, accounting, recruitment, coaching.

See our process automation consulting work for how we approach this kind of operational design for service businesses.

What We Learned

The database schema matters more than the automations. The time invested in designing the Airtable data model — defining every entity, every relationship, every field — was the work that made everything else possible. Automations built on a well-structured database are straightforward. Automations built on a poorly structured one fail in ways that are hard to diagnose.

The email stamp was an unconventional solution that worked precisely because it met the team where they already were. Advisors were sending emails anyway. Adding a stamp to those emails required minimal behaviour change. The system did not demand that the team learn a new tool or develop a new habit. It plugged into something they were already doing.

The human in the loop at the quality check step was deliberate and important. Automation handles the routine. Judgment handles the exceptions. Putting a human review at the final deliverable — where the stakes were highest — was the right place for that judgment call.

Finally: the NPS improvement was a lagging indicator. It took months to show up after the system was deployed. If the team had measured NPS at week two after launch and found it still at 20, they might have concluded the system was not working. It was working. The client experience just needed time to register.

Anmol Gupta

Builder of systems, breaker of manual processes. Founder of PhotonMan. 12 years running a FinTech firm taught him that the best hire is often a well-designed workflow.