Here we goooooo...

[jducoeur]

Finally -- after six months of discussion and development, I get to talk about what I'm doing again. Stealth mode is exciting, but it can get tiring after a while. But the website went live an hour or two ago, and we just had the company meeting to announce the official name change, so it's time to start down the fun side of the roller coaster.

So: Convoq has changed its name to Zingdom. Yes, it's an awfully Web 2.0 name, but it's easy to remember and (unlike Convoq) easy to spell. And we wound up with the shortest domain I've ever been in, zing.dm.

What's the product? The website gives the official view and a bunch of examples, but basically it's all about providing users with controllable ways to contact each other. The core notion is that people have lots of ways to contact each other (phone, IM, SMS, email, etc), but are understandably leery about simply posting their contact information online. We provide intermediary services so that people can use the communications devices they're used to, but do so privately, keeping control over their communication.

I suspect that some of the tech blogs are going to initially dismiss us as just another phone-anonymizing service (of which a bunch have popped up in recent months), but that misses the point of what's going on here. We're well ahead of the pack in a bunch of ways:

• Unlike all the other services, we're explicitly multi-modal. We're supporting phone and AIM initially, with more to come soon.


• The name of the game for us isn't just anonymity, it's control. So we provide things like scheduling capability: for instance, you can easily allow access to your business phone during work hours, and IM in the evening.


• We really aren't selling just a single service, we're selling a platform. Our system was designed from the very beginning to be API-based, so we're set up to do all kinds of integrations quickly. (But we also have a really slick default UI.)


• We're mainly focused on integrating with sites, providing them with ways to help their users communicate contextually, rather than mainly selling to end users. (Translation: we have a plausible business plan.) Yes, I'm afraid this means you can't just sign up, at least not yet.


• Our name doesn't start with J. (Hey, after Jangl and Jaxtr, the company was unanimously agreed on this one.)

Of course, having revealed ourselves, things only get more interesting from here. We've got a lot of irons in the fire over the next couple of months, both in starting to integrate with partners and trying some cool new experiments of our own. We've only scratched the surface of this project so far: there's an amazing amount we can do with this platform, and it's time to kick the tires and have some fun...

Comments

[goldsquare.livejournal.com]

You may have eDial on the run. :-) Of course, we probably have lots of features that you guys don't. But, just from your posting, you have some that we don't (that I wish we did).

One of the ones I wish we did, is time-based control rules. And another is ID based control rules. But, why would I want my fiance to reach me any time, but my boss to reach me any old way - from 8AM-6PM M-F? I don't know.

We probably (I am guessing) have the lead with mobile device interfaces, and I know we are releasing/working on integrated voice mail and email.

I've got to go read your web site now. Bye!

[metageek.livejournal.com]

One of the ones I wish we did, is time-based control rules. And another is ID based control rules. But, why would I want my fiance to reach me any time, but my boss to reach me any old way - from 8AM-6PM M-F? I don't know.

If it integrated with your calendar, you could say, "Customers can reach me by phone during office hours, unless I'm in a meeting."

[jducoeur]

The difficulty there, frankly, is keeping it simple enough. This bit us on the ass with ASAP: it was *quite* sophisticated in its presence and availability management, but we found that people tended not to use the more interesting features. It was just a bit too feature-dense.

So this time, we're playing it a bit smarter -- what I think of as the Google/Apple approach. The feature set is intentionally stripped-down to the basics to start with, expressing the core ideas and giving users the most critical functionality with a reasonably simple interface. As we find out what the users really *want*, we'll build those features in. We lost far too much time in ASAP building systems that were clever, powerful, and just not useful enough to be worth the effort and complexity.

As for calendar integration: not out of the question in the long run, but not simple to do well. We did pretty deep Outlook integration for ASAP, and developed a lot of respect for what a pain in the ass it is. And this is a lot more complex a problem, because most calendar systems aren't designed to express the kind of semantics we need. (And users don't use those features even when they exist.) Distinguishing between "this is a meeting, and I shouldn't be interrupted" and "focus on this project at my desk for a couple of hours" -- well, they're semantically quite different, and have different implications for presence and availability, but they generally look much the same to the code.

Presence management is a remarkably complex art once you get deeply into it: much of Convoq's lifespan was spent on just that, and we had an entire server project dedicated solely to it. Zingdom is only scratching the surface of it so far, because we want to keep things simple to begin with. We'll see where we wind up going with it -- it's just one of the many dimensions we will be playing with. (Frankly, I expect identity-management to be a more interesting and immediate problem, since that's a space in a lot of ferment right now...)

[umbran.livejournal.com]

Well, good luck!

[hfcougar.livejournal.com]

Best of luck.

The trendy, it burns!

I wanted to do that once

[metageek.livejournal.com]

Cool. Back at eCal (a calendaring company in 1998-2001), we wanted to expand into that space. The calendar would've given us a UI for the time-based rules; I got active in the IETF's IMPP working group; and we'd already acquired a company called iPing, which did notifications by phone, and which I thought could give us the phone leg of the stool. (Unfortunately, the iPing infrastructure turned out to be a lot less flexible than we'd been led to believe; any new type of notification required new ASP/Visual Basic coding.)

But then the bubble burst, and all the consumer-oriented sites that were our customers started folding, so we had to dump all nonessential work. (We lasted long enough to build an enterprise calendar, but not long enough to sell it.) Nice to see the idea come back.

Re: I wanted to do that once

[jducoeur]

Frankly, the infrastructure was too immature at the time. Phone control and integration was fairly hard work back then, and could suck up an entire company. *Now*, there's enough standardization to make the phone integration tractable with only a fraction of the team, and allow us to focus on the more interesting aspects of the problem, but I wouldn't have wanted to tackle this seven or eight years ago...