Sales targets for five gyms left the spreadsheet and now come straight from NextFit
Fitness Academia has been around for more than two decades and runs five locations across Chapecó and Cunha Porã, Brazil. The sales data already lived in NextFit, but the commercial target was rebuilt by hand in a parallel spreadsheet — with a different rule at each location. Epicora built the platform that reads NextFit every five minutes and turns it into a single reading: the network, the location, and each sales rep's contribution.
- Client
- Fitness Academia (Chapecó and Cunha Porã, Brazil)
- What we did
- Sales-target platform integrated with the NextFit ERP — network dashboard, per-location dashboard and synced sales
- Platform
- Responsive web (React · NestJS · MongoDB · AWS + Vercel)
The starting point
Fitness Academia is a gym network with more than two decades in business and five locations across Chapecó and Cunha Porã. The commercial operation — prospecting, sign-ups and renewals — is run by sales reps, and the network already used NextFit as its ERP: every sale, every plan, every cancellation was already recorded there.
The problem was not missing data. It was that the data never reached the people who needed it. The target was tracked in a parallel spreadsheet, filled in by hand from NextFit itself — the same number, typed twice. What one location counted as "a sale that hits the target" was not what another counted, so the numbers were not comparable. And the sales rep, who most needs to know how much is left to hit the goal, had no screen at all: she had to ask the manager or open a shared spreadsheet that also exposed everyone else's performance.
- Targets rebuilt by hand in a spreadsheet from data that already existed in NextFit — pure rework, with typos and a number that was always out of date.
- A different rule per location: what counted toward the target varied, and the numbers never reconciled.
- No autonomy for the sales rep: to know how much was left, she depended on the manager or his spreadsheet.
- A shared spreadsheet isolates no one — everyone's performance was visible to everyone.
- No network view: the manager compared five spreadsheets instead of looking at one number.
The turning point
Epicora did not build a second place to type sales into. The architectural decision was the opposite: NextFit remains the single source of truth, and the platform never accepts manual entry. A job reads each location's API every five minutes and mirrors the sales into the application database — and every screen works off that mirror, never querying the ERP live. That delivered two things at once: instant reads for the user, and an integration that does not overload the client's ERP.
Before writing the integration, Epicora ran a technical spike against the real API to find out what the documentation did not say: the request limit NextFit actually tolerates, and how each sale type arrives in the payload. That spike set the sync frequency and the classification rule — which is why the integration did not break when it scaled to five locations.
The second structural decision came from a scope review with the client: the target belongs to the location, not to the individual rep. Each location has a monthly target, and each rep sees her contribution to the collective number — not an individual quota. That reshaped the whole product, and the network gained a number that means the same thing at all five locations.
The decision that unlocked it
Deciding that only plan sales count toward the target — and that everything else does not even show up. Gym-pass partnerships, one-off products and drop-in classes are still imported for history, but they do not add up and they do not clutter any screen. That ended the divergence: every sale you see in the platform is, by definition, a sale that counts. There is no more "depends how you count it".
What we delivered
The network dashboard — five locations on one screen
Network target, actuals, attainment percentage and how many locations hit the target this month, with the list sorted by attainment — worst first, because a manager does not need confirmation about who is doing well, he needs to know where to step in. Next to it, the month's curve against the target line, to see whether the pace on day 10 will hold up by day 31.
The location dashboard — the screen the sales rep never had
A progress ring for the location's target, how much is left, days remaining and a "your contribution" block with what that rep added to the total. She sees her own location as a whole — target, actuals and her colleagues' contributions — and never sees another location.
Synced sales, with a correction in the manager's hands
Every plan sale coming from NextFit, with search, filters by period, location and rep, sale detail and CSV/PDF export. A sale cancelled in the ERP shows up as cancelled on its own. And because real life happens, the admin has a per-sale toggle to force whether it counts toward the target — the case of a member transferred between locations, or an entry made at the wrong one.
Targets, locations and a sync log you can audit
Target setup per location and month, with a structural block against two targets in the same period. Each location has its own API key, with a connection test and on-demand manual sync. And every job run is logged with duration and result — how many records read, new and updated — so "why did this number change?" is a question with an answer.
How we made it safe
Isolation between locations, not just between screens
Two roles — admin and collaborator — and the collaborator's isolation holds everywhere: not through a manipulated URL, not through a filter, not through an export can a collaborator reach another location's data. Scope is enforced in the backend, not hidden in the frontend. JWT with refresh tokens, email invitations and a strong password policy validated on both ends.
An integration that respects the client's ERP
Each location's API key is stored encrypted. The sync is incremental and paginated, with backoff and throttling adapted to NextFit's real limit — discovered in the spike, not assumed. Because every screen reads the local database, a usage spike in the platform never becomes a request spike in the ERP. And the log shows the whole network synced in the same five-minute window: five out of five locations.
Independent QA with the authority to reject
The delivery went through Epicora's own QA, run by someone who did not write the code — and who rejected it three times before approving. The third round caught the kind of bug that only shows up in real use: the period filter built the day window in UTC and, since the operation runs on Brasília time, late-night sales fell into the next day. Fixed by computing the day's edges in local time. Only then was the system presented to the client.
The result
In the first full month with the platform live, the network closed at 104% of target, with four of the five locations hitting their number. The platform does not sell for the team — the reps did the selling. What changed is that, for the first time, that percentage came out of the system and not out of a spreadsheet: it came from sales read straight from NextFit, under a single rule, with every sync logged and auditable.
And adoption shows up in the database itself: the client created all fifteen accounts for the operation on their own in the weeks after delivery, and already has targets set through December — half-year planning done inside the tool, not in a new spreadsheet tab.
Related solutions
Related cases
Is the data you need already in your system — just not readable?
Epicora connects what your operation already uses and turns it into the reading the decision requires: one number, updated on its own, the same for everyone.