Software / CRM
Industry: Professional Services
40%
Faster cycle
In short
Arcetis built a custom CRM for a professional services business to replace scattered spreadsheets with a single system of record. The platform, built on Laravel, React, PostgreSQL, and Redis, added workflow automation, role-based access, and real-time reporting — delivering a 40% faster cycle time and 3x faster reporting.
A professional services business had outgrown the spreadsheets it relied on to run sales and operations. As the business scaled, deal tracking, account handoffs, and reporting were spread across disconnected files with no shared source of truth, making it difficult for leadership to see the real state of the pipeline or trust the numbers behind it. The company needed a purpose-built system that could unify sales and operations data, enforce consistent workflows between teams, and give leadership live visibility into performance. Arcetis was engaged to design and build a custom CRM platform from the ground up — one built around how the business actually operates rather than a generic off-the-shelf tool retrofitted to fit.
Before the engagement, the client's sales and operations teams ran on a patchwork of spreadsheets. Deal information, account status, and handoff notes lived in whatever file a given rep or manager last updated, with no shared system tracking where a prospect or engagement actually stood at any given moment. For a professional services business, where the sales-to-delivery cycle depends on clean handoffs between the people who close work and the people who deliver it, this created a structural gap: information had to be manually re-entered, re-explained, or re-confirmed every time it moved from one stage or owner to the next. The absence of a single source of truth had compounding effects. Reporting was manual and after the fact — someone had to pull numbers from multiple spreadsheets, reconcile conflicting versions, and assemble a picture that was often stale by the time it reached leadership. There was no reliable way to view the full pipeline in one place, no consistent record of who owned which handoff, and no shared definition of what stage a given deal or engagement was actually in. Access control was effectively nonexistent: spreadsheets don't distinguish between what a frontline rep should see and what only a manager should, so either everyone saw everything or teams siloed information further to compensate — which only made the visibility problem worse. This kind of environment is common in professional services firms that have grown past the point where spreadsheets and email threads can keep pace with the volume of deals and accounts moving through the business, but haven't yet invested in a system built around how the business actually works. The risk isn't only inefficiency — it's the erosion of trust in the numbers. When two people can pull two different versions of the same pipeline, leadership ends up making decisions on instinct rather than current data, and operational handoffs slip through cracks that no single role owns. Professional services organizations in particular tend to run into this problem as they grow, because the work being sold and the work being delivered are handled by different teams operating on different timelines — a sales cycle that closes today hands off to a delivery team that may not engage with an account for weeks, and both sides need a shared, unambiguous record of what was agreed to and what stage the relationship is actually in. Spreadsheets can support that handoff when volume is low enough for people to track manually and check in with one another directly, but they don't enforce it, and enforcement is what breaks down first as the number of deals and accounts moving through the business grows past what any one person can hold in their head. The business needed more than a reporting layer bolted onto its existing spreadsheets. It needed a platform that could serve as the actual system of record for sales and operations — one where a deal's status, next action, and owner were unambiguous, where the handoff from sales to delivery happened automatically rather than through a forwarded email, and where leadership could look at a dashboard and trust that what it showed was current. That meant rethinking the underlying data model and workflow logic from scratch rather than layering automation on top of the spreadsheet habits already in place, and it meant building role-based access into the foundation of the system so that visibility could scale with the organization rather than being an afterthought.
Arcetis led the end-to-end design and build of the custom CRM platform, from data modeling through deployment. Arcetis architected the application on Laravel, React, PostgreSQL, and Redis, and designed the core data model to unify sales and operations activity that had previously lived in disconnected spreadsheets. Arcetis built the workflow automation layer that governs how deals and accounts move between stages and teams, replacing manual handoffs with system-driven ones. Arcetis implemented role-based access control so that visibility into pipeline and account data matched each user's function in the organization. Arcetis also built the real-time reporting layer, including the live dashboards used by leadership, and was responsible for the underlying performance work — including Redis-backed caching — that made that reporting fast at scale.
Arcetis designed a data model purpose-built for the client's sales and operations process, replacing the ad hoc structure of spreadsheets with a normalized PostgreSQL schema that represents accounts, deals, and handoffs as first-class, relational entities. This gave the business a single, unambiguous source of truth for pipeline and account data, and provided the structural foundation that the workflow automation, access control, and reporting layers were all built on top of.
Arcetis built automation into the core of the CRM so that handoffs between sales and operations happen as a function of the system rather than a manual forward of an email or spreadsheet row. As a deal or account reaches a defined stage, ownership and required actions transfer automatically to the appropriate team, removing the manual re-entry and re-confirmation steps that previously slowed transitions and left status ambiguous between teams.
Arcetis implemented role-based permissions across the platform so that what a user can see and act on is tied to their function in the organization rather than being all-or-nothing. Frontline reps, managers, and operations staff each get a view scoped to their responsibilities, which lets the business open up visibility into the CRM broadly without the uncontrolled exposure that made the previous spreadsheet-based approach risky.
Arcetis built a live reporting layer, backed by Redis, that gives leadership dashboards reflecting the current state of the pipeline rather than a manually assembled snapshot. Instead of reconciling numbers from multiple spreadsheets after the fact, leadership can view up-to-date figures on demand, which is the basis for the reporting speed improvement measured after launch.
Arcetis built the platform's frontend in React and its backend in Laravel, delivering a single cohesive application rather than a set of point tools. This full-stack ownership let Arcetis control the experience end to end — from how a rep interacts with a deal record to how data is stored, queried, and surfaced in dashboards — and kept the automation, access control, and reporting layers tightly integrated rather than bolted together after the fact.
Arcetis approached the build as a ground-up platform rather than a customization of an existing CRM product, since the client's core problem — no single source of truth, no consistent workflow logic, no controlled visibility — required control over the data model and business logic that off-the-shelf tools don't typically expose. The stack was chosen to match that goal: Laravel as the backend framework, React for the frontend, PostgreSQL as the primary data store, and Redis for caching and performance-sensitive operations. On the backend, Laravel's conventions around models, controllers, and service classes provided a structured way to encode the business rules that had previously lived only in people's heads or in spreadsheet formulas — what stage a deal needs to reach before it hands off to operations, who becomes the owner at each transition, and what data is required to move forward. Domain logic for workflow transitions was implemented as explicit, testable rules within the application rather than scattered across ad hoc scripts, which is standard practice for a CRM where handoff correctness matters as much as raw data storage. Laravel's queue and event system is a natural fit for this kind of workflow automation: a stage change on a deal or account fires an event, and listeners handle the resulting side effects — reassigning ownership, notifying the next owner, updating dependent records — asynchronously, so the user making the change isn't blocked waiting on downstream automation to finish. PostgreSQL was used as the system of record, with the schema modeling accounts, deals, users, and roles as relational entities with proper foreign-key constraints — the direct opposite of the spreadsheet model, where relationships between records existed only informally, if at all. Role-based access control was implemented at the application layer, scoping queries and API responses by the requesting user's role so that a given endpoint returns only the data that user is permitted to see, rather than filtering after the fact in the UI. Redis served two standard roles in this architecture: as a cache for the data behind the reporting dashboards, and as the backing store for queued jobs generated by the workflow automation. Real-time dashboard reporting on a system with meaningful transaction volume is typically too slow to serve directly from repeated live aggregation queries against the primary database, so aggregated figures were cached in Redis and invalidated or refreshed as underlying data changed — the standard pattern for delivering fast, near-live reporting without placing continuous load on PostgreSQL. This caching layer is the direct technical driver behind the reporting speed improvement the client saw after launch. On the frontend, React was used to build the interfaces reps, managers, and operations staff interact with day to day — pipeline views, deal and account detail pages, and the leadership-facing dashboards — communicating with the Laravel backend over a REST API. Building the frontend as a single-page application allowed the pipeline and reporting views to update responsively as data changed, rather than requiring full page reloads, which matters for a tool meant to replace the always-open, constantly-edited spreadsheets it superseded. Given that workflow automation directly controls ownership and handoff behavior across the business, correctness in that layer needed to be verified before rollout rather than discovered afterward. Automated tests covered the workflow transition rules and the role-scoped query logic in particular, since a defect in either would surface either as a broken handoff or as pipeline data visible to a user who shouldn't have had access to it — the two failure modes the project existed to eliminate. Deployment followed a staged rollout rather than a single cutover, letting the client's team validate the new system against real pipeline and account data before fully retiring the spreadsheets it replaced. Throughout, Arcetis treated the workflow automation and access control layers as core architecture rather than late additions, since retrofitting either into a CRM after launch is materially harder than designing them in from the start.
Stage transitions on deals and accounts are modeled as events within the Laravel application, with listeners handling the downstream effects of a handoff — reassigning ownership, updating related records, and triggering notifications — asynchronously via Laravel's queue system. This keeps handoffs consistent and system-enforced rather than dependent on someone remembering to notify the next team, which was the core failure mode of the spreadsheet-based process it replaced.
Dashboard and reporting data is cached in Redis rather than computed live against PostgreSQL on every request, which is what makes real-time reporting viable at the speed leadership needs. This caching layer is the direct technical basis for the 3x reporting speed improvement measured after the platform went live, replacing a process that previously required manual assembly from multiple spreadsheets.
Permissions are enforced at the API and query layer in Laravel, scoping what data each request can return based on the requesting user's role, rather than relying on the frontend to selectively hide information. This ensures access control holds regardless of which client or view is used to reach the data, which is a meaningfully stronger guarantee than the informal access boundaries spreadsheets provided.
Accounts, deals, users, and roles are modeled as normalized, related tables in PostgreSQL with enforced foreign-key constraints, giving the business one consistent representation of pipeline state instead of the parallel, frequently conflicting versions that existed across separate spreadsheets. This relational structure is what makes automated workflow transitions and role-scoped reporting possible in the first place.
Faster cycle
Reporting speed
Technology used
Key learnings
This engagement is a clear example of a pattern common across professional services and other operationally complex businesses: the limiting factor isn't a lack of data, it's the lack of a single, trusted place for that data to live. Spreadsheets are flexible enough to get a business through its early stages, but that same flexibility becomes a liability once multiple teams depend on the same information moving accurately between them. The fix isn't a better spreadsheet template or a lightweight reporting tool layered on top — it's a system where the data model, the workflow rules, and the access boundaries are designed together from the start. Building workflow automation and role-based access control into the architecture from day one, rather than adding them after launch, proved to be the right sequencing: both depend on having a clean, relational data model underneath them, and retrofitting that structure onto a live system is far harder than designing it in from the beginning. The Redis-backed reporting layer also underscored a practical point about "real-time" reporting claims generally — live dashboards are only as fast as the caching and invalidation strategy behind them, not the dashboard UI itself. The measured results — 40% faster cycle time and 3x faster reporting — reflect what happens when automation replaces manual handoffs and caching replaces manual data assembly: the time isn't saved by working harder inside the old process, it's saved by removing the manual steps the old process required in the first place.
When the core problem is a lack of a single source of truth combined with business-specific workflow and handoff rules, an off-the-shelf CRM often requires as much customization to fit those rules as a custom build would — without giving full control over the underlying data model. In this engagement, Arcetis built a custom platform on Laravel, React, PostgreSQL, and Redis specifically so the workflow automation, access control, and reporting logic could be designed around how the business actually operates rather than adapted to a generic tool.
Stage changes on a deal or account are treated as events within the application: when a record reaches a defined stage, the system automatically reassigns ownership and triggers the next required actions, instead of relying on a person to notice the change and manually notify the next team. This is what enabled the automated sales-to-operations handoffs delivered in this engagement.
Real-time dashboards are typically too slow if every view triggers a fresh aggregation query against the primary database. In this build, Arcetis used Redis to cache reporting data so dashboards could be served quickly and refreshed as underlying data changed, which is the direct technical driver behind the 3x reporting speed improvement measured after launch.
Rather than hiding data in the frontend based on user role, permissions were enforced at the application and query layer in Laravel, so that each API request only returns data appropriate to the requesting user's role. This gives a stronger, more consistent access guarantee than filtering visibility after the data has already been retrieved.