Customer master data layer
The list became the central record for customer identity, location, chain logic, payment processor, fee status, exemptions, notes, and revenue context.
Case Study
Building a customer master list and gateway-fee operating model.
At Silverware, I took ownership of the gateway-fee process and built the master list behind it, then expanded that same foundation into a broader customer and revenue source of truth. What started as a payment-governance project became the operating layer for fee control, customer prioritization, revenue visibility, and market segmentation.
Company
Silverware POS
Role
Operations Strategist
Tools
n8n, Power Automate, Microsoft Forms, Teams, master spreadsheets
Business Problem
Silverware needed one system to manage customer fees, payment strategy, and revenue visibility.
The business could not manage gateway fees, Silverware Pay conversion, customer exemptions, and revenue planning effectively while customer data stayed fragmented across teams and tools.
Silverware needed to roll out gateway fees without creating avoidable confusion, churn risk, or inconsistent customer handling.
Customer, payment, revenue, and exception data lived across scattered lists, systems, and informal knowledge instead of one usable operating file.
The business needed one shared model that could handle gateway-fee governance, payment-status visibility, customer prioritization, and revenue analysis.
Approach
I built one operating system instead of solving the payments and customer-data problems separately.
The gateway-fee workflow and the customer master list reinforced each other. Better customer data made approvals and exemptions more reliable, and the fee process created the reason to keep the customer record current.
Started by consolidating 2,000-plus customers into one master list that classified payment status, fee eligibility, exemptions, and chain relationships.
Built a structured gateway-fee process with gating logic, Customer Success escalation intake, approval workflows, refund handling, and Accounting notifications.
Used Microsoft Forms, Power Automate, n8n, and Teams-based approvals to keep exception handling and refunds traceable instead of ad hoc.
Expanded the same master list into a broader customer and revenue source of truth with SaaS spend, DaaS spend, ARR, NRR, accessibility, and account value context.
Used the unified model to support Silverware Pay conversion strategy, processing-volume reporting, market segmentation, and revenue recovery.
System Design
The strength of the solution was how customer data, approvals, refunds, and revenue context worked together.
This was not just a spreadsheet project and not just a fee workflow. It was a connected operating model that helped multiple teams work from the same customer picture.
Gateway-fee governance
I built the rules for who should be charged, who should be protected, and how contract, enterprise, and multi-location exceptions should be handled consistently.
Automation and approvals
Form submissions, Teams approvals, refund logic, Accounting emails, and refund confirmation tracking turned a sensitive fee rollout into a controlled workflow.
Revenue and segmentation backbone
Once expanded, the same file supported customer spend analysis, ARR and NRR visibility, accessible-market logic, and downstream Customer Success prioritization.
Outcomes
The result was better operational control, stronger retention, and much better revenue visibility.
The biggest win was not one metric. It was giving Silverware a working system for fee governance, customer-level decisions, and revenue clarity that multiple teams could actually use.
Helped retain more than $1 million in ARR from at-risk customers during the gateway-fee rollout.
Supported more than $120 million in payment-processing volume moving from other processors onto Silverware Pay.
Exposed approximately $700K to nearly $1M in missed SaaS revenue and unaccounted AR, which the business was then able to collect.
Created the operational source of truth used for gateway fees, customer prioritization, executive visibility, and later market segmentation work.
Key takeaway
What began as gateway-fee control became the company's customer and revenue operating layer.
Lessons Learned
The best operations work often starts with one pain point and grows into a broader system.
This project reinforced how often a narrow operational problem is really a data, governance, and visibility problem underneath.
A sensitive customer-facing fee needs strong data and exception governance behind it, not just a billing rule.
A master list becomes much more valuable when it evolves from a tracking file into an operating layer for multiple teams.
Automation helps most when approvals, ownership, and update paths are already clearly defined.