Support

Personal To Do List

GTDInbox is set up to enable a person to use Gmail as a central task list, available wherever you can use Gmail – which is a lot of places (Web, mobile, desktop email software, etc.).

Create a Task

Creating a task is simply a case of sending yourself an email (‘Compose Personal'), and then labelling it as an Action, and perhaps giving it additional meaning by assigning it to a Project, Context or some other label. You can accelerate this process by creating a Gmail filter that auto-labels all messages you send to yourself as S/Action (or just use GTDInbox's Pre-Label feature to add the labels as you compose the message), but beware that this can cause complacency – you might take S/Action less seriously if it's automatically applied.

As a matter of house keeping, everything should be archived once processed. So long as it has a Status (or a Project/Context), it will be found during reviews. This is to maintain inbox-zero – a state of reduced clutter in your email life.

Process Tasks

Processing the actions is then a simple case of review. Use the GTD Dashboard to bring up a list of all items marked Next Action or Action, and proceed to complete them.
Next Action is a short-list of actions, used to decide what is most important to do next. It allows you to do a ‘planning' session (choose next actions), and then a ‘doing' session (run through the actions without having to think too deeply) – splitting the separate mental tasks to relieve our brains. A particular pleasantry of using Next Actions is to give you the satisfaction of completion. For instance, at the end of the day you can choose the most important Next Actions for tomorrow, and use them as a ‘tomorrow list', so that once all those Next Actions are complete, your day is over. As opposed to simply working and working until you run out of time, and then having the sensation of not finishing things.
The ‘Someday/Maybe' status also has a very important property, because it lets you add actions without having to make arbitrary decisions for when they'll be done. There are simply things ‘you might like to do', so you can think of an action and just dump it in Gmail. Periodically – e.g. once a week – you should review your Someday items, and see if any of them ought to be promoted into real actions.

Update a Task

Gmail's conversational threading system works nicely for updating existing tasks. Attaching a file, or a new piece of information, or more detail on the task is just a case of replying to the thread (i.e. replying to yourself), so the update is appended to the end.

Finish a Task

Finally, finishing an action is done by removing all status labels (e.g. S/Action). Without a priority, it drops out of the GTDInbox view. Some people prefer to explicitly mark items as finished, using S/Finished, as a measure to ensure no email is overlooked (i.e. it has 3 states: In Action with a status, Finished with S/Finished, and Uncategorised – which means it needs a decision taking).

Managing a Project

The second greatest strength of GTDInbox – after managing priorities – is grouping items into projects. It brings control & order to the mess of your inbox.

What is a project?

A project is loosely defined as anything that requires more than one action (or resource – like a file). Generally speaking, there's no real need to explicitly finish a project; only actions are finished, and a project is inactive when there are no more actions.

A project can consist of actions, communication and files – all of which you can either of sent or received.
In GTDInbox, you can also have sub projects. For instance, I have a label P/GTDInbox, but I also have P/GTDInbox/Bugs and P/GTDInbox/Ideas for bugs & ideas related to GTDInbox.

Adding Items to a Project

Adding items to a project is as simple as applying the appropriate label to the thread, either when they appear in your inbox or as you compose them.

Ski Trip Example

Take a recent project of mine, to organise a snow boarding trip for 8 people. As this is relatively simple, and because it is just to improve my personal organisation, there is no need to coordinate my project items & labels with other people; it all takes place in my inbox.
If an email comes in about the trip – which involves getting agreement from the 8, and communicating with hoteliers, airlines and hire places – then it is marked with P/SkiTrip/Feb08. If it is an action that can be done in two minutes, it's done & marked finished. If it is a longer action – like filling out forms to return by post – then it gets marked S/Action and archived. Nothing is deleted.

When I compose a new message (or reply) to the group, and I expect an action to be taken – e.g. to reply to a question like ‘can anyone find a good discount' or ‘do we need to include linen', or to do something like book flights – then the message is marked S/Waiting On.
This is a way an effective way to manage delegation. It is now trivial to see all the things I'm waiting for others to do in any given project; and the time (on the thread) that there was last movement on an item. I can then, if I so wish, reply to that thread to ‘ping' the people involved to find out the status.
Every time someone replies to a S/Waiting On thread, I can check to see if it's complete, and thus that is when I would remove the S/Waiting On item.

A similar review is used for the actions that I'm expected to take. They'll be marked S/Action, and at the start of the evening, when I would deal with the trip, I can quickly see all outstanding actions and start doing them.

