Sifter & Email
Can we email issues into the system and receive notifications? Will we be able to reply to issue updates via email?
20
people like this idea
I like this idea!
Tell me when this idea gets some attention.
The more people who like this idea, the more it gets noticed.
The more people who like this idea, the more it gets noticed.
The company has this under consideration.
The best point from the company
-
I'll revisit it and see if there's a way we can bump it up by keeping it simple. Thanks for all of the feedback. It's good to know that just simple reply capabilities are likely good enough for now.
I’m optimistic
The company and 1 other person think
this is one of the best points
Create a customer community for your own organization
Plans starting at $19/month
-
Inappropriate?We definitely view email as a first-class interface to the system. We're already planning on email supporting all of the features that will be available through the web interface. More importantly, we expect to enable people to seamlessly reply to emails and have the contents automatically imported into the comment stream for the issue. While we haven't implemented this yet, it's an extremely high priority and something we're taking very seriously.
1 person thinks
this is one of the best points
-
Inappropriate?Garrett, this is huge for us too. I love that our clients can use email to bounce communication back and forth and log it all into Sifter. I noticed you posted this 4 months ago, any progress on this side of things?
I’m thankful
-
Inappropriate?No real progress on email into Sifter, yet. Although, once we start adding new features, it's right near the top of the list.
-
Will email make into the final product, still? -
It's definitely one of our higher priority features, but it will be some time (a month or two?) before we get it in there. -
Inappropriate?Looking forward to email into Sifter!
-
Inappropriate?Yes, that was going to be my recommendation. Participating in the communication through all means necessary would be imperative. The downside to similar services is the need to login to maintain the project. I think Sifter's success could lie in managing projects outside the site. Think not only email, but IM, Mobile, etc. On the point of email, here's a nice idea:
Have someone's issues feed their Mac Mail to do list. And as they check items off the list, it adds the status of "resolved" within Sifter. If Mac Mail isn't a possibility, the creation of a widget or something could suffice.
Keep up the good work! -
Inappropriate?so, any news on email?
-
Inappropriate?It's scheduled to be the first new feature. I'm spending the next few weeks refactoring and making some minor enhancements so that we have an easier time adding new features.
I'll be starting on the new features in mid-January '09, and email is right there at the top of the list. As soon as I start designing it, I'll be sharing the behind the scenes design process on our blog so it should be really easy to keep up with.
I’m all over it
-
Inappropriate?Email is still in the queue. I've done some early proof-of-concepting and prototyping, and while I'm happy with the progress, I'm going to put it on the back burner for a bit.
Both email and an API are high priorities for us, but we also don't want to rush something out the door. So instead we'll be circling back and cleaning up some loose ends on the web interface as well as improving the overall user experience before we add alternative interfaces.
I apologize to everyone that really wants this, but after some significant thought, we believe this is the right choice for Sifter long-term. I hate to disappoint anyone, but I hope you understand.
I’m apologetic
-
any ETA? its been ok for us so far without emails and API, but when we launch our product late march, the API will become a "Must Have". I love the simplicity but we cannot input user reported bugs by hand. -
No ETA on the API just yet. We've had a couple of initial design discussions, and we're optimistic that it will be before March, but I can't make any promises at this point.
It's worth noting that Sifter, as it works today, is not a good help desk solution. So, while you could use the API to create bugs, the original submitter wouldn't be tied to the issue anymore because they would have to have a user account within Sifter. As a result, that submitter wouldn't receive updates or be able to provide updates to requests for additional information. Unfortunately, it's just not practical to create a user account for every single customer because Sifter is designed first and foremost to support a client/consultant relationship between companies.
We do hope to eventually improve it so that it could behave as a help desk or support open-source public projects, but that's going to be a good distance out in the future. -
we don't need the help desk part, just something to get the bugs in.
we now have the product owner checking an email account and manually inputing the bugs that beta testers report.
it's good to know that your help desk priority isn't high. we'll se how the product shapes up and evaluate again if we need more public exposure for bug fixing. our idea is that people just play with the game, and we develop it, so it doesn't make much sense to get them in the loop for bug fixing. -
Inappropriate?I'm sorry to keep pushing for this, but it would be great to have email and/or API. Can we expect to see this in the next three months?
Sifter is getting greater adoption in our company : )
I’m anxious
-
I'm really glad to hear that it's getting greater adoption.
It's unlikely we'll commit to any particular timelines, though simply because we're doing so much. I can assure you that a lot is going on, and while things may seem like they're slowing down, we're hitting on all cylinders.
The API is definitely coming. We've already started designing it and laying the groundwork. The reality is that while it's our highest priority, Sifter is still note quite full-time for me, and I'm still doing some client work to pay the bills. We are however working on several different things that will significantly improve Sifter, and it looks like it will be getting much more attention in the next few months.
Email is going to be much more difficult than we anticipated in order to do it well. Because of the fact that it's a supplementary interface, and it's about convenience rather than creating valuable functionality, we've put it on the back burner. Ultimately, if we can't create an email interface that we feel is high enough quality, we may end up putting it off indefinitely. It's one of those things that sounds great on paper, but from what exploration I've done so far in implementing something, it would be limited or clunky.
It's relatively easy to just enable text updates via email, but it's much more difficult to update the status, assignee, priority, or category. Alternatively, we could create some kind of parsable syntax for updating those, but it would be cryptic and unintuitive. So, if/when email does make it in, it will likely be an extremely limited interface option.
In the meantime, we'll be spending time focusing on the API & API documentation and creating a solution for handling milestones. We're also working on redesigning our blog and site so that we have a better way to keep everybody in the loop, get input on upcoming feature implementations, and have a place to put all of the requisite API documentation.
Right now, it's just one big juggling act, but I can assure you that we're getting really close to having me working on Sifter full-time with another person on it part-time in the near future. Then we'll be making incessant improvements. -
Inappropriate?I'm curious of there's been any further movement on this. I've had multiple clients ask why they can't just reply and I tell them it's in the roadmap.
I’m effin' happy
-
Right now, it's definitely still on the roadmap, but it's delayed indefinitely.
Our initial prototyping of the feature showed that it will take a considerable amount of effort to execute well enough that we'll be satisfied with the results. Honestly, it may end up being the single most technically complex feature that we've added.
Receiving the email isn't really the challenge. Parsing it and making sure that Sifter doesn't get filled with noise, vacation autoresponders, verbose signatures, etc. is the main concern. Also, we'd like to devise a simple but reliable way for people to update priority, status, assignee, etc. via email.
Unfortunately, after prototyping it, we decided that the benefit of the feature isn't proportional to the level of effort, so we've let it slide. That is, it would be really nice to have, but it's not actually impeding anyone from using Sifter. It just makes it a little less convenient without being able to reply.
We're certainly not giving up on it, but we'd be remiss to defer the other things in the queue to this. Sifter is full-time for me now, though, and it's an incessant march to improve it.
I know that's not the answer you would have liked to see, but hopefully it helps give some context to things. By the way, thanks for being "effin' happy". It's a really nice relief when people aren't always "frustrated". -
Inappropriate?i must disagree with this point of view.
just being able to comment back and forth is really valuable to get people on board that won't log in to the web interface.
on the other side, being able to change, status/priority/etc seems more like toy features that don't matter cause they are usually done by people who do log in to the web interface frequently (typically the project manager or assistant)
regarding autoresponders and signatures, i can share my experience with basecamp's email reply feature:
-signatures usually don't bother cause they are always in the end of the message, so they don't get noisy
-regarding autoresponders, i believe the "reply above this line" mechanic implemented in basecamp effectively removes all issues with them, as most default autoresponders don't include the received message. It Also filters out lots of signatures (at least previous mails signatures for sure, soemtimes not the one of the guy writing the email)
-attachment parsing is not needed
I’m unsure
-
Inappropriate?I have to agree with cubetto. Being able to comment back and forth is really valuable and changing priority, status etc is not. Also being a Basecamp I can also agree that the "reply above this line" system works pretty well and seems to eliminate most of the problems that Garrett lists.
This all said, given the choice between this and the API, I'd prefer the API first. Jumping between Basecamp and Sifter to keep things in sync is getting a bit tiresome. I'd just prefer automate it myself something like Tiki.
I’m also unsure
-
Inappropriate?Thanks for the reply Garrett and I'm still effin' happy...
That said, I appreciate your position and have to agree with both tima and cubetto. Maybe it's just me but more than half of my clients won't login to any sites. The only way I can get clients to use basecamp is through emailed replies and I can see it going in that direction for Sifter. I don't think status udpates are all that important for email integration but just being able to reply to tickets via email might help keep my clients focused a little.
Either way, it's a kick-ass service and looking forward to what you do with it.
I’m halucaseeing
-
Inappropriate?I'll revisit it and see if there's a way we can bump it up by keeping it simple. Thanks for all of the feedback. It's good to know that just simple reply capabilities are likely good enough for now.
I’m optimistic
The company and 1 other person think
this is one of the best points
-
Inappropriate?This is a huge priority for us. I've had a hard time selling the app to my clients, and with the lack of either an email submission, or a manual way to assign the submitter, I'm afraid we'll have to abandon our subscription soon. We just moved away from zendesk due to their restrictive pricing structure so I'd hate to have to go back.
I’m frustrated
-
I'm sorry to hear you're thinking about leaving. That's never good to hear. However, we have dozens of factors and thousands of users to keep in mind with every decision, and it's not something that we take lightly.
While we plan on supporting this at some point, our vision for it will require a significant amount of effort to do well. It will add more moving parts, require a plan for handling spam, and need to be elegant on top of that. We want don't want to just check this feature off of a checklist, we want to do it in a way that people can enjoy using it. That takes time.
As I mentioned in my earlier comments, basic reply via email is something that we're considering putting in place sooner, but given that it's all so closely connected, we're hesitant because we don't want to build something that will need to be torn out shortly thereafter when the larger solution is put in place. -
Totally understandable - anything (however small) to alleviate some of these issues would be appreciated. -
It will happen at some point. We just can't be sure when. It's entirely possible that we might phase it in in small pieces to speed it up, but it's too early to say for sure.
Loading Profile...



EMPLOYEE



