Difference between revisions of "2002-06-29 SvsG Emails"
m (template by year) |
|||
| Line 1: | Line 1: | ||
{{SvsG Email|2002}} | |||
=13:27 from Nick= | =13:27 from Nick= | ||
==Text== | ==Text== | ||
Revision as of 15:53, 16 October 2005
Staddon vs. Griever: SvsG Messages: 2002
13:27 from Nick
Text
- Message-ID: <3D1DEE1D.9060907@redhouse.com>
- Date: Sat, 29 Jun 2002 13:27:57 -0400
- From: "N. Staddon" <n@redhouse.com>
- To: team@vbz.net
- Subject: team update 6/29
1. I have created a list for internal memos, discussion, etc. Email sent to "team@vbz.net" is automatically forwarded to all us'ns.
2. I have also signed up for a dedicated server. This is $60/mo. Domains are unlimited, but if we want to really use a domain we have to buy an IP address for it (otherwise it will have to be a limited redirect like "benefit.vbz.net" which is difficult to use). IP addresses, fortunately, are cheap:
- 8 IPs $25 startup $8/month ($1 each)
- 64 IPs $25 startup $32/month (.50 each)
- 128 IPs $25 startup $64/month (.50 each)
- 256 IPs $25 startup $128/month (.50 each)
Here are the domains we have currently hosted, that I can think of:
(vbz.net not moving for now)
- 0. redhouse.com (already set up as main account for server) was $40/mo @ Affinity
- 1. redistribution.org -- currently about $15/mo
- 2. indiantshirts.com -- currently down but costing $5/mo anyway
- 3. thejandj.com -- same
- 4. something for Lofty Ideas, set up by Bubba -- how is this being billed? If I recall correctly, it's on Affinity at $20/mo.
There are countless additional domains we have registered but not hosted; we should do a survey of these and see which ones we could put to good use and what the investment of time and other resources might be for each one -- and then we can decide how many IP addresses we will need for the near term.
--
Seems to me there was another item I wanted to mention, but it escapes me at the moment -- so that's all for now...
N.
18:31 from Nick
Notes
- The psych.duke.edu email address belongs to Nick's father. (All email addresses are obscured in such a way that spambots should not be able to read them correctly.)
Text
- Message-ID: <3D1E3544.70301@redhouse.com>
- Date: Sat, 29 Jun 2002 18:31:32 -0400
- From: "N. Staddon" <n@redhouse.com>
- To: team@vbz.net
- CC: tigger@redhouse.com, staddon@psych.duke.edu
- Subject: vbz strategy, 6/29 (long)
(note to "The Team": I'm cc:ing a couple of parties who have expressed interest in the inner werkins of Da Bizniss and/or my head. Since this involves both...)
It has been bubbling around in my head for several days now that we need to think about "roles" at vbz.net, i.e. whose "job" it is to do which functions, so we can avoid either stepping on each other's toes or leaving tasks incomplete.
Some tasks are just going to be problems for a little while until we work out systems for dealing with them (I'm thinking primarily of customer support, though I'm sure there are others), but we can at least get clear on who is the "point" person for each task.
Here's a first stab at making a list of roles/tasks. I'm sure it's not complete, but it's still pretty long and boring. I think it is very important for us to have a delineation like this, though, so that we have some kind of handle on Just What It Is That We Do as vbz.net, so that we can ask questions like:
- are we each doing tasks that we want to be doing?
- are we able to be _effective_ at the tasks we are doing? If not, why not? (i.e. are there solvable problems preventing us from being effective at a given task, or should someone else be doing it?)
- what tasks would we each _like_ to be doing, and what's left over once those are accounted for?
- if we're doing tasks that we really would rather _not_ be doing (and there isn't someone else on the team who could take over), is there a longer-term strategy for offloading those tasks? What additional tasks will be required if that happens (there's not yet any section called "management"...), and how will those tasks affect the answers to the above questions?
- how much of our available time do we each want to put into this project anyway, and how much of it can be handled that way? How much is left over?
- what is our focus/goal? Are we (a) trying to make money off selling stuff? (b) demo-ing our software so we can sell our services? (c) demo-ing our software to attract investment capital (or, alternatively, open-source developers) to develop it further (for sale, publicity, or whatever)?
Anyway, here's the long-and-boring breakdown. Comments and suggestions are invited.
BREAKDOWN BY TASK
A. PRIMARY BUSINESS FUNCTIONS
- 1. customer support
- 1.1 answering "where's my order"
- 1.2 managing other order-related correspondence
- 1.3 handling non-order-related customer inquiries
- 2. shipping
- 2.1 sorting received restock items by order
- 2.2 creating packages in order db (so we know what's shipping so we know how much to charge)
- 2.3 processing charges & refunds in PTC
- 2.4 preparing physical packages
- 2.4.1 printing packing slips
- 2.4.2 printing address labels (manually or otherwise)
- 2.4.3 putting stuff in envelopes or boxes
- 2.5 checking packages into shipment (in DB and box(es) to take to PO)
- 2.6 delivering physical packages to PO
- 2.7 entering shipment into DB (timestamp, cost, notes)
- 3. restock orders
- 3.1 determining when it's time to place a restock order
- 3.2 collecting/reconciling list of items to order for restock
- 3.3 phoning in the order, confirming available items
- 3.4 emailing amended order confirmation to supplier
- 3.5 handling n/a items resulting from phone confirmation
- 3.5.1 adjusting status of n/a items in the catalog DB
- 3.5.2 notifying customers of unavailable items (subsequent interaction becomes part of 1.2)
- 4. stock
- 4.1 performing complete inventory of compromised containers (only needed occasionally; urgently needed right now)
- 4.2 adding leftover items (orders not paid for, items mistakenly sent by suppliers) to inventory db
- 4.2.1 adjusting special prices as stock is depleted
- 4.3 maintaining organization of inventory containers; constructing/maintaining shelvage etc.
- 4.4 managing out-of-print items in stock
- 4.4.1 determining special pricing
B. SECONDARY BUSINESS FUNCTIONS
- 1. bookkeeping
- 1.1 entering transactions into money db
- 1.2 reconciling transactions against bank statements (online or printed)
- 1.3 determining what funds are available for any given purpose
- 2. accounts receivable
- 2.1 determining what amounts are owed to the company
- 2.2 printing statements and delivering them
- 3. accounts payable
- 3.1 collecting all the bills for amounts we owe
- 3.2 deciding when & how much to pay
- 3.3 writing checks or otherwise delivering payment
- 4. finance (obtaining funds to cover deficits)
- 5. red tape
- 5.1 determining what records need to be kept in order to comply with legalities
- 5.2 making sure those records are kept; creating back-dated records if needed
- 6. taxes
- 6.1 determining what records need to be kept for tax purposes
- 6.2 keeping those records
- 6.3 filing appropriate tax forms
C. MAINTENANCE
- 1. Data maintenance
- 1.1 Catalog DB maintenance
- 1.1.1 Keeping catalog DB current
- 1.1.1.1 Obtaining the latest catalogs from suppliers
- 1.1.1.2 Entering catalogs into DB
- 1.1.2 Keeping pages updated from catalog
- 1.1.2.1 Rebuilding pages from latest DB data
- 1.1.2.2 Uploading latest pages to site
- 1.1.3 Keeping static data (in scripted pages) current
- 1.3 Image maintenance
- 1.3.1 remaking problematic images
- 1.2 Static page maintenance
- 2. PC Systems maintenance
- 2.1 Responding to workstation issues
- 2.2 Managing backups
- 3. Server (web hosting) maintenance
- 3.1 Searching for errors
- 3.1.1 Browsing thru site, especially recently-modified areas
- 3.1.2 Placing test orders, especially recently-added items
- 3.2 Keeping track of errors found
- 4. Supplies
- 4.1 Keep track of what office materials are running low
- 4.2 Purchase materials as needed
- 4.3 Print things like return address labels, business cards, etc.
D. IMPROVEMENT
- 1. Development
- 1.1 Existing store framework
- 1.1.1 Writing new scripts
- 1.1.2 Writing static content
- 1.1.3 Adding new items/suppliers to DB
- 1.1.4 Images
- 1.1.4.1 Requesting images from suppliers
- 1.1.4.2 Scanning or photographing items, where supplied images are n/a
- 1.1.4.3 Processing images into appropriate sizes, contrast, bg, rotation, cropping
- 1.1.4.4 Adding processed images into DB
- 1.2 New areas of store (back-door domains, new interfaces, etc.)
- 1.2.1 Writing new scripts
- 1.2.2 Writing static content
- 1.2.3 Server configuration (control panel, CGI, .htaccess, etc.)
- 1.3 Applications currently under development & in use
- 1.3.1 Money Tricorder
- 1.4 Applications which could improve effectiveness but are not currently ready for use
- 1.4.1 email system
- 1.4.2 FTP system
BREAKDOWN BY SYSTEM (much simpler)
- A. Information Technology (egad, I'm creating an IT department...)
- A.1 Local network admin (hardware & software)
- A.1.1 User support
- A.1.2 Maintenance
- A.2 Remote server
- B. Business
- B.1 Red Tape
- B.1.1 Taxes
- B.1.2 forms, licenses, other nonsense
- B.2 Accounts
- B.2.1 Assets (bank accounts)
- B.2.1 Receivables / Billing
- B.2.2 Payables
Just taking a very coarse and approximate look at how these tasks have been divided up so far:
- A - 20% Bubba / 50% me / 30% neglected
- B - 70% neglected / 20% me / 10% Livia (taxes only, and 2001 was the last tax year with which she'll be involved)
- C - 15% neglected / 65% me / 20% Bubba (requesting catalogs, processing images)
- D - varies; development usually goes in fits. Tends to focus on me.
I'll send my personal responses to The Questions (the ones just above the breakdown list) in a separate email...
N.
21:33 from Nick
- Message-ID: <3D1E5FD6.3070107@redhouse.com>
- Date: Sat, 29 Jun 2002 21:33:10 -0400
- From: "N. Staddon" <n@redhouse.com>
- To: team@vbz.net
- CC: tigger@redhouse.com, staddon@psych.duke.edu
- Subject: vbz strategy 6/29 pt. II: NIck's survey answers
My personal answers to The Questions:
I'd prefer to focus on D (forward-moving innovative-type stuff), though I don't mind dabbling in C. I definitely am not very good at B (paperwork), though given relief from some of my other urgent obligations I could probably deal with it a lot better (and in time I expect to have it much more automated than it is now). I can do A (day-to-day ops) if necessary, especially when developing systems to make it easier, but once the system is working I'd rather let someone else do the routine stuff. As my share of non-D-ish tasks rises, my interest in the enterprise decreases, and vice-versa.
I originally got into entrepreneurship because I wanted to have a recording studio. That mutated into selling music online, which mutated into selling art and t-shirts online.
Both mutations happened because the previous zygote wasn't showing signs of viability yet and the mutation seemed like a quicker way to breathe some life into it (get some cash flowing). Each time, I got a little further from what I had set out to do -- but each time, I found a way to fit something I enjoyed doing into the new shape.
However, this left me having to find something I want to do within the shape The Thing had become, rather than choosing what I want to do and shaping The Thing to accomodate it as was the original plan.
This still seemed worthwhile when it seemed like The Thing could turn around fairly quickly and begin supporting me to the point where I could meet my financial obligations and have at least a modicum of time free to work on the things I really wanted to work on (which was something I had always had, until moving to Athens) -- whether they were part of The Thing's needs or some other project.
It has now been approximately 4.5 years since the last major mutation of The Thing (a minor mutation happened sometime during the interim, in that we seem to have abandoned any attempt to expand or maintain vbz.net's musical offerings).
Profitability still seems possible, but it still does not look like a quick win. No piles of cash will be coming in the door any time in the next six months and resolving all issues by rendering them moot. Dedication and concentration will still be required to make profitability happen, if it is going to happen, and that in turn requires clarity of purpose.
So much has happened lately that any existing clarity of purpose I might have had (much of which was, I believe, simple desperation) needs to be taken apart, oiled, sharpened, and carefully reassembled if it's going to be usable. I have had to let go of so much in the past 12 months that clinging to a still-distant goal such as this one (though it has become visibly closer) can begin to seem rather pointless at times. New opportunities and new obstacles have appeared; we are no longer navigating the same landscape, and the map showing our original goal (or any mutation thereof) no longer corresponds to the terrain.
I am _not_, however, prepared at this time to abandon it cold -- but I do think we need to look carefully at why we are pursuing it in its present form, and whether there is anything we can do to get closer to our individual goals.
There's more, but my thinking is starting to get fragmented. I will send the rest in part III, if it ever coalesces.
TTFN,
N.