customer 'aftersales visit' monitor

[bite_tony]

Hi,

I am trying to create a system for my window company, whereby the boss can monitor visits to homes where we have installed windows and had to go back to fix various issues.
I'm not a complete novice when it comes to access but it has been a very (very) long time since i used it.
The boss wants to be able to monitor how many calls are being made (cumlative AND to individual households) and the nature of these calls..

In my head, a database is the best way to go,
should i be using a spreadsheet?

ALSO...can anyone point me in the direction of a sample database along these lines?

 

[plog]

You haven't exactly asked your question to an impartial panel--this is an Access forum. Have you asked this to an Excel forum? I'd be interested in how the answers here match up against those.

With that said, you should probably choose Access. Whenever the boss wants new reports--it always starts out as a few simple ones until he sees what data you have and then wants to dig deeper. Then he gets a crazy idea and wants to create even more reports that are usually more complex. If you lay your data out correctly in Access those will be easy to produce for him.

Access can also make data entry easier which means the learning curve for doing that is shorter allowing more people to work directly with the data.

What I am saying is that Excel is good for simple data worked on by few. But the more data you get and the more users who need to interact with it, Access becomes the better choice.

 

[bite_tony]

Cheers for your reply, funnily enough i did ask on a spreadsheet forum and got told a spreadsheet was the best way forward.
I reckon a database might well be the best way to go though..
I'm just going to have to relearn it first..

I'm thinking of
A table with customer details, with customer ID as a primary key
Then a seperate table with a rolling list of all aftersales calls on it,

I assume its possible to have each individual's aftersale history show up with their details if i configure my query correctly?

Any ideas where i should be looking for it to flag up when several calls have been made and no progress has been made?

 

[plog]

So far your general table structure sounds solid. However now that you want to track when several calls have been made on a single issue, you probably need a new table. Access is sounding like a better choice if you want to do this.

What I would do is create these tables: Customers, Issues, Calls. Think of the system like a hierarchy with Customers at the top, Issues in the middle and Calls at the bottom. This is how it would play out:

A Customer can have many issues.
An issue can have many calls.

That structure would let you see how many issues a customer has had, how many calls an issue has had, how many calls a customer has had and even allow you to see which issues cause the most calls to fix.

You could have a field in issues called something like 'DateResolved', if its blank it means the issue is still a problem, from there you could easily count the number of calls made to resolve it.

 

[gemma-the-husky]

the thing is

SPREADSHEET

a spreadsheet is easy to do but hard to control. you will get wrong/invalid data in some columns.


DATABASE

a database is hard to do well, but then becomes easy to control, and prevents all the errors you are likely to get in a spreadsheet

but there is a steep learning curve for access.

for one thing, you hardly ever see all your data at one time. So you have to be 100% sure that your rules for manipulating the data work with all the data.

 

[bite_tony]

So far your general table structure sounds solid. However now that you want to track when several calls have been made on a single issue, you probably need a new table. Access is sounding like a better choice if you want to do this.

What I would do is create these tables: Customers, Issues, Calls. Think of the system like a hierarchy with Customers at the top, Issues in the middle and Calls at the bottom. This is how it would play out:

A Customer can have many issues.
An issue can have many calls.

That structure would let you see how many issues a customer has had, how many calls an issue has had, how many calls a customer has had and even allow you to see which issues cause the most calls to fix.

You could have a field in issues called something like 'DateResolved', if its blank it means the issue is still a problem, from there you could easily count the number of calls made to resolve it.

thanks!!! that is really really helpful....i needed some kind of starting point..i'll see how it goes from there. No doubt i'll be back with more questions further down the line

Thanks again

 

[bite_tony]

the thing us

SPREADSHEET

a spreadsheet is easy to do but hard to control. you will get wrong/invalid data in some columns.


DATABASE

a database is hard to do well, but then becomes easy to control, and prevents all the errors you are likely to get in a spreadsheet

but there is a steep learning curve for access.

for one thing, you hardly ever see all your data at one time. So you have to be 100% sure that your rules for manipulating the data work with all the data.

this appears to be the dilema i'm facing, both programmes are capable, but one is hard to start with and easier later, and ones easier to start with then harder later...

im gunna give it a go with this database and see where i end up, because there might be other people who will need to input data on it, and i dont trust 'em...not one bit..

thanks for your input...