Soltex: connecting sales activity with product and order information
Soltex Petro Products needed customer-facing work to reflect the realities of its manufacturing business. Sales opportunities, product-development feedback, commercial approvals and order visibility were connected parts of the same process.
Client and business problem
The published case concerns a petro-products and polymer/masterbatch business. Teams needed a clearer route from leads to orders, while handling customer and regional pricing, samples and approval responsibilities. Sales visibility also depended on information about overdue invoices and expected dispatch dates.
What Fristine built
The Zoho CRM scope described in the case covered lead and sales workflows, new-product-development samples and feedback, pricing requirements and sales-hierarchy approvals. The project also addressed visibility into overdue invoices and dispatch information.
The purpose was to connect the commercial conversation with the operational information needed to move it forward. This is particularly relevant when a quotation or order depends on technical feedback and approvals beyond the sales team.
Timeframe and outcome
The original case lists a six-month implementation. The documented result is a more structured and connected sales process with visibility into the relevant product and order information. The case illustrates the information and handoffs required to connect a technically informed sales process with order-related follow-up.
Plan the workflow before the configuration
For a comparable project, start with the points where sales waits for another team: sample feedback, pricing approval, order confirmation or delivery information. Fristine can map those handoffs and define the data ownership, application scope and measures needed for a useful first phase.
Book a sessionFrequently asked questions
What business context does the case describe?
The case concerns Soltex Petro Products and its manufacturing-related sales processes, including polymer and masterbatch business requirements. That context matters because sales work can depend on samples, technical feedback and pricing decisions. The implementation should be understood through those process dependencies rather than as a generic list of CRM features.
Was this only a lead-management project?
No. The published scope also describes product-development samples and feedback, pricing requirements, approvals and visibility into order-related information. Those elements connect the sales process with other operating teams. The exact interfaces and responsibilities for another business would need discovery before a similar scope could be estimated or implemented.
How was new-product-development activity included?
The case describes handling samples and feedback within the wider sales workflow. That provides context for businesses where an opportunity depends on technical evaluation before an order can proceed. It does not establish a measured reduction in development time, and any such target for a new project needs a separate baseline.
What commercial controls were addressed?
The published scope includes customer and regional pricing requirements and approvals linked to the sales hierarchy. These controls helped structure how commercial decisions moved through the process. A new implementation should define approval authority, exceptions and record ownership with the business, rather than copying another organisation's rules without checking their relevance.
What operational information became visible?
The case describes visibility into overdue invoices and expected dispatch dates alongside sales activity. These are useful inputs to customer discussions and follow-up. The available evidence does not establish a particular technical integration pattern or quantified collections improvement, so those details should not be inferred from the visibility described.
How long did the implementation take?
The original case header states six months. That timeframe belongs to the historical engagement and should not be used as a standard promise. A new schedule depends on the number of processes, data readiness, interfaces, testing and the availability of business owners to approve the requirements and completed work.
What should we measure in a comparable sales workflow?
Choose measures connected to the handoffs being improved: complete sample feedback, timely pricing decisions and visibility of an order’s next action. Assign an owner to each measure and establish a baseline. Revenue and collections can also be monitored, but attribution requires care because pricing, market conditions and customer behaviour affect those outcomes.
What should a comparable project measure?
Measures should reflect the handoffs causing difficulty, such as approval turnaround, completeness of sample feedback or the effort needed to obtain order information. The business should define the baseline and reporting period before implementation. Those choices allow the completed workflow to be assessed without assuming that every change automatically creates revenue growth.