Build Reporting Layer for VICIdial Statistics Integration

@starttechno

Your VICIdial data lives in MySQL and your reporting needs to live in Supabase/Postgres, so the heart of this is a clean ETL plus a well-shaped reporting schema. I'd pull incrementally from vicidial_log, vicidial_closer_log, vicidial_agent_log and vicidial_list on a 1-5 minute cron (watermark on call_date/event time, so no full re-scans), land the rows in staging tables, then normalise into fact tables for calls and agent time with dimensions for agent, campaign, lead source and disposition. Inbound, outbound and CBACK get flagged distinctly at load time so callbacks never double-count as fresh inbound. On top of that I'd build SQL views and materialised views for the KPIs you listed — logged/pause hours, talk time, conversion rate, sales per hour — at both agent and call-centre level, each filterable by date range, agent, campaign and lead source so a dashboard can query them directly. I'd finish with a reconciliation script comparing daily totals against VICIdial's own reports so you can trust the numbers. Two practical things: I'll need read-only access to the VICIdial database, and since call records include customer phone numbers we should agree how those are stored or masked. Do you want the phone numbers kept in full in Supabase, or masked? Muhammad Saad

@novalitztech

Hi, I understand you need a reporting layer for VICIdial stats integrated into Supabase, focusing on calls and agent activity. I have experience with similar integrations. Could you please clarify the deadline for this project?

@codeandcommand

I have done PHP reporting layers on top of VICIdial data before, pulling agent and call stats and pushing them into a separate store. For Supabase I would sync via scheduled queries or a small PHP script hitting the VICIdial DB directly. Can start today, working version in 3 days. This price and timeline are first-pass estimates from the post, we will lock in real numbers once we go over the full scope. Let me know and I will send a plan.

@Cruz1217

If the sync misses the brief window when a call changes state, the reporting tables will quickly fall out of step. I'll set up a PHP daemon that pulls the VICIdial call log via its MySQL view every 2 minutes. It will transform rows into normalized Supabase tables and use edge functions to upsert the data. A common mistake is to rely on a single bulk load and then recalculate KPIs on the fly, which overloads the database. You’ll get clean daily and hourly aggregates, filterable by agent, campaign, and lead source, and the numbers will match the official VICIdial reports.

@abela399

Hi, I can build the reporting layer around Supabase with VICIdial as the source, focusing on reliable synchronization and reporting accuracy rather than simply copying raw call data. I’d structure the pipeline to pull incremental VICIdial data every 1–5 minutes, normalize calls, agents, campaigns, callbacks and lead sources, then expose reporting views optimized for the dashboard. Inbound, outbound and CBACK calls would be handled explicitly so they don’t distort agent or campaign KPIs. The reporting layer can provide logged hours, calls, conversion rates, sales per hour and other KPIs with filters for date range, agent, campaign and lead source. I’d also include validation/reconciliation checks against VICIdial reports so discrepancies can be identified rather than silently propagated. I’d keep the architecture modular so additional KPIs or dashboard components can be added later without changing the underlying ingestion logic. Abel

@nicolasarmandoc

Hello I’ve worked on data-driven systems involving API integrations, reporting layers, dashboards, and backend data processing, so building a reliable analytics layer between VICIdial and Supabase is the kind of architecture work I’m comfortable with. How are VICIdial statistics currently exposed in your environment, through database access, API endpoints, or exported reports? I would start by mapping the required call-center metrics, then design a normalized reporting structure in Supabase with automated synchronization, validation, and KPI views optimized for dashboards. I’d focus on keeping inbound, outbound, and callback data consistent while creating flexible filters for agents, campaigns, lead sources, and time periods. The goal would be a reporting layer that remains accurate and easy to extend as your analytics needs grow. Happy to review your current VICIdial and Supabase setup. Best regards, Nicolas.

@morganh61

Hello, With over a decade of software development expertise, I am confident I can create the robust reporting layer you need to fully integrate VICIdial statistics into your Supabase setup. My skills align perfectly with your project requirements, particularly my experience in designing database-integrated systems and RESTful APIs. I understand the crucial need for accurate and up-to-date data for effective decision-making, which is why I'll ensure that your VICIdial data is synchronized with Supabase every 1-5 minutes. Efficient handling of inbound/outbound/CBACK calls is critical, and my proficiency in PHP assures you seamless workflows and proper management of call types. When it comes to reporting, I excel in creating detailed views and KPIs that are easily filterable based on various parameters such as date range, agent, campaign, and lead source - exactly what you've requested. Finally, I am well-versed in conducting thorough data validation and reconciliation against existing reports. This means that you can have confidence not only in the accuracy of the data displayed through the reporting layer but also its alignment with VICIdial's original reports. With my holistic approach to development; from architecture to deployment; you can be assured of a high-quality solution that delivers on its promises. I'm excited t Thanks!