Finally, I can use references to add meaning to the resources in the project. Specifically, the project contains invoices – which I need later for splitting the costs with people – and forms (e.g. chalet booking) that I must return. I can mark these items with R/Form and R/Invoice respectively, making it easy to request GTDInbox to ‘show me all invoices attached to the ski trip'.

Team Working

GTDInbox can loosely support teamwork, and it is not much more complex than personal management. The principle distinction is that each person in the team must use the same label names (for Projects & Contexts), must use GTDInbox, and that you use Pre-Labelling when communicating to one another.

Pre-Labelling Messages and Delegation

Suppose I am requesting that a colleague test the latest release of GTDInbox. I would compose the email with the request, pre-label it with C/Office and P/GTDInbox/Testing and S/Waiting On, and send it to the colleague.
When it arrives in their inbox, the C/Office and P/GTDInbox/Testing labels are automatically applied.
When they reply, I can remove the S/Waiting On label; and if they don't reply, I can follow up (after reviewing all S/Waiting On items).

The point here is to simplify communication between team mates; as well as ensure a little structure within the team's inboxes.

Associating People with Projects and Contexts

Over time, GTDInbox will learn the most relevant people associated with a project; so when you right click a project, you can browse the associated contacts, and potentially send an email to all involved. Conversely, it will also tell you the projects most associated with a person when you right click them.

Gmail Tip

Unrelated to GTDInbox, Gmail now does ‘groups' for contacts, making it easier to send an email to everyone in a group.

Customer Support & Relationships

GTDInbox is specifically designed to be contact orientated.

To be a little philosophical for a second, email is the original social network: communication & file exchange with a trusted set of contacts.
Gmail does this even better. It makes sharing pictures more natural by showing them within emails, it has instant messaging for more light weight communication, it effectively ignores un-trusted contacts with its spam filter, and it makes searching by contacts trivial.
That is not to say email is perfect, we are all suffering from a huge overflow in our inboxes – caused by the simplistic ‘anything goes' list view and a deluge of daily emails, which must be clunkily opened individually. Email is also a bottomless pit, making anything over a few days tricky to rediscover (I have over 6000 emails spread over 1GB accumulated over the last 3 years, and I think I'm a fairly light weight user).
Contacts – along with projects and contexts – provide an effective and meaningful way to slice through the mess to find relevant, related items when you need them.

In a nutshell, the most useful contact-related features are to see - at a glance – any historic communication with a person, and to browse any projects, people (and various other items) that they may be related to.

An Example: Customer Service for GTDInbox

To illustrate doing customer service with GTDInbox, I'm going to use a few examples of how I do customer service for GTDInbox.

Types of Communication with Customers

To give a little background, with GTDInbox user relationships fall into 4 broad categories: ideas, bugs, help requests and donations. Given GTDInbox has a personal feel to it, I like to communicate on a one-to-one level with the people who write, building up a dialogue over time. There is also a serious side, in that I need to account for donations, action bugs & feature requests, and find answers to help requests. A final subtlety is that help requests are often thinly veiled bugs/ideas, so they must be transformed as such.

Categorising Incoming Requests

When an email comes in, it is categorised based on initial assumptions. While reading, I will right click the sender, and use the Contact Popup to see any previous conversations (opened in a new window, so I don't have to close the email). I'll use this history to incorporate any specific nuances that person has, such as a particular setup, a recurring problem, or perhaps an outstanding action I was supposed to do for them but slipped the net. The Contact Popup also allows me to see – at a glance – what labels they're associated with, so I can see if they offer a lot of ideas (P/GTDInbox/Ideas), suffer a lot of bugs (P/GTDInbox/Bugs) or have donated (R/Donation).

If the email is posed as a help request, but suggests a bug, I'll add my own reply to the thread (sent to me only) to clarify the bug, and label it as P/GTDInbox/Bugs and S/Action. (Similarly, if it's a feature request, it'll get an appropriate label and S/Someday.)

Reviewing Actions created by Customer Requests

Next time I come to a bug fixing session, I'll pull up all action items marked as a GTDInbox bug. Typically, I'll commit them to paper as I find that easier in the short term (GTDInbox will soon have printing capabilities, at which point that would be more useful).
For feature requests, I'll use a processing session to formulate a new road map for the next month or so.
In both cases, once the item has been dealt with, S/Action is removed and S/Finished it added.

Overall, by organising your communication by contacts and projects, GTDInbox becomes very effective at providing a backbone for CRM and customer support.