Siddharth Sehgal and the price of a free pass

Siddharth Sehgal’s first Dreamforce souvenir was an education he had managed to get for free. He arrived in San Francisco alone, a visitor from Delhi for whom buying a conference ticket felt out of reach. A free pass let him attend sessions. By 2023, he was returning with ten colleagues for his company’s sixth sponsorship. The visitor had acquired a booth, a team and a reason to keep talking.

There is a pleasing economy to that beginning. Sehgal sells communication software, yet a large part of his business has depended on showing up and having conversations. Customers tell him what is missing. Partners decide whether to trust him. Employees discover that solving a problem quietly can leave a customer noisily wondering whether anybody is working on it.

The founder and CEO of 360 Degree Cloud has spent years turning those exchanges into products. His story includes an app that failed, a price that frightened a buyer by being too low, and the slow discovery that a founder can become an obstacle by being available for everything. Software provides the setting. Learning whom to listen to supplies the plot.

The first product had a staffing problem

Sehgal places the start of his career around 2008 or 2009, at a large systems integrator in India. After roughly three years, he saw room below the enterprise accounts that attracted the big firms. Smaller businesses also needed help making Salesforce useful. In 2012, he and co-founder Pooja Singhal launched 360 Degree Cloud.

He describes himself as a sales person. Early product hiring therefore began with developers, while he handled selling. This division matters: the founder was close to the customer’s objections, and he needed other people to turn the answers into working software. His company began with consulting, where a specific client’s problem comes with a specific client’s bill.

The move into products looked economical. Consultants waiting for assignments could build something the company owned. Then a paying consulting project arrived, the developer was reassigned, and the product waited. Spare capacity proved to be an unreliable business partner. It tended to leave just when somebody offered it money.

The early app, 360 Merge Duplicates, was eventually discontinued. Sehgal connects its failure to the absence of a dedicated team. It taught the company about AppExchange development and complicated customer environments, but it also taught a less technical lesson: a product needs people whose main responsibility is the product. For 360 SMS, he assigned them.

An SMS app outgrows its name

The communication gap interested him because it crossed industries. Many businesses needed to reach customers, even when they sold very different things. The company dates the launch of 360 SMS to 2016. The name was admirably clear about what it did, which later became slightly inconvenient.

The app expanded into WhatsApp, calling, email and channels serving different markets, including LINE, KakaoTalk and WeChat. Sehgal calls naming it after SMS a classic mistake. A short name can become a remarkably persistent piece of office furniture: useful, familiar and increasingly difficult to fit everything inside.

He started with low pricing to bring smaller customers in. Their requests then shaped development. Instead of treating his own ideas as an automatic ticket onto the roadmap, he listened for features customers asked to use. The arrangement gave the company time to build and customers a reason to explain what they wanted.

This is the practical appeal of his consulting background. A request arrives attached to an actual workflow. Someone needs a message sent, a call recorded or a conversation carried into the right record. Product decisions can then begin with work somebody is trying to finish, rather than a feature somebody would enjoy announcing.

When cheap becomes suspicious

One enterprise customer produced a sales objection that few sellers expect: the price was insufficiently alarming. Sehgal recalls offering a year for $3,000 to a large Salesforce customer. The buyer worried that a supplier charging so little could not afford to provide the service required.

Sehgal had to get on a call and persuade the company that the offer would work. He says the relationship endured and eventually became worth half a million dollars to his business. He leaves the later amount’s billing period unspecified. The telling detail is the buyer’s original hesitation: a bargain can require as much explanation as a premium.

That experience sits inside a deliberate progression from smaller clients towards larger accounts. Customers helped deepen the product; the company subsequently increased prices and pursued the mid-market and enterprise. The initial fee opened a conversation. Keeping the relationship required the product and the service to justify staying.

By the January 2026 release of his AppsemblyLine conversation with Scott Covert, Sehgal reported a revenue split of 60% AppExchange and 40% consulting. He also described the company as entirely bootstrapped. Consulting had financed development. Products had grown into the larger revenue stream. The early service business remained part of the economics.

The founder learns to leave the room

The hardest resource to reassign was the founder himself. Sehgal remembers wanting to save money and do everything, including judging whether somebody else could possibly sell as well as he could. His advice to his earlier self is to hire capable people sooner and hand over the tactical work.

He describes a change in how he assessed employees. Familiar faces once had an advantage: people who frequently came to him looked engaged because he saw them working. Eventually he began valuing the colleagues who met their numbers without requiring his constant involvement. Proximity had been masquerading as performance.

He still makes himself available when people are stuck. What he wants to avoid is a daily arrangement in which every decision borrows the founder’s authority. Accountability becomes difficult when a person can always explain that the boss told them what to do. Independence frees the employee to own the result and the founder to consider the next problem.

His appetite for quick execution also met a demand for process. He recalls his wife insisting that the business could not keep scaling in the same way. Dashboards were already familiar territory in a Salesforce company; clearer responsibilities took longer. He describes seeking a middle ground where structure supports growth while decisions can still move quickly.

“I have always considered myself as a sales guy.”

Siddharth Sehgal · AppsemblyLine

Seven hours of work, five minutes of explanation

A communication business can have its own communication problem. Sehgal describes engineers dropping everything to fix a customer’s issue, becoming absorbed for hours, and sending a brief message once it was resolved. During the silence, the customer had no way to know that the work was happening.

Worse, a short resolution message could make the eventual fix look effortless. The customer might conclude that a five-minute job had taken most of a day to receive attention. The team understood the labour. The customer understood the delay. Both were looking at the same seven hours.

Sehgal’s answer was to teach the missing part of service: tell the client when work begins and explain what has been done. He says this became part of onboarding. His support model also favours a Zoom conversation to resolve issues rather than a prolonged exchange of emails. The company sells channels; the lesson concerns what travels through them.

He has taken that interest into authorship with Cracking the SMS Conversion Code, a book about when and how to send messages. Across the software and the support desk, his recurring subject is the gap between dispatching information and making another person feel adequately informed.

A larger business, with boundaries

Running consulting and product operations together creates another delicate conversation. A consulting partner that recommends an app might reasonably worry that its maker will also compete for the client’s implementation work. Sehgal says he deals with that through a firm boundary: partner-introduced product customers are excluded from his consulting pursuit.

In his account, that restriction survives even if the referring partner later leaves the customer. It is a clear choice about a future opportunity he will forgo. A partner relationship becomes more credible when the answer remains the same after the immediate commercial circumstances change.

His next ambition is a small exchange of 360 products, spanning communication and productivity, while remaining within Salesforce. AI development follows different customer preferences: Agentforce, external models or customer-controlled infrastructure. In the conversation released in January, he described optional activation and human checkpoints before messages or calls proceeded. Those details give his ambitions an operational shape.

The return ticket

By September 2026, Sehgal was again writing about Dreamforce, recalling the free pass and describing nine consecutive sponsorships. The conference had become a recurring place to meet customers and discuss what they wanted next. An annual trip had accumulated the weight of a business routine.

That gives the opening story its significance. A free pass could provide access for a few days. Returning meant having something worth bringing back: a product, a team, an answer to the previous conversation. His career has developed through those returns, including the uncomfortable ones to an app that failed or a management habit that had stopped helping.

The most revealing scene may still be the engineer silently working while the customer waits. Sehgal understands why both sides feel misunderstood. His business depends on getting them into the same conversation. After years of adding channels, products and people, he keeps returning to that modest piece of work: make sure the other person knows what is happening